LUGGY HAZ SOMETHING TO SAY :D

[Ketra Naideen]

DISCLAIMER: I might not know as much about the site as I would like. So it is very likely that something I say here can be totally discredited by another fact.

Catching Pokemon

I know that there are events that allow people to catch pokemon, but I think for a pokemon-catching based game (practically the whole point of pokemon is to get more pokemon). Therefore I personally think that opportunities to catch pokemon should not be limited to simply events. In the actual game (which honestly is where most of my experience in this comes from) you just go into areas and wild pokemon appear. And you have a chance of catching it. Why not implement that here? It is a school for pokemon trainers. But this poses some problems of course. 1) students can catch whichever pokemon/however many pokemon they want 2) how will we decide if they catch it or not.

However I still think this is doable with a little bit of staff/player involvement. Certain areas can have certain pokemon at different times (ie fire areas have certain fire types at some time and grass areas with grass pokemon and so on). There can be a common, uncommon, and a rare pokemon (or more pokemon depending on what you want to do). These pokemon can be NPC controlled by either the staff or other players (you can provide a separate NPC pokemon account and maybe even award extra points for playing an NPC pokemon). Furthermore you can roll for which pokemon appears in said thread and limit the number of pokemon catching threads that can happen on the site to make it more manageable (I'm assuming it'll be a tad bit hard for someone to play an NPC in each of 10 threads involving catching a pokemon). Furthermore you can limit the number of posts/time in which a trainer needs to catch a pokemon so to limit the time on the threads. 

I say this only because personally I think it's something very essential to the game. By all means you can cap the number of active pokemon a person can have (within logistical reason, I personally don't find any harm in capping the number at 6 since that's the basis of most pokemon games) but please pick and choose whichever works best for the forum. 

Restriction of Certain Pokemon

This touches on a few areas I have some concerns with that may or may not be clarified by some facts that I am currently unaware of. To simply put it, I don't know why some pokemon are restricted to start off while others are not. Eevees make sense of course because in the games (prior to gen six) you were only ever given one eevee. However you can start off with a Riolu or a Lucario, while you can't start with any of the aron line. While I understand that Aron are rare, I have never once come across a Lucario in the game that wasn't given to you. And upon reading up on it, it seems to be just as rare as eevee in some cases and in others just as rare as aron.

I also find it confusing that only teachers are allowed to have legendary pokemon. More specifically, I find it confusing why ANYONE should have legendaries. The teachers are supposed to be experienced, yes, but in the games gym leaders are also experienced but they have NO legendaries. Furthermore, this only allows staff to have legendaries while the other players cannot. I understand the reason. Staff as a general understanding are less likely to abuse this privilege. However you are essentially saying only one class of rpers are ever allowed to obtain these regardless of activity. For instance a very active and reliable player might not have a chance or be interested in being a staff member. Should they be denied to have a pokemon others are allowed? It makes more sense to just not allow legendaries as a trainable pokemon. That is not to say you shouldn't include them in events (in fact please do that would be SO COOL to see )

To sum up this part I think it might do the site good to reexamine which pokemon should be restricted as starter pokemon and which shouldn't. And if there is a logical reason I think it should be more openly stated in some part of the FAQ or on the restricted list itself (if there is one then I have not found it. please direct me  )

In General

This is my first pokemon rp site so I am currently unaware of any underlying code of conduct that other's might know about. I just play the games on emulator and 3DS and get experience from that. ^^' These are just some things that I would love to see on the site. I'm not at all trying to rip apart this site, I just have a tendency (with anything I do) to find potential holes in a setting and point them out so they can be clarified or fixed. I hope what I have said here does benefit the staff and the board for future project

[Christof Drescher]

-Hey Lugnugget. 

Thank you for taking the time to offer your suggestions, we do appreciate the input.   We also tend to run things fairly openly on MA, so we don't have any problem giving members a little insight into how the site works, and what our current status is on policies, and features.   So, I will try to sort of let you know where we stand so far on things. 

