After a month of implementing the Threat-Response AI I am still having a lot of fun! I have expanded its scripting capability to add more nuanced behaviors. Although I haven't used it very much, as long as I have the hooks in I can get back to it later. Finally, during April I switched my database to MongoDB. This is a document-oriented database that seems to line up with my data better than our standard relationship database. Most importantly it will allow me to save data a lot faster.
For the month of May my big goals are a) fix everything I broke in April, and b) get my rest service up and running. For point A, I often program in a "Build-Fix-Build" style where I first the ground work for a new feature without worry about how it will disrupt, or break, older features. I try to keep the new feature self-contained, but that isn't my focus. I will then go back and make sure other features are still functioning and fix anything I messed up. Finally I go back to the new feature for any finishing touches. I enjoy this methodology because it allows me to focus on making new features as complete as possible, then gives me the chance to review my past work in light of recent code changes. I have heard the term "tech-debt" used for the fix stage, but I consider it less debt repayment and more of a review, spring cleaning, or editing process. Often in the fix phase I rework old features to utilize some of my newer code. In this current phase I broke how buildings are destroyed & rebuilt, as well as how units are created. Both have been needing updates anyways. I think I can eliminate a good thousand lines of code of classes no longer being used.
Once I'm satisfied with my fixes and the final touches on AI, my next project is the Rest service. This is a brand new server component that will fulfill any stateless needs of the system. Things like account login and most of the information screens. Examples of these screens include unit reserves (storage of a player's units not currently active), player lists, unit information, and account/player information. For many of these screens the client needs to request static (or mostly static) information. Ultimately this is the foundation for the ability to create units, resurrect units, and see unit stats; really fun and visual aspects for the game.
I'm really hoping to complete this all in two or three months, but I haven't decided on what to make the Rest API out of. I could stick with Java, but I'm fond of Python for this as well. We'll see.