Good:<\/strong><\/p>\n I finished with a playable game.<\/p>\n
I had an extremely limited feature list because I knew everything was going to be complex and I was able to implement everything in the time allowed, with the exception of the status display for the selected units…<\/p>\n
LibGDX worked great<\/p>\n
I used an MCV architecture to split the model, control, and view pieces of the code. \u00a0I can now make changes to the visuals and UI without rewriting any back end code.<\/p>\n
I stepped the graphics back to a pixel look and I think the final product is better for it.<\/p>\n
Bad:<\/strong><\/p>\n I had no framework for structuring my code. \u00a0I would forget what a method did what and accidentally call helper methods in the place of main ones, which would cause all sorts of problems.<\/p>\n
The aforementioned bug. \u00a0I can’t duplicate the set of circumstances that cause it so I can’t troubleshoot it<\/p>\n
There are no win or loss conditions since destroying the power stations is impossible.<\/p>\n
I didn’t have time to make my own music, so I grabbed some from opengameart.org<\/p>\n
So-so:<\/strong><\/p>\n The AI. \u00a0I’d never written an AI for an RTS before. \u00a0This one is actually almost completely random but actually puts up a fight, which surprised me. \u00a0It is easily exploitable, but for about 20 minutes work I’m happy with it.<\/p>\n
The instructions are ok for explaining what to do, but not how the units interact with one another.<\/p>\n
The UI is getting there. \u00a0It needs some work to really give the player a clear picture of what is going on.<\/p>","time":"July 31st, 2013 6:28 pm","title":"Power Grab Postmortum"}