This blog contains development updates for a game in development by us, Brian the Designer/Artist (bmurph) and Ray the Coder (fufux). The game is currently a pseudo turn-based action game where you control a squad of units to combat robots gone wrong (zombots!) with a crazy mish-mash of abilities and characters.
Updates come sporadically, the latest build is occasionally updated in the link above, and you can always see the latest changes from our depot in the feed to the right. Enjoy!
We’ve been chatting about coming up with a loadout screen that makes it quick and easy to accomplish the following:
The last one is probably somewhat lower priority but if we can incorporate it without increasing complexity (which would diminish the first 2 goals) then I’d be happy at the very least for not having to implement yet another UI screen. Here’s my latest (programmer-art) mock-up inspired somewhat by old school fighter games…
Lots of silence recently I know but things keep moving, albeit slower than expected. Brian’s got greybox versions of 3 levels put together and now I’m stringing them together as part of our core loop. We’ve spent some time on the meta-loop, specifically on how you outfit your characters, how you unlock new characters, and how you unlock interesting new badges for them. Things are a bit wanky at the moment but we’ll be spending the next week bringing things back together in a slightly more polished (and playable) form.
As an added bonus there’s now an RSS feed on the side with changes direct from our depot, so you should be able to click and see them in their raw glory.
The badge system has been up and running fairly well so now we’re doing several rounds of building out scenarios, playtesting, tweaking and fixing bugs, and then repeating. One of the harder aspects to get right so far is the right level of control for the player balanced with the right amount of autonomy for the units to create the feeling of strategic control of smart AI as opposed to the tedious micro-management of braindead AI. Since we’re using a pseudo-turn based game loop where you can only issue commands every 3 seconds we were running into a lot of cases where an unit would need to update to a change in the battle or you weren’t able to control his actions given the current situation, so I whipped up a simple action queue system to help.
So now with each turn you can queue (or remove) any number of badge actions which the unit will do it’s best to act out once you jump back into real-time. Despite some kinks to work out since I went with a super-fast prototype approach there’s already a lot of good feeling from this new interaction setup. I’ve also been taking a pass at adding small bits of UI feedback to help explain what’s going on in the cases I find where I’m yelling at an unit for doing something seemingly stupid (even though he was simply doing what he was told.)
Brian knocked out some animation states for our new guy and the blastface enemy, so now we’ve got some basic animation going in the game instead of the static card motif. I’ve also been playing around with the particle FX a bit to learn the system and add a little more variation – it’s programmer art for sure but variety is always a good thing. And finally the AI is finally getting some much needed attention as the old zombie AI wasn’t meeting the bar for a modern Project Awesome villain.
Run little Blastface, run! Don’t be fooled, this guy will hunt you down… and destroy you.
I started mocking up an in-game version of the loadout screen that eventually will let you select which units you want to take into the current mission and configure which abilities/upgrades they’ll use. Our current thinking on unit progression will be badge slot unlocks that occur on a unit promotion (every mission) which allow you to equip an additional badge. Currently all the badges are straight up actions (sprint, cripple, headshot, bandage, and so on) but next I’ll add the notion of passive badges that allow you to modify base stats constantly (extra health, trade off movement speed for health, etc).
Bare bones and basic, but hopefully it’s enough to convey the idea of what we’re building. While I was mucking about with the GUI some more I added simple animation support as well so the HUD is quite a bit more pleasant nowadays. Unfortunately animation doesn’t capture well in a screenshot, go figure…
We set out at the beginning of the month with a fairly simple goal that we’re not going to meet:
- Build something we’re confident in shipping (i.e. submitting to a store)
There’s a variety of reasons why we didn’t make this goal, most of them dealing with personal and work life demanding far more of our respective time than normal. I do believe we might have started out a little out of scope and since we weren’t able to collaborate at our usual frequency we missed out on opportunity to course correct and re-focus on the original goal.
That being said tremendous progress was made this month and I’m as excited as ever to keep developing the project. Brian’s whipped up a great narrative outline, new character designs, and mockups for all of our new UI. I’ve implemented the changes to shift our core game loop to the “real-time with strategic pauses” direction and checked in a new framework for implementing character abilities that will enable us to rapidly experiment, tune, and iterate the core gameplay.
March thankfully is a new month and the only obstructions I see to getting plenty of development time on Project Awesome will be how much snow if falling in the mountains nearby.
Things were a bit slow on my end this week due to Real Life(tm) but thankfully that’s easing up a bit. Now I’ve got a mountain of content to plug-in thanks to Brian cranking away while I was indisposed. Lots of great design work coming on-line, we’ve got a whole new system of ‘badges’ that players can mix’n'match to customize and upgrade each of their units. Additionally Brian took a pass over our GUI screens and mocked up new versions of pretty much everything, so I’ve been focusing on bringing our GUI up to speed.
In the process of flushing out my GUI helper classes I decided I ought to take a stab at creating a custom editor window in Unity and as you can see we’ve now got the beginnings of a editor. There’s plenty of features to add to it for sure, but the time it now takes me to get a screen up and running has been reduced by 1536.023%. That number has been scientifically verified!
I’m not updating the playable build quite yet as the body hasn’t been sewn up enough to be presentable again. Soon though, soon. Famous last words I know.
We’ve mapped out a multi-level campaign that showcases PvE gameplay for projectawesome and are quickly making progress towards building up the new elements. I’m still hacking away at the code side of things, refactoring some logic to make it more easily extensible for the new features coming online soon and also creating a few helper classes to make my life easier(!). Here’s a snapshot of the editor view of the breakout level from our current playable build, red/blue cubes indicating unit spawners and whatnot. We’re still iterating on camera positioning as this level has quite a bit of depth but with the current in-game camera it doesn’t pop quite as well.
Thanks to everyone who’s checked out the build! We should have a meaningful update to the latest playable by the end of the weekend.
Work is already underway for this month’s planning and development. I think we’re leaning towards exploring the PvE gameplay rather than jumping on the PvP bandwagon. Given our current thinking it looks like this will mean lots of focus on adding more elements that make for more interesting level designs and small strategic/puzzle elements. And more polish! Brian’s already experimenting with new characters, I’m figuring out how to make better use of the particle systems, and we’re on a hunt for audio… huzzah!
I’ve been using this small reprieve from “shipping” something to do some cleanup and refactoring of minor things that were annoying me over the last few weeks. Changing a bunch of internal variables is always fun since inevitably a typo will sneak in and fundamentally break the game, so then you get to spend 15 minutes figuring out how you so fundamentally broke everything for such a meaningless reason. Good times! I also nuked a bunch of prototype assets that were artifacts of the Unity learning process, so now our library is somewhat organized, which appeases the OCD gods somewhat. I also played around with some editor-only gizmos drawing to help with the level building/scripting stuff, as evidenced by this glorious screen capture (red/blue cubes = spawners, cyan spheres = triggers).
I updated the dev build to include these refactorings, along with a few minor bug fixes, and a couple small features. You can now click & drag the camera for example. Insane. And your units no longer clip through the button tiles. Is this even legal?? And you can no longer accidentally deselect all of your units. True story.
We’re evaluating Trello for our planning/collaboration and I’ve opted to make our planning board public for all the world to see. It’s a nice way to get a snapshot into what we’re up to, what’s likely to come to the next day’s build, etc. Take a look if you’re curious. I’m going to upload our design documents from last week as well for the morbidly curious. They’re were surprisingly helpful even if we veered off track pretty much every week.
Overall the experience of starting a new project with Unity was very good. Every engine has it quirks to be sure, but the more I started to get a feel for the way Unity prefers to have things setup the more appreciation I gained for the technology. Here’s a few thoughts on the process now that I’ve spent a month with the tools building a game with moderate complexity.
The good…
The not as good…
Oh, and a helpful tip for easier debugging – instead of marking properties that shouldn’t be editable but need to be public as [HideInInspector], try using the ‘internal’ property identifier instead. This way the property is accessible to all your classes as though it were effectively public, won’t show up in the normal inspector, but will be viewable alongside private properties in the Debug inspector. Very handy for seeing the internal state of objects when there’s bugs afoot.
We’re forging ahead with the project and sticking with Unity, so I imagine I’ll have more to add after next month’s developments. I have a (hopeful) suspicion that there will be very little friction moving forward now that we’ve gotten over the initial hump.
A new playable build is up with a few fixes, some tuning, a little polish, and another couple bits of story to pull the missions together. The last mission didn’t make it in time for tonight unfortunately but we’ll get it in tomorrow most likely. Trying to wrap this up for onegameamonth.com has been a great experience and a lot of fun. I’m really looking forward to seeing how much further we can progress given this was our first attempt at building something with the Unity engine. The ideas for where to take the game for February are already pretty exciting and I can tell already scoping will once again be our biggest challenge.
About