This is the second Flash game I have done as lead programmer. This project has such a wide scope that it allowed me to learn some more advanced programming theories behind game development. For the Purchase Screen, where you buy all of your items, I am pulling all the info for each button from an XML document. In a racing minigame I have opponents with pathfinding AI. The same AI script is being used to show the player the correct direction to the goal in real time. I also learned a great deal about managing programming tasks. This was especially difficult since I am still learning too. Not everything made it in to the game, but I will discuss what was meant for the game, whther or not it got in, and why.For some discuassions I will include links and pictures to mini-gamme prototypes, and early builds. Also I will not go into too much depth about art since I helped in that area very little.For Reference purposes when I refer to following names, this is who I am refering to: Alan Guy, the other programmer on the team; and Tony Urso, the Producer.
When we started makking all the items the player could buy I realized we obviously don't need each object to be using up the whole button worth of graphics every time. There are about 100 items or so and I decided we would import the image of the item and some stats about it from XML. The reason I wanted to do this immediately was so that I could have code bringing in items slapping them on a button and filling in the space until all the items were used. I feel this was the single best decision I made during this development. From that initial XML list I have been able to work on other areas while a designer or producer edits the easy to read and edit XML. This way the balancing, adding, and subtracting of items was far more efficient and done by non-programmers. When they were done they just needed to replace the game's XML with their own and it worked, with no intervention frommyself or Alan.
The scope of this game is what gave me the free roaming territory to tackle new and exciting challenges in the programming arena. I enjoy the challenge of making an eve bigger game than last time. This game has minigames! That in itself was a pretty enormous task. Having mostly completed a pretty big game makes me less intimdated to take on projects that seem out of my reach. Before FC was finished I attempted to make a multiplayer flash game using XML and PHP. It worked, but is in a very protoyped stage.
This game had a scope bigger than any other in the class. All in all, this game really one-step away from being a full blown RPG. As it is set up now the player has access to each area of interaction up front at anytime. If we take away this access and give the player control of an avatar in an environment, then we can hand out items and experience upon completion of tasks within that environment.
One of the things that most excited me about this project was that the racing game called for some AI. The design document for this minigame was just a storyboard with controls written on it. But they wanted a city map of roads with multiple landmarks to be used in different scenarios of the game. Also it was visually zoomed in so the player couldn't see where the final goal was. This meant they would need some kind of guidance system to tell the player which way to the goal in real time and changing based on wrong turns, or short cuts taken.
For this I fuond a pathfinding script called A* or A-Star. It basically takes a grid on moves to the next spot that is both closest to the goal and not a wall. It can also be customized to give tiles specific risk values. This means a wall is 100% unpassable, but a pit of fire is more like 70% passable, and the script plans it's route accordingly. For this game we only have implemented walls, though grass and sidewalk areas may be potentials for expansion.
This script was also used to generate a path for the enemies to travel along. The #1 prototype represents this build. The level in this first build was designed by me shortly after the first working build. You just have to beat the opponent to the goal. His movements are more precise but slower than the player's making the level design key. At the beginning the player smokes the opponent, but then as the roads cramp and get mroe complex the difficulty automatically ramps up. The opposite is true for the second prototype.
#2 is a map created by Tony, the producer, after discussing and going over the structure of the game and the level layout. I enjoyed this map a lot during testing.
#3 Prototype is one I made, that #2 is built off of, to show the design team about how much pull they had with drifting.
#4 Prototype is showing an instance where the player and the opponents have to stop by one point before heading to another point which was the goal. The design behind this concept was You and your co-workers all take off for lunch and you try to beat them back to shorten your lunch break and improve productivity.
#5 prototype is a demo of the game zoomed in and with the nvironment moving around the player instead of vice versa.
We originally planned on having 9 minigames. 3 different games for each of the 3 bars that steadily increase throughout the game. Those 3 bars turned into 2 that steadily increases and 1 that fluctuates greatly. So we ended up with a game for each career level up and a game at the end of every turn. First was the racing game described above, this is the career advancement opportunity game. Next was the mail sorting game and the race to the elevator game. Both have only programmer's art. These games are decent games but the problem is there were not enough of them. The Racing game, although it gave me insight into the next stage of game programming, took way too long and was far too complex for this project. The main reason I did not get to spend more time on games, I feel, is because of everything I had to do for the main game.Below is a version of the catch the elevator game, I don't have a build of the mail-sorter, Alan wrote it.
