Trent Polack's site for cats, games, game development, and undeniably powerful sociological insight all with a healthy dose of narcissism.
Almost Finished
Published on March 17, 2008 By mittens In Game Developers

At this point, I think that it's fairly safe to say that the meat of Asplode! is finished. All of the primary gameplay is in place, the enemies are all implemented and handled in a state that I'm fond of, and the player controls, responses, and such are all implemented. At this point any more features that I add to the gameplay portion of the game are either polish points or experimental ideas that I may or may not keep as part of the game (a few automatic weapon upgrades, various ideas as to how to handle the score multipliers, and whether or not I'll allow the player to acquire more ships/lives as the game progresses or not). I mean, I still have to add the main menu, restarting/quitting mid-game, and handling option changes dynamically instead of by text file and such, but unless there's something I'm vastly underestimating about this process (I'm not having a fancy UI or anything), it shouldn't take more than two more weeks -- as I'll be gone all next weekend. That all said, what I'm struggling the most with right is performance. The game runs smooth and excellently for the first two-three minutes but, shortly after the two-hundred second mark, it started chugging something fierce. My first response earlier this week was that it was, obviously, the particle system and its insanely inefficient rendering method where I filled a vertex buffer per-system and then rendered the contents (per-system). I remedied this by batching all of the particle geometry together into a single write-only vertex array/buffer indexed by a static index buffer and rendered all of the contents in a single draw call. The number of particles doesn't generally spill over into a second batch but, even as a worst-case scenario, that's two draw calls total for that. Pictures from that experiment (this actually went really well and I only had one screw-up):



That improved the overall framerate a decent amount but it still was, clearly, not the main problem. The only other huge graphical culprit that could have been causing a problem were the vector model rendering routines. When I started looking over the source code I realized that these were the first things I wrote when I switched back to XNA after my D3D10 experiments and the code was absolutely atrocious. I had two draw calls per every model and, on top of that, I was generating data for each of the models from the source XML data whenever a new enemy was created. So, not only was I reading and parsing the XML data but I was generating all the geometry from the minimal data in the XML. It took most of Saturday to sort out all of that and batch the model rendering routines together and, in the process, I made a number of pretty-looking screw-ups:



This gave me an enormous overall boost and almost a quarter reduction in the total memory usage of the game by the 250 second mark where, as of now, it's now running about 45-50fps on average (but on my pretty-decent machine). This is an enormous gain from where I was at a week ago, but I still have a number of other optimizations that need to be made. To start with, I'm going to eliminate all dynamic memory allocations made during the course of the game to the best of my ability; I may not be able to account for cases where games go on for a very long period of time but I can, for the most part, account for a hefty majority of the gameplay that most people should see. Luckily for me, I'm a pretty good shoot-em-up player and, I figure, if I make performance perfect for the longest game I'm able to play and then some, I'll be in good shape. I'm officially declaring the game in beta testing status as of now and here are some screenshots from a playthrough an hour or so ago.


No one has commented on this article. Be the first!
» 553
» 0
Sponsored Links