---

Catching Pokèmon:

This is actually a somewhat tricky subject.  In honesty, if it were possible to set up a way for the capturing to be done in a manner that would spontaneously initiate pokèmon encounters it is something that would likely make things a lot easier for us as well.  However, currently the problems we face for having students encounter pokèmon during RP at random (rather than, if someone earns a thread in which they can specifically go out for catching a pokèmon). 

• Least troublesome of the problems we face is that we are not currently familiar with dice rolling games.  We get the concept of them, but we haven't looked that far into how to establish them, what is available for use to use through proboards, and we haven't figured out a system of what probabilities for what pokèmon in what areas.  The other problems are of greater concern.
  
  ------------------------------------------------------------------------------------------
  
  
• As far as we know, there is no way to set it up so that the site would automatically initiate an encounter with a pokèmon.  While we can imagine how we might like it to look if it were to happen, there isn't yet a plug in, nor do any of us know of a code that would allow us to tell the site to (for example)  generate a random number per action by the player (such as a refresh or clicking the 'reply' button), and by assigning outputs that would dictate the outcome (based on set probability)  all the player to possibly encounter a pokèmon, let alone encounter different kinds or in different areas/times of the day ect.  
  
  That is basically the process the actual game goes through (if I'm not mistaken).  Each area has a preset probability of each pokemon (some at different times), for every step your character takes (in the cave or grassed areas or while surfing) it either generates the random number, or there is a mathematical formula by which the number of steps dictates when some encounter will happen and then a number is generated.  Given the output number that is generated (internally) the pokemon you encounter is determined, as well as any other factors, such as gender, stats, ect. 
  
  ------------------------------------------------------------------------------------------
  
  
• A possible option for us to do this might be to have a member of staff work with the preset numbers, and to manually use a random number generator to determine if a pokèmon is encountered and which one, however there are problems that this would cause on site as well. 
  
  
  • Determining the probabilities and locations for over 500 pokèmon would take a long time, and would be very complicated both to establish and to reference when staff look to determine if a/what pokèmon would be encountered 
    
    
  • Staff would manually need to go in to each thread in every applicable area and run the generator.  this would bring up questions such as,  do we do this in accordance to when the player is on?  If it is time based, do we track time artificially in game,  follow real life time, or do we rely on clues in the RP to determine things, such as if nocturnal or diurnal pokèmon should be encountered?  When/how often should the generator be run, and how do we determine which character in the thread is going to be given the chance to catch the pokèmon?
    
    
  • If we decide that a staff member should initiate the encounter in real time (ie while I am on and the students are on I post something and they can respond to it) this puts some people at a serious disadvantage.  For example, currently my schedule is pretty open, but I'm pretty much never on from 5 am - 1 pm CST.  I am rarely on 2 am - 5 am CST, and flucuate on being on from 1 pm - 2 am depending on work.  Even then, I can't be counted on to necessarily be on this site within that time every day.  Anyone who comes on when I am not around doesn't have a chance of encountering a pokèmon as those who are around the times during which I would make a post. 
    
    
  • It is difficult to assure all players they are being given an equal chance to encounter pokèmon equally.  Honestly, even with the events there is some trust involved, but with those a key can be made, and made to the point that quite without staff being able to remember or figure out which results reveal what, so that it is all predetermined, and therefore can't be influenced by the staff member  retrieving the result.  All staff members are currently considered 100% trustworthy, but if there is any question about it, everything is situated in a way that any funny business could be discovered.  Doing the random number generator could (theoretically)  be manipulated, as (for example ) if I use it, only I will have seen the number.  Let's say (for example) Blaine became suspicious that I was intentionally letting certain members encounter pokèmon more often.  Since only I see the number generator, there is no way for Blaine to say 'Chris, there's no way you saw a  7 this time'.  If, however, Blaine looked at a submission made on Monday (in an event where the day of the week matters, they aren't all going to be like that), and sees that pokèmon X is not available for -any - option on a Monday,  Blaine can see that something is amiss. 

