Day 12: The Perils of Integration and The Loveliness of Finite State Machines

Today was the beginning of the greatest problem to tackle thus far: Working with somebody else in integrating code together into a finished product. So far, the integration ironically meant that while one of us was working on combining our code, one of us could work separately on a completely different piece of code.

This is where I come in; for our small and quick strategy game, the building interface could still use a bit of work. First off? The most basic of integration is taking the World class (has cities, a hopefully abstract representation of an open overworld) and the WorldScreen (formerly known as PlayScreen) that visually represents it and allows navigation via a quick and dirty button interface. This works very well with the ExternalClip and ExternalButton classes.

And into the city? I also made a very dirty background to represent the cityView, but nothing that involves working the buildings. For a solution to this (well, it wasn't really a problem so much as it was nothing) issue, I worked with the maximum of a 3x3 grid and setting initial undeveloped portions around the city, so called "shanty towns" that would later be building blocks for different buildings.

Using an array of an array works strangely in ActionScript 3: the Array carries a vague object definition in that anything can go into an array, but tricky casting (something AS something) is necessary to take them back out. I kept such array access nice n' private to make sure nothing got too messy. After placing these buildings in their required area, I transformed them into buttons (shanty buttons?! No, just regular buttons. Is interchangeable that way) and worked on dynamic road creation to represent visual development.

This was quite difficult in not only that I had to build roads on a horizontal, vertical, and intersection base, but needed to prevent overlap (the roads laying on the intersections) and also not place display objects on top of each other so lazily (which I learned by not placing numerous menu and play screens on top of each other). Solution? Keep a separate array (of arrays!) that contains not the roads, but the state of said roads. Such an array can be loaded and saved to a city on the fly, or built given the development of a certain area. Is this area constructed (or not necessary?) Don't build a road. If so? Build in certain portions (i and i+1, for a whole square). And the result?

Bet you don't see that in a prototype.

Really, it's quite a bit of work for a visual concept, but I enjoyed the challenge. What next? That large empty space on the left is going to be quite full of possible buildings to build on shanties. That hopefully is the plural of shanty, as I will be utilizing the shanty quite a lot.

This was all made possible by state machines; where all your work is in a state far away from someone else who could conflict with your code.