So in true student developer form, I’m changing the focus of the dev blog one post in! After looking at the scope of my semester, and what I wanted to accomplish I decided to focus on the ¬_other_ project I mentioned in my first post. The game is a real-time-with-pause physics based tactics/sports game. If that description is too confusing, you can imagine a marbles if each marble was a unit with abilities that you could issue commands to, and all of the physics was juiced up. The game started as a project earlier in my FIEA career that I felt had a lot of promise, and now that I have the time to choose what I work on I’ve decided to give it the attention it deserves and flesh it out and launch it on mobile! This rest of this post will be going into a bit more detail on what the project is, what its identity is, and my plans for it.
The Origin of the Design:
The game was formally designed for a one-page[LINK] design assignment I was given, but it’s roots go back to an overly ambitious project I attempted in my undergrad. It’s intended to be a pretty tight fusion of tactical challenges and action packed gameplay, and it does so by letting the use control time whenever they want. This is pretty similar to the real-time-with-pause (RTWP) system found in many cRPGs like Baldur’s Gate, or (more recently) the Pillars of Eternity series. The idea is that users can pause, and use physics based unit abilities (e.g. Dash, Grab/Throw, Grappling Hook etc.) while the game was paused, and then un-pause to watch their plan execute (and often fail in hilarious unforeseen ways).
The First Incarnation:
I got the chance to actually build the above design a few months later at the end of the same semester. During development, a few big changes had to be made though, the biggest was about the goal of the game. The initial design wasn’t actually that concerned with WHY the player was doing these things, it was infatuated with the dynamics of gameplay, not so much the goal. As a result, it defaulted to a combat-esque death match scenario. It turns out that accurately predicting high-speed physics interactions is actually pretty hard, and the game didn’t need adversaries to feel fun and challenging. In response to this, I changed the goal of the game from “K.O. all the enemies” to “Score a goal before the timer runs out”. When the timer runs out, the level automatically resets and the player can try again immediately, keeping the action going and the frustration of the many inevitable failures players will face at a minimum. This was the state of the game at the end of April when the project concluded.
Where the Game is Going:
Taking the game from where it was left at the end of the student project to a full fleshed out game I can launch on the app-store is a lofty goal, and one that requires a whole bunch of work. I won’t bore you guys with my full road map, but the bullet points an annotated list would look something like:
-
Redesign Unit Mechanics:
The unit abilities and interactions were designed for a combat environment where the primary goal was to create impactful interactions between opposing units. This means that many aspects of the unit mechanics feel either arbitrary or lackluster in an environment where your trying to score a goal. The two biggest offenders of this are the unit abilities that were designed with a defensive focus, and the rules that govern unit collision, which often results in one or both units being stunned from the collision.
-
Touch Controls
The prototype of the game made use of 7 keyboard keys, a mouse, and a scroll wheel, and those controls felt pretty clunky. Redesigning the control functionality, and mapping it to intuitive touch controls will be a big part of what makes the game feel good on its intended platform.
-
Content
The prototype had 6 levels, most of which were designed to show off a particular mechanic during the demonstration. An actual launch of the game would require enough content to justify the user’s interest- which considering how short levels can be, means many dozens of levels. Designing more elements to gameplay (environmental obstacles/hazards etc), and developing a level creation pipeline will be essential to being able to deliver on this requirement.
-
Optimization
It turns out there’s a lot you can get away with in a pc prototype that doesn’t fly on a mobile title. A did a pretty good job with the code that governs the back end of gameplay, but as the hours wound later during the initial development process, various solutions were implemented that will need to have a hacksaw taken to them.
-
Physics
There will be a lengthy post on this later, but as I get further into development of the game the more I realize that various aspects of Unity’s physics simulation aren’t going to cut it. Specifically, the way they collision/reflections are handled often produces results that are erroneous in non-predictable ways. It’s quite likely I’m going to have to write my own collision library to solve this problem. This would be a lot more intimidating if I wasn’t working with frictionless, perfectly elastic 2D discs in a vacuum.
Many of these goals require simultaneous development, so I’m working through a lot of them concurrently. I’ll make a point of posting here when I implement the first big solution to each problem- and then keep posting as I refine and update said solution. Its also worth nothing that I am 100% sure there are very substantial problems I'll encounter that I'm simply not aware of right now. As I encounter those, I'll be sure to let you guys know about them, and know how I plan to overcome them.
This was a long post! If you made it this far, thanks for reading, and stay tuned for more development posts!
-Andrew