---

Restriction of Certain Pokèmon: 

Starting non-legendary restrictions: 

While many of the pokèmon on the list of permanent restrictions for pokèmon are rare there are also a few other factors involved as to why there are others, and in some cases why some are chosen. 

• Reserved for Earning: 
  
  Many are put on restricted so that staff have a few pokèmon of different types that they can specifically use for events and promotions to help motivate players take interest in events, and to become engaged in the site.  By keeping some pokèmon on reserve for this, we know we have a list of those we don't have to ask ourselves 'can we use this or do a bunch of people already have it?'.  For example, if a bunch of people started with Ponyta, we wouldn't want to use Ponyta for a special promotion.   We chose mostly rare ones, because it didn't make sense to reserve common ones for this, especially since that would restrict their use in regular events as well. 
  
  
• The exceptions to the rules 
  
  There are two pokèmon lines in particular that this applies too.  Most pokèmon lines are able to be put in a generalized group of how rare or powerful they are supposed to be in game, and therefore can be mapped out as far as what stage in the line a student can start with, or what other pokèmon the student can have (even if we do tweak it a bit here and there).  By doing this there are some encouragements for players to start with lower stages in lines, or to start with lines that might otherwise be overlooked if a player can pick any pokèmon freely.  For example, maybe one day I want a  Venusaur for my character.  If I start with a Venusaur though I have very few others I can start with.  On the other hand, if I go with Bulbasaur, I can eventually evolve it to Venusaur -and -  I can start with... let's say a Pikachu.   Similarly, if I pick a more mundane line, like the Ratata line, it costs less for me to evolve it into a Raticade, then if I start with a Scyther and revolve it into Scissor.  One is a more common pokèmon that evolves normally, the other is a rarer pokèmon that evolves in a special way.  
  
  Two pokèmon lines mess this system up to the point that they cause problems.  Magikarp and Feebas are both common, weak pokèmon that are supposed to evolve into rare, powerful, and highly desirable pokèmon.  Including them in the restricted kept us from having to either erroneously putting Magikarp and Feebas in the category of 'rare',  make special evolution rules for the pair of them, or putting Gyarados and Milotic in the somewhat inaccurate category of a 'common line'.    

Legendaries:

• Starting:  
  
  Students are not allowed to start with them, due to the fact that they are supposed to be rare.  A trainer with enough skill to find, battle, and capture a legendary pokèmon would hardly need to come to an academy to learn how to be a trainer. 
  
  
• Teachers and Legendaries: 
  
  Actually teachers are not the only characters able to have legendary pokèmon.  Members have the ability to earn and purchase a staff position character (assuming they can come up with a valid position for the character to hold in the school, and/or valid classes that would be taught in the case of a teacher character). These characters are not students, and are allowed to have legendaries within reason.   Similarly, while the process isn't completely hammered out yet, students are/will be able to work their way up in their 'class' ranking (ie Initiate, Apprentice, Senior Apprentice, Journeymen) and then 'graduate' to a paid 'staff' position (IC not OOC).  These characters would be given the opportunity to acquire pokèmon either not typically or flat out not available to them as students. 
  
  The fact that only staff (OOC) have legendary pokèmon (and only with their staff characters) is more circumstantial then anything. Prior to our putting a guideline in place as too the creation of non-student characters, an individual had contacted us about wanting to play the on academy doctor/pokèmon vet, and would have been able to choose a legendary.  However, this player, similarly, dropped out prior to actually making the character. 

 

---

I know that was probably a lot, but I do tend to be pretty thorough.  I hope that helps explain a bit about the challenges we face, in regards to these topics.  If there are any further questions, or suggestions on these matters or any others on site, do feel free to ask/suggest. It wouldn't be the first time that a member directly or indirectly inspired a feature, idea, or change to the site. 

[Ketra Naideen]

That was all very thorough. Thank you so much. Blaine also clarified some things for me over skype which was very helpful :3 I still have a few things to bring up especially with catching pokemon. I'll try to address everything you stated, but I might miss some things XD



Pokemon Catching



Blaine also filled me in a bit about this in a skype conversation. So prior to anything I say I would like to add that I hear you conduct the choose your own adventure games and I think that's a wonderful addition (for lack of a better word) for the site and I would definitely keep it here Also I hope that if these random sightings are implemented that they may increase player activity. At the same time I understand other concerns about why it might not be the time to implement it or why there might still be some concerns, but if this was a possibility this is some way you could do it.



First there is no I can see this as being at all as complex as the game itself (unless of course someone on the staff has a supercomputer for a brain then MAYBE it will work XD). As you said the automatic plugin would be difficult to code and possibly very easy to get around if it had to do with refreshing the page (all the while again it could not be nearly as complex as the game itself). So now we're looking at the staff manually having to roll for each pokemon which again poses its own hassles. It wouldn't be a flawlessly simple process but it might be manageable.



1) Limit the staff workload with each pokemon catching thread

I don't expect you guys to take on ten of these threads at one time (especially with the work you already have to do). So therefore you can either limit the threads or limit the work you have to do. I seriously think that the pokemon that's being caught should be an NPC (played by either staff or player). If the staff alone control the pokemon, then perhaps you would have to directly limit the number of threads on the site for catching pokemon. IE players would send in a request to catch pokemon (having bought pokeballs to do so) and say the first five requests can catch pokemon, while the rest will have to wait their turn. While this isn't ideal it does prevent you from attending 10 threads at once for that area alone. On the other hand you can also reduce the workload by using other players to play the NPC's. You can encourage players to play these NPC's via point incentives. The most you would have to do is go through whatever way of choosing which pokemon occurs/if a pokemon occurs (if you want to go that route) then notify the NPC player what the situation is and they can play it out. I honestly have little idea of what you could do if you wanted to incorporate no pokemon occurring. You might also have to judge certain pokemon battles to see if the pokemon was caught or not which might add more to your workload, but still possible depending on how you do it.



2) Limit which pokemon occur at which time/place

I barely touched up on this in my previous post since I was going over it in general. Again, highly unmanageable to incorporate calculations for 500 pokemon at one time at one place. If that were possible then woot! But honestly it's not. Therefore it might be best to limit the number of pokemon at a given time by cycling out which pokemon go in which area at a given time. For instance say in one of the fire safaris you have Charmander, Pansear, and Growlithe in for one month, then the next you switch to Ponyta, Houndour, and Cyndaquil. At most you may need to keep a running list if you don't want to overlap which pokemon occur. Mathematically speaking: we have 500 pokemon and we need to cycle into 12 areas (by my count). If we have 3 pokemon in the 12 areas at a time we cycle 36 pokemon in for a month. So in 14 months you should be able to cycle through all the pokemon. Yes a long time, but it adds to a constant variety. And furthermore you can perhaps keep the rare pokemon out of the mix and save those for the events you can bring about that is separate from the random pokemon catching. You might also want to exclude starters (since you never really come across those in the game), or furthermore keep only the commonly found pokemon as catchables mixed in with a few uncommon ones. All this can be modified to be easier.



3) Limit the number of times a pokemon trainer can catch.

Not a popular method, but again it'll probably be annoying for someone to finish a thread, be unsatisfied, then go at it again five more times. If this is an issue, then you can limit the times a pokemon trainer goes to the safari and requests to catch a pokemon. Perhaps two weeks after they have caught/not caught they're pokemon they can go again. Again this is not a fortunate way to manage this, especially when the player goes away without a pokemon and has to wait for the next cycle. Another way might be to allow a player x times per month to try to catch a pokemon. Again there would be some difficulties especially if the player's threads overlaps into the next month and then they can try X number of more times (don't you just love how I poke holes in my own argument solutions XD). Not ideal, but another option. Please keep in mind that this might work well with the in character trading. Say trainer A catches an ekans. Trainer B really wanted an ekans but didn't get one. Trainer B can still trade trainer A for an ekans.



4) Other complications

Now you mentioned something with time and day of the week in which pokemon appear in the game. As much as I tend to be a stickler for the gameplay (so much so I get confused on this forum because of the necessary differences between the game and pokemon rp ^^) I say disregard those completely. Makes things way too complicated. So what if hoothoot happens to fly by day (moreover the thread might be more amusing if poor trainer stumbled upon a cranky sleep-deprived hoothoot XD). Including the date/time IRL specifications would make things very unreasonable and complicated for a system that will have flaws. As for what you said about staff reliability, that's something that will be an underlying issue, and I'm glad you brought that up. I honestly have no sure fire answer to combat that except that we're just going to have to trust that the staff will be unbiased and fair in this regard. But then I think forums rely on them for most things. Typically it's a staff's job to judge fights, accept characters, and settle disputes. Sure it's easier to lie with a random number generate and the bias might not be so transparent, but it's a risk. And if it's an issue then it'll be dealt with.



To conclude on a more cliche note: not everything's perfect. Even I poked holes in this pokemon-catching system I thought could work for the site. Heck I might have even missed some points you previously made (I swear I tried to cover most of them). But I would be willing to risk a bit for this. As the system is now, there isn't much pokemon catching save for events (wonderful events) that happen once a month. Yes this is an RP site and not the actual game. And you guys have done a lot to add and implement aspects that make the game more exciting to the players. I just think with a few modifications this might be possible to implement as well. So if you decide to consider this for the future, those are just some methods I would use to make the system workable.

Restricted Pokemon

I understand that there may be some restrictions regarding pokemon as starters, but it's still very vague as to why these pokemon are restricted. If you guys are going off of what's popular, personally I find the pokemon Lucario to be a very popular pokemon so why is that allowed to start off with over Absol and Aron which I don't see as being as popular or rare. They might be, and I don't know. What I mean to say by this is that pokemon can be restricted to start off with. But as a person who was applying and who is new to the site, I was very confused as to why they Aron line was permanently not allowed while Ylva has an Aggron on the site. Of course she might have got it before the rule was made which is of course understandable. Like I said, I am completely fine with the restrictions as long as there's a reason. I don't think it would hurt to look it over or include a reason as to why each pokemon is permanently restricted that people could see, because in all honesty it's not completely apparent to me.


Legendaries

I totally do not expect legendary pokemon to be starter pokemon. My only concern was that players were incapable of ever earning a legendary while the staff could start off with one. Thank you for clarifying And sure enough Luggy looks at the store board and finds where you can purchase a staff/falculty member XD

[Christof Drescher]

This may be just a bit rushed, I finally finished the thing I was working on that I mentioned. It took a bit longer than I had expected x___x  

---

Catching Pokèmon

Coding

I may not have been clear, while I do have a pretty good grasp on what are likely ways that the programming would go about achieving the random encounters, I (and other members on staff) don't have any way of knowing how to do the actual coding.  In general, I am very good at understanding the 'thinking' process of the computer as it goes through the code. For that reason, I can theorize how the actual game might go through the process of determining when there is an encounter, and what it might be.  


        I can tell you that first the pop up box/message would need to be established (ie just the item that is a popup box and nothing more, with things like color, size, ect defined).  It would need to be told that action   x  results in random number ___ through ___  to be generated, thus establishing the input. The code would then need to say to 'retrieve' the input, and compare it to a number of if-then(else) statements,  the if part being based on what would reflect our desired probabilities.   The seemingly easier way would be to relate the ifs  to a mathematical formula, however that would require one to be careful about the placement of the statements so that any overlapping qualifies would yield the result desired (ie, one if is 'divisible by 2', one if is 'divisible by 3', which one is used for any number divisible by 6 will depend on what order the statements were placed in the code).  The other way is to straight out assign numbers.  

      This would look something like:    
                    (not in code just the concept)
  
            go look at the number generated (1-3)
                     if 1  then charmander else
                     if 2 then squirtle else 
                     if 3 then nothing

                 Simple in this form, but crazy when you want different probabilities
                  and have multiple possible results.


               Then it would need to tell the program to display the result to the player.  Either it would tell it straight out (if possible depending on the output), or there would have been outputs established prior with a title that would then be referenced in the code as ... if  x  then *insert result denoted by 'title y' *  Most likely the best way (if it can be done this way) would be to tell the out put to consist of two parts, one would be the text message(and whatever bells and whistles) that would be pre-established by title  as it would need to vary by which pokemon is encountered (if any), and the second part would be the embedded  dice roll system or whatever would be used to determine if a capture happens.   The dice roll system probably would also need to be pre-established and referenced, though where I'm not sure, so that it is then merely told to access it at this point in the coding, and how it should respond when the player interacts with the dice roll program on their side (this would require establishing a button and any animations if desired, the number generator for dice of n sides, making connections between the fact that the program should run the generator when the button is pushed, and then what all it should do given the number that is drawn up).... From that point, honestly I don't think there is anyway for us to tell it to take the process further, given what access we have to the underlying systems in proboards.  Ideally, if we had limitless access, we could tell it to, somehow add the captured pokemon, or to message admin about the capture so that we could complete the adding of the pokemon to your profile specifically...  that aspect of it, while seeming pretty simple, as I can map out in my mind how it works; however, is not nearly enough to actually actually create such a code.

 I am only vaguely aware of the language needed for if then (else) statements, and at it is a specific coding language.  I don't know all the variables that would be necessary for establishing the visual announcement box, nor what order the variables are expected to go in.  How one initiates the establishment of any item, or tells the code to 'retrieve' information  I'm also not sure of.  To that point, there are the things like,  what symbols mean what in whichever programming language the system would be expecting me to work with (of which I'm not even sure).  Furthermore, I don't have a program to work with to actually create the code, so, even if I knew a lot of the coding, there is nothing for me to run quick tests with, or to verify that I have closed all of my fields, and satisfied all anticipated variables in any established items. 

---

Manual 

Manual, while not possessing the same difficulties in creating the system itself, actually comes with a whole bunch of problems and undesirable situations that don't present themselves with the coding. 

• If any one (staff or member) is relied on to manually RP the scenario, there is the possibility that the player may find his/her chance to capture stretched out over a long period of time and/or inadvertently 'dropped' if either player becomes unavailable (for whatever reason) before the thread is finished, and/or players find themselves on at differing times. 
  
  
• If threads must be requested, they cannot occur naturally (ie if two players decide to go RP for fun somewhere), this can also result in a 'back list' of players waiting for their chance well after they've earned it.   These factors are discouraging to players. 
  
  
• If existing threads in appropriate areas are selected, either they must be done at random, or admin must keep tabs on how often, and who's threads have been selected to try to make the opportunities equal.  Either way, the problem presents itself as far as, which characters in the thread are the ones who are earning the opportunity, and what factors determine when an opportunity is earned. 
  
  
• Once the factor of who/when are determined, they will either be kept secret (which may frustrate players who have no idea if they are even doing what needs to be done to be considered for a potential capture), or revealed, which depending on the method can result in problems such as over flooding of meaningless threads/ posts (ie lets say it is known that every five threads at four posts or more results in our running the generator, members may then start multiple threads with a partner with no interest in RPing past the point that they have 'forced' the generator to run and have or have not encountered a pokèmon)
  
  
• Obligatory engagement may overtax those playing the 'NPC' parts.  Regardless of whether it is a regular member or a member of staff, finding one's self in a position where they have  x number of threads they are engaging in out of obligation and not for fun or interest (and without the option to exit when desired ), can cause an individual to put off returning to site due to not 'feeling like' continuing but also feeling unable to do anything else while their obligation is not being met.  Further more, the number of these one is involved in may hold up RPing in other locations.  Let's say, for example, I am running five of these threads, it may slow down my posting in actual threads my characters are involved in, and hold up others who are waiting for me in those threads. 
  
  
• Limiting of number of captures, and cycling pokèmon (done to simplify workload) require additional measures to be taken to keep tabs on these factors.  Furthermore, simple as it sounds, merely organizing all the pokèmon in these lists can be challenging.  It is definitely one of those things that sounds simple but then turns out to be insane.  I know this, as I personally had thought of doing something 'simple' in going through the list of pokèmon, and just deciding where in the real world (and in what environments) they were likely to to be found, so it could be established on site.  I literally got down to listing out the 'mons by national index number, and creating the categories in the table, and after that, only had the gumption to actually puzzle through a few of them; especially, as I realized that the only way it would be useful was to make a dynamic table, in which I could have excel display the information based on things like 'what area' I was interested in looking at, or (for example) if I wanted to just look at bird pokèmon.  In concept, even that is simple, the problem is with so many 'mons, it's just too much. 

---

---

                 

   Restricted Pokemon

         In honesty, the information as to why the ones we permanently restrict for starting is pretty much irrelevant.  We don't have a problem with disclosing things but... well looking at everything I typed above (I really meant to keep it shorter x__x )  I think you can see that I have no problem with mapping out a number of 'reasons' for anything (whether I agree or disagree with it actually ^^; ).  There is, however, a point in which one is simply telling people too much.  It either overloads them, or makes it seem like one has to justify every decision one has made.  It's different when someone actually comes to ask a question about it themselves, rather than when one is posting information that is deemed 'for everyone to see as a matter of joining the site'.  

       Initially there were two permanently restricted pokèmon officially (we'll ignore the hot mess that was going on behind the scenes at the time), the pair of them were both for the same reasons, rarity, popularity, and wanting to have a couple pokèmon to award specially every so often.  The decision to expand this number came from the fact that we had two types represented in the 'specially awarded' ones.   It seemed odd to not have at least the majority of types represented, as people might have type preferences. For that matter, it simply seemed like a good idea to have a few more for this purpose.  Which ones were chosen had various factors involved, such as perceived desirability, perceived strength, rarity  the before mentioned reasoning of the Magikarp and Feebas line, and there is one that was chosen, honestly, because Bulbapedia's information on it looks really wonky (it has a -lot - of listed immunities, and I can't seem to figure out why for most of them) and I want a chance to look into what's going on with it (if it's inaccurate I'd like to know, and if it's accurate it needs to be restricted anyway ).  These factors, however, only helped determine which ones were selected to represent the types (in nearly all cases). 

       The Aagron line, specifically, was indeed added after Ylva joined with her character.  This list was expanded recently, and in fact there is one other character who requested a pokèmon previous to the list being put out, that has dibs on being able to start with one of them (because it was approved before the list was put out, and the character would have been created if proboards would have stopped swallowing his app ).  Because this list was put out after the fact, there are notices that even indicated (both in the picking starting pokèmon guide, and I believe in the restricted list) that these are subject to change.  This is possible due to the fact that with over 500 pokèmon there is the possibility we will come up with another one or more than need their status to be changed in some way (whether it is restricted status or what else can be chosen to start with it ) , or we might simply choose to change which ones we want to have on reserve for special awarding, for whatever reason.  As too why Aagron was selected, honestly, most steel types looked like they could have been selected, and I was torn between Aagron and Skarmory, as both were steel types that seemed pretty impressive, and were ones I didn't need to go looking for to think of.  Not sure which to pick, I decided.... 


1. since Aagron was a full line it made more sense to give that one out specially than a pokèmon with a single stage

2. Ylva seems to really know her steel types, so I would defer to her judgement on which would be a good one (though I didn't actually ask her, or even let her know I'd taken her opinion into account in my decision XP ) 

---

---