This week, we made more progress towards our Stage One challenge. When I mentioned last week that we were planning on challenging, it somehow slipped my mind that Columbus Day would interfere with our normal class schedule. This gives us another week to get our stuff together, but that's also another week that we haven't progressed to Stage Two. I'm getting a bit nervous about being ready to present our game when the time comes. Not that this is going to affect my resolve to have the game ready by then, but it is a concern.
On the programming side, I added upgrades back to buildings. Things are much more cohesive and nice to work with after last week's big refactor session. I'm now working on adding shields and fighters to balance out the combat. That should be fairly simple, though the fact that the planets rotate still is troublesome for targeting and pathfinding.
There are a few parts of the project that now seem like they're diverging from our goals of simplicity, accessibility, and quick matches, notably the combat system. To that end, I suggested in a meeting a few days ago that we reconsider that system, which has always been nebulously defined. We're now considering a different style of combat based more around launching projectiles from your buildings. This deals with our problems in multiple ways. First, I won't have to contend with pathfinding as much. Projectiles will move in their own arcs and be affected by gravity. While we may have some homing units, they will act, I imagine, at a much shorter range. Second, players will have more involvement in the actual results of an encounter - seeing and adjusting the actual path of your nuke instead of just choosing a target and letting it find its way should be much more satisfying. Third, it allows for a bit more variety in our towers. No longer constrained by "bombers", "fighers", and "nukes", we can now have proximity mines, deflectors, wormhole generators, and all sorts of other interesting projectiles. The introduction of space and movement as parameters for players to manipulate and control adds to the arcade feel and is easier to understand immediately.
Of course, this kind of flow makes much more sense in a turn-based environment. Take aim, fire, let time progress for a few seconds, then let your opponent decide and execute. This, of course, isn't turn-based in the same way Civilization is turn-based. This is more a case of having a limited time span, perhaps 20 seconds at the most) where the world isn't progressing but you are free to choose any number of buffs and an action for this turn. I should be able to implement some, though not all, of these changes before we challenge next week.
After we move on to Stage Two, I plan on bringing in a little pet project of mine, a string macro translator, into the project to allow for better action descriptions and names. Essentially, you can give it a string like "$(CurrentHP) / $(MaxHP)" and have it translated to whatever values you assign as translations for named macros like CurrentHP or MaxHP. These translations can be plain old strings, functions that return strings (useful for things that change often, such as HP counters), or even functions that accept arguments, allowing for macros like "$(InventoryDescription 0)" or "$(AreaName map0)". It's a small little project but it works really well and will help us out later when it comes to localization.
Anyways, see you all on the flipside of our challenge next week!
No comments:
Post a Comment