In general, we went over what I had brainstormed as a rough idea for the project structure and design philosophies for the project. Everything that was gone over can be currently found in the wiki. The basic design philosophy that was stressed was to run the program as light as possible, and to avoid redundant data. We talked about using polymorphism and inheritance as key design concepts, creating base classes that have all the data and functions needed, and then creating derived classes from those base classes. These derived classes will the manipulate the data in whatever way they need to act as expected.
The sited example was a standard pokéball vs a duskball. Where on throw, a pokeball only needs to do the most basic type of calculation that a ball does (takes it's catch rate and compares it to the wild pokemon's stats), a duskball has conditional behavior. It works best at night or in caves (or basically any dark place). Rather than having one pokéball class, who's every function would need to contain massive if statements, it would be better to create derived classes from a base class that has all the necessary data and functions to operate.
New Ideas
I brought up the idea that there be a very small "container" sort of class for the backpack. This container class would simply hold 2 integer values. The first value would be the item id, the second would be the quantity of the item. While we could accomplish this with some sort of multidimensional array, I think that a small class would make for a solution that is much easier to read and code (and a quick look over StackOverflow seems to agree with me).
Before the meeting Brad brought up the idea of breaking the game down into regions, rather than just all areas. Which sounds like a really good idea. If for the text based duration of the project, the user is entering index values for what area they want to move too, breaking the game down into regions will keep us from entering commands like goto 511 into our program.
Task Assignments
Brad will take on blocking out the base classes for the standard items. Things like potions, battle items, status healing items, repels and anything else that would normally go in the "standard items" pocket. These won't see use in our initial test, but will be helpful as we begin to expand into the next phase of our development.
Eric will be handling writing out the xml file for at minimum the first 25 pokemon. I probably won't do too much more than that, as the structure is positively going to change, and I might make more work for myself by getting too invested. I will also create the C# code that reads in the xml file.
Sean will be handling the classes that relate to game structure. Things like GameWorld, Region, Area, Building. Building and especially Area may benefit from creating some sort of base class for them. As Areas will need to account for both towns as well as routes. Which are functionally different.
A last note before everyone gets started:
Please remember to branch your work off the master before you get started, and if you decide to do more, make an issue for it. So we know what has been done, what's been worked on and who's been working on it. Other than that everyone have fun, and write awesome C# code!
Our first group meeting With: Brad, Eric, Sean
Overview
In general, we went over what I had brainstormed as a rough idea for the project structure and design philosophies for the project. Everything that was gone over can be currently found in the wiki. The basic design philosophy that was stressed was to run the program as light as possible, and to avoid redundant data. We talked about using polymorphism and inheritance as key design concepts, creating base classes that have all the data and functions needed, and then creating derived classes from those base classes. These derived classes will the manipulate the data in whatever way they need to act as expected.
The sited example was a standard pokéball vs a duskball. Where on throw, a pokeball only needs to do the most basic type of calculation that a ball does (takes it's catch rate and compares it to the wild pokemon's stats), a duskball has conditional behavior. It works best at night or in caves (or basically any dark place). Rather than having one pokéball class, who's every function would need to contain massive if statements, it would be better to create derived classes from a base class that has all the necessary data and functions to operate.
New Ideas
I brought up the idea that there be a very small "container" sort of class for the backpack. This container class would simply hold 2 integer values. The first value would be the item id, the second would be the quantity of the item. While we could accomplish this with some sort of multidimensional array, I think that a small class would make for a solution that is much easier to read and code (and a quick look over StackOverflow seems to agree with me).
Before the meeting Brad brought up the idea of breaking the game down into regions, rather than just all areas. Which sounds like a really good idea. If for the text based duration of the project, the user is entering index values for what area they want to move too, breaking the game down into regions will keep us from entering commands like
goto 511into our program.Task Assignments
Brad will take on blocking out the base classes for the standard items. Things like potions, battle items, status healing items, repels and anything else that would normally go in the "standard items" pocket. These won't see use in our initial test, but will be helpful as we begin to expand into the next phase of our development.
Eric will be handling writing out the xml file for at minimum the first 25 pokemon. I probably won't do too much more than that, as the structure is positively going to change, and I might make more work for myself by getting too invested. I will also create the C# code that reads in the xml file.
Sean will be handling the classes that relate to game structure. Things like GameWorld, Region, Area, Building. Building and especially Area may benefit from creating some sort of base class for them. As Areas will need to account for both towns as well as routes. Which are functionally different.
A last note before everyone gets started:
Please remember to branch your work off the master before you get started, and if you decide to do more, make an issue for it. So we know what has been done, what's been worked on and who's been working on it. Other than that everyone have fun, and write awesome C# code!
Cheers, -Eric