Big design block on how the command card is going to work, as well as what kind of actions you can order your units to take. All the usual actions you can expect from an RTS are there, from Moving and Attacking to Patroling and Holding Position. 

The Building Queue

The building units design doc. Pictured above is the current design sketch explaining how unit buying/building was meant to work. It went through many iterations to reach this point.

It's all pretty cut and dry, but features that have been in flux since this point:

• This design shows 4 units in the queue but we've begun to considered that we could squish them together with some overlap to fix more, as much as 8 or 10 without losing visible recognition.
• The bar that fills up to show you progress/time before the unit is produced is quite small, so a building animation was also came up with to show building on the main game space.

Capture Logic

Today we're looking at capture logic:



Both the art and code behind capture points changed multiple times over the game's development (and still has some changes to go) before coming to the state it's at now. In the current iteration, we've settled on this push/pull design with directions and destinations.

For this example, we use Team Red and Team Blue, but this math works with any number of colors or players. Placing a unit on a Neutral un-owned capture point begins the capture process; filling a bar until its full and giving you control of that point.

Captured points provide income over time to their controlling player or team, or in the case of Factories, Seaports, and Airports, construction of Land, Sea, and Air units.

What happens however if your capture doesn't go off so cleanly? If your unit stops capturing for any reason, there is a short delay whereupon it begins de-capturing back to whatever it's default state should be; neutral or team-owned.

 If your point is almost captured back to Neutral but not completely pushed there, you can recapture your own point back faster than if you let it go completely to Neutral ownership and start to be captured towards the enemy team.

With a push and pull perspective, the point is always pulling towards a state, and units can either fight against this flow, or ride with it, aiding it to get to its destination even faster.

In the above design sketch, in examples A and C, the point's native recapture speed is suspended as the unit performs his capture. Unit capture speeds are based on how much HP the unit has; damaged units capture at much slower rates than healthy full HP units.

In B and D however, the capturing unit is actually assisting the point's inherent capture speed, adding his own speed to the mix and incentivising you to assist in recapturing points rather than just letting them time back out naturally.

Communication is Key

With the addition of our new project manager, we've adopted a few new practices that have enabled us to start to develop again, primarily among them the Sprint methodology.

Every Monday we (digitally) sit down and have a meeting discussing the sprint; a small slice of the large pie to focus on for the week such as designing and implementing a new font, team-coloring all the GUI assets, or setting up an asset sharing platform for all the team members. 

Once we iron out the week's goals each morning we perform a stand-up meeting focusing on the big three questions:

1. What did I accomplish yesterday?
2. What will I do today?
3. What obstacles are impeding my progress?

This has proved invaluable to our productivity. It's almost become an in-joke to shout "My status is blocked!" Knowing what you've done, what you are going to do, and letting the team know if there is something you need them to do to progress something you are working on has greased the development wheels immensely.

Communication is key though; proper communication. Posting bug reports or screenshots to Skype logs is fast and easy in the moment but ends up lost in minutes as soon as something else is said. Trello is our acting bug tracker, backlog, and sprint manager, as you've seen posted before. It's very useful for sorting and tagging members to specific cards. We use labels for User Stories, Programming cards, Bugs, Graphics work, and general Tasks, all of which can be filtered by.

So what is in store for our next sprint? You'll have to check back to see the minutes Monday.