ChimaeraMechs

What Went Right - There were many features I was initially concerned with in regards to implementation. Often I was able to program the design exactly how I thought it through in my head, and it would work on the first build. This of course becomes more common as your programming experience increases, but it is always a very good feeling nonetheless. One instance of this was the ability to implement a particle system from another project with minimal editing of the code required. Not only was I able to get a dynamic flame for my hero's jump, but I was later able to re-use the particle system to create the dust trail that follows the hero. With more time I had intended to expand the particle system to include some features for the boss due to the fantastic look of a particle system with minimal effort beyond the inital class construction.

 

As is stated in the earlier parts of my updates, this project was built using the Microsft platformer starting kit as the engine. The engine gave me tools such as the text level designer, graphics animator and the physics collision. There were some bugs in the kit, and not all the features were included in the basic version that I had downloaded (such as the vertical scrolling which had to be added on). I built a lot on top of the engine, however, and learned the code for the engine well enough that I could recreate it if neccesary. When I went to fix the bugs from the kit (one of the bigger ones being jumping), the fixes ended up working well and quickly which is unlike my usual experiences with attempting to fix others' buggy code. This could have been due to the neatness of the Microsoft code, or even just due to its general bareness and my ability to add as neccesary without causing other problems to arise. Starting with some basic code ending up being very useful in the long run due partially to the tools that were also including, but also allowed me to see how things were done (correctly) in the code already and mimic them in my own functions.

 

The biggest, and luckily very successful, changes done to the starter kit were done to the hero and the enemies. In the original kit, the hero can run and jump, enemies can patrol without falling off ledges and heros running into enemies results in instant death. I was able to change this into the ability for both the hero and enemy to attack each other, do damage and be defeated. This did not require much change to existing code which kept me from changing anything that caused backlash in other parts of the code. The additional code that was added, however, did not have any issues and many of the calls already being made for the hero and enemy were in a great position to call the additional methods added. Classes that were completely new to the kit included my weapon, bullet, boss, pickups, particle systems and math library.

 

What Went Wrong - One of the first issues I ran into was that of being able to shoot at any angle. Due to my testing platform, this feature was difficult to test and use due to not using a mouse. Instead, the shooting was changed to directly in front of you, which allowed for easier balancing in the levels and enemies. I would have preferred to use any-angle shooting, but the alternative provided a better game for the intention. This of course led to a slight redesign of the game vision itself as it now became a game in which enemies must be in front of the player as opposed to placed anywhere. This led the design to follow more of a retro and simplistic design that was a good project for a semester long course.

 

Another big issue (that never was fully resolved) were the issues with Monogame + Windows 8.1 + VS 2013 and how sound worked. To get any sounds to work, they have to be converted from their wma/wav format (mp3 seemed to cause issues) to the xnb 'compiled' format. This can not easily be done and required a seperate (luckily found in my last semester) program to do the conversions. Just converting sounds, however, was not enough to get them working properly. The method for songs and soundeffects slightly differed, but the general tasks were similar. Both required both the original file and the converted xnb file to be placed into the output (bin folder) content prior to running the program. Due to debug and release mode having different content folders, the files were required in both for debug and release to run properly. The main difference in the song and soundeffect issues seemed to be that soundeffect xnbs had to be included in the project, but songs have to include the xnb and the original file (with both set to copy to output folder). When songs were made to play (using the standard MediaPlayer.Play method), they would do so without an issue, but when a song was stopped and a new song attempted to be played (such as changing of states), the first song will restart and play until completion before the start of the next song. Since most of my sound changes were done near the end, there wasn't enough time to resolve the issue or create a work around.

 

With working along, I was able to be involved in every process of the programming which was good due to my somewhat limited skills in that area compared to others at my same level. This meant that there was lots of time spent resolving problems that were relatively minor, but would take some reaserch or 'tinkering' with the code until they could be fixed. This also would often result in me not being able to spend as much time and effort on the art and design side as I would like. Many weeks I would be fixing issues until the due date and then trying to get the weekly art updates done in the last evening or two. This resulted in both not getting the time they required to be the best quality possible, but for a single developer game, I am happy with the overall results. There were some problems that I only overcame by asking for assistance (usually online but occasionally of classmates) and this often resulted in a slightly better understanding than the often quoted "Why did that work?". The constraints also limited the amount of the overall design that could be implemented in the timeframe. Many of the things left out were relatively minor, but would require art, sound and some re-do of large code areas to be considered complete. Such things include the coin pickups (which are relatively useless currently) were going to be replaced with health, roar and ammo pickups. This would have also required implementing an ammo system (and doing a minor amount of testing due to only 5 short levels being implemented). I was able to include a boss as originally intended, but was unable to put the effort into the AI that I had originally planned. The full centaur body and movement was removed due to issues with the melee enemy cutting into the time, but was replaced with a predictable up and down turret-like motion. The levels were are smaller than planned (mostly in time frame although also in physical span), but most likely would have required including vertical scrolling to make the levels more manageable to create. Luckily I was able to prioritize the features I wanted or needed and this allowed me to simplify any features I hit a time or skill constraint on.

 

Most of my 'what went wrong' boiled down to using XNA (through the fan made Monogame) which is somewhat between being phased out completely and being updated to run on the newest versions of Visual Studio and Windows. This was a software I was familiar with that helped re-expose me to the game loop based design prevelant in many common design engines. Due to the issues with XNA, I do not intend to pursue this project for my next level of Studio and will instead look towards UDK or Unity. XNA has always been an easy way to get 2D onto the screen quickly with the power of the C language behind it. Now that it has become less effective in producing release quality games at the same standard as most indie companies, it is also becoming less used. By using Unity or UDK, I hope to still be able to make 2D games when I want to, but with a graphical implementation that compliments my design style much better than text lines of code.