Greetings! This week was much like a loading and firing a catapult – most of the time is spent preparing and all the results come quickly at the end. I spent a whole long time preparing and refactoring code and once everything was ready, I made a significant advancement on Sunday.
The result is that the player can now control multiple Arborian troops and have multiple circuit routes.
Navigation Refactoring (Round Two)
The quick summary:
- One-way and circuit routes are even more unified than before, with their own class
- Route operations are now managed through the Route Manager
- Multiple circuit routes can be created
- All routes are stored in the Route Manager
- Troops can leave and re-enter routes
- Circuit routes are no longer deleted automatically when a troop gets a new order.
The long version:
I wrote two weeks ago about how I refactored some of the navigation code. Well, this week I had to further rework the code to allow for new functionality.
One-way routes were badly broken at this point of the refactoring 😩
In order to keep track of multiple routes I created a new game object called the Route Manager. The route manager is responsible for keeping track of all the existing routes. This means tracking both one-way and circuit routes for all troops in the game.
Having all the routes stored in one place makes it easier to modify them. In the previous iteration all the routes were kept inside the troop object, which is not very proper and could get messy with multiple troops. I intend for the routes to be usable by more than one troop and for them to persist after a troop leaves them, in case the player has future use for them. The Route Manager enables this.
In the future I will also add a user interface that will allow the player to organize and name routes, this will also be managed by the Route Manager as well.
A fortunate result of this refactoring is that navigation now has an even better object-oriented design. The one-way and circuit routes are now more like different flavors of the same thing – behaving mostly the same with only a few exceptions.
As a bonus, I was able to get rid of the extra object that accounted for the first leg of one-way routes (Part 4 of May week #4). This first leg is now handled by the same process that renders all the routes. This feels a lot cleaner because I am not making unnecessary exceptions and instead reusing existing functionality.
Multiple Troops!
But actually that’s not everything! 😀 Because of all the intensive re-working and creating of the route manager, the code is now so limber that I was able to add additional Arborian troops to the scene with ridiculous ease. By interacting with the Route Manager, any troop can create a new route or join an existing route. You can imagine this like a group of people sharing maps and plans with each other.
In future iterations, I will remove direct control of all but one of the troops. The intent for Arborlands is to have only one troop – Troop One – react to orders instantaneously. All other troops will have to be sent commands via messenger, after all these are critters out in nature with no radios! This will be a primary constraint that a lot of play will revolve around and I can’t wait to program it!
As always, the video version of this log is on YouTube. Thank you so much for reading!!
Arborlands 
1 Comment