1. First public version of Aggro Tactics... sort of...

      written by Ray Benefield
      HAHAHA! I did it (link below... but I suggest you read). So things have been quiet around here for a long while... and not just around here either. The team has been awfully quiet. Probably because there has been little to know progress on actual game code. For the past couple months I have been doing a lot of research and learning. When I built Aggro the past couple times, including this most recent start in like December I was doing it all wrong. The codebase was rigid and what we call spaghetti code in the Software Engineering world. This approach would do nothing but cause problems going forward. So my research and prototyping has all gone towards setting up a better architecture for Aggro's code base.

      The Original Problem

      So a lot of those that would read this on RP probably don't know much about software engineering, so let me try to offer a decent metaphor. Imagine having a ton of building blocks to build a map in a game. One set of building blocks are extremely complex and essentially pre-built objects, like buildings in Reach/Halo 4's forge editor. The other set is nothing but simple blocks, various sizes of rectangular prisms, ramp type objects, wall type objects, etc. As a new map designer, the first thing most people jump to are the pre-built objects. I've seen it from experience... maps are built mostly out of the pre-built objects. But as time goes on, you learn that those objects are not as flexible. Perhaps you want a door on the left side of a building, but the pre-built object can't be changed. So you start to learn to build with the basic objects instead. Except doing that is frustrating at first, because it never looks nice as it is sooo simple. However as your map design career moves forward you start to learn little tricks to make things built out of the simpler objects cleaner and cohesive. Working with the simple pieces becomes a huge skill to produce elegant designs.

      That is essentially what is happening here. Most programmers start out building massively complex objects first and then find that those objects just aren't flexible enough for what they need. It takes time to learn to create those simpler objects and then time to make them work seamlessly together. The past iterations of Aggro were so rigid and inflexible, that when I wanted a new feature here in this pre-existing part of code, I would have to go through a lot of work to get the results I wanted rather than just shift a couple pieces around to add it. I found myself re-building stuff I previously built rather than just adding new stuff. What you notice is that development gets slower and slower as time goes on. It sucks, and that is why I would get so far into the game code and then just have to stop working on it and restart.

      So this time I'm approaching it differently, at work I was introduced to the SOLID design principles for software engineering. And those principles have changed my life. It taught me not just techniques, but introduced me to new tools that I couldn't even imagine existed before. SOLID is essentially how we go about building those smaller pieces and then how to tie them all together so those pieces are re-usable. Sure building a city with pre-built city with pre-built buildings is easy, but it doesn't have the power, flexibility, variety, or even the awe effect that comes with building the entire city using legos instead. So I've been studying the art of making legos for Aggro. But it was all just research and prototyping... until now.

      The Approach

      I hope everyone enjoyed their Memorial Day weekend. Three days is nice, and taking the time to remember those that have served and died is always a wonderful thing. This weekend I tackled the first real jump back into the game code for Aggro Tactics. After working hard for the past 2 months, nonstop reading and testing I've finally gotten to the point where it is time to start coding Aggro again. And it is exciting. I dedicated 17 sessions to Aggro this weekend, 50 minutes a piece. 50 minutes because I'm doing this productivity thing where you work for 50, break for 10 or however long... or something like that. Well it works quite well. I'm actually planning on keeping track of how many sessions I work on the code for, could be interesting. Anyway, I've made a lot of progress, and I'm going to do my best this time around to keep the public up to date. One of my goals is to keep the latest build public at all times. Rather than only putting a build out when it is clean and polished, I am putting it out in its current state every week. Why? Because I need to accept that no matter what, a piece of software will always be buggy. There will always be improvements that can go into it. So when I get over that, then I will start to get over my perfectionism of always having something neat to share.

      As I talked about earlier, the goal of this is to make Aggro easy to work on as time goes on. I don't want development to stagnate, I want it to flourish as time goes on. Things should get easier as we put down code, not harder. And after working on Aggro this weekend, it is obvious that this is going in the right direction. Every time I wanted to add something new, it was seamless to add with only a couple of errors that took no time to fix and were only a problem because I missed a step. I know it is still early, but I've set a lot of groundwork and process for going forward. This coming weekend I plan on putting some shine on the code itself, adding in some comment documentation. I also plan on building my first real integration and unit tests this weekend. Those are basically automated tests to make sure that things always continue to work the same way going forward. You know those times where you are testing something and you repeat the same process to see if it works? Yeah automated tests will do that for us and save us time and stop us from making the same mistakes. This will keep the code more stable going forward. Whenever a bug is found, a test is written to replicate it, then we fix the bug, and that ensures that we never reintroduce bugs into the code.

      What exists now

      Now for what is actually in the game right now... well not much. We are starting out with just a simple text/console style UI. Why? Because we can focus on just the pure game logic, little focus will go to the visual and everything will go to making sure that things work properly logic wise first. The way that Aggro Tactics is built, it will be easy to develop with one UI and then switch on another UI and build in the hooks for that. The visual part of the game is completely separated from the game logic... this means that we can swap the look of the game really easily without breaking any of the backend. Probably over most of your heads, but trust me it is a good thing.

      So with this first version, I've created the menu groundwork. The first objective is to create the entire process from start to finish. But every time you run through it, you will get the exact same data every time. No matter what name you login with, what password you use, what piece you select, etc. Everything will use fake data with no calculations happening at all. Why? Because when we build out the whole process, we can go back and substitute logic where it needs to be substituted. So for a long time we can go with fake login system, but in a couple months we can go back and swap it out for an actual working login system. Then when we know that is working, switch back to the fake login so we can get to the parts that really matter. Right now the specific things that are in are the portal menu, title "screen" message thing, menu selection works fine, free text input works nicely, the ability to push notices (like "Login Successful"), and the ability to tie anything to the "Not Implemented" notice. There is also a lot of stuff going on in the background, but the ground work is here now.

      I do need to repeat this, we are building the console version first to ensure that the game logic works as we need and we don't spend extra time prettying up something that isn't even set in stone yet. All text first to get started, then once we get the game logic in we can start working on actual UI. And at that point things will be much easier as it is just displaying stuff we have already calculated. Exciting! Well it is for me...

      Going Forward... again

      Going forward, this week/weekend and onward, the goals are to:

      • Go through and add comment documentation everywhere in the code for other developers
      • Build initial unit and integration tests, so new changes don't break things that are already working
      • Start writing out the process of development so I can get Thomas in on this, and get him comfortable with how things work
      • Write productivity macros to make writing repetitive code easier, I already have a few but now that I have a process I need a particular suite of macros
      • Start wiring up the entire game menu system (game list, collection, playing a turn, viewing game info like the board/opponent/pieces, queuing actions, and eventually the action/map editors)

      LOTS TO DO! But with the current structure that is setup, development should go much faster than in the past. You can find the current version for the game at (I'm using a temporary URL until I can take the time to actually put it on aggrotactics.com, gotta learn more about webservers and shit)... OH and the Unity Webplayer is not a virus, it is needed to play the game in the browser. I have setup downloadables for Windows, Mac OS X, and Linux that are available on the site as well:

      Release Date: May 27, 2014
      50-Minute Session Count: 17


      Doc1777 said...

      Sweet. Definitely sounds like a good approach. I look forward to see the changes made for each update.

      GodlyPerfection said...

      Thanks Chase. I'm looking forward to it. Lots to do, but it didn't take me long to setup this much so I'm hopeful going forward. :)

      Anonymous said...

      Ι'm gоne to sɑy to mʏ littlе brother, tɦat he ѕhould ɑlso pay a visit tҺis blog
      օn regular basis tο оbtain updated from latest news update.

      my blpog post - Powerade Coupons october 2011