So, here we really go, let’s dive in.
I woke up this morning intending to waste no time in coming up with a concept to tackle through the week. Seven days is really not a lot of time, and I have no plan on wasting any of it.
No doubt a product of what I have been playing, but lately, when I think design, Strategy is always the first place my mind goes.
This project will be a form of Strategy Game.
I have concerns about tackling a Strategy Game for a project of this sort. Don’t get me wrong, I am passionate about Strategy, but in this space I would like to create something fun, lighthearted and compelling – and as much as I love Strategy – it ain’t that.
Strategy is all about rules, it takes time to learn and understand – not exactly the traits you’re looking for when frantically throwing together a pet project that you’ll be lucky to have people spend more that 5 minutes with.
Regardless, seven days is really not a lot of time, and this is where we’ve found ourselves. Besides, maybe I’m being a little close-minded.
The strict time restriction will govern the majority of decisions I make during development. I will need to avoid taking on anything difficult or overly time consuming, as well as avoiding breaking any new ground.
The following are some things I wish to avoid in my design.
For two reasons, both good ones.
I have never experimented with network or multiplayer code within Unity, but more importantly, as a playable demonstration, a single player product is far more useful.
No Complex AI
Or any AI for that matter. I simply do not have the time to design and write complex systems for the game’s enemies.
No Complex Pathfinding
Pathing is the bane of my existence. I want to simplify pathing within the game as much as possible. This is going to have far-reaching consequences.
No Heavy Level Design
There is simply no time to hand design levels. Some kind of procedural or random level creation needs to be developed, but this is also time consuming and concerns me.
My art skills simply don’t match my standards.
Having constraints, and knowing them, is fundamental to design. You can’t expect to design an elegant solution if you don’t first outline the problem.
We’re going to search for solutions to each of these ‘problems’, and with any luck these solutions will work cohesively together.
So lets delve a little deeper into each of these constraints, and see how we can create a functional design that plays nice with ‘em.
Saying no to Multiplayer and Complex AI
This is a strange space for Strategy Games to find themselves in, although the (sub)genre of Tower Defence is a great example of strategy manipulated to fit within this constraint.
Saying no to Pathfinding
Attempting to write complex pathing code is completely out of the question. I’m simply not skilled enough to write this kind of code in the brief time I have available, so we’re going with the bare minimum. I plan to write pathing code that will allow the following:
- Allow units to path in a straight line, directly to a point.
- Additionally, allow the player to give more complex paths to units, by drawing lines for units to follow.
Now this is incredibly lazy, and not elegant design at all. I believe limiting pathing to the above specifications will be limiting to the project, and will likely be felt in the final product.
I will not be able to include any of the following, which I would have liked to.
- Obstacles for the player and enemy units to avoid or navigate around.
- Interesting terrain, with variation in levels.
- Smart unit collision avoidance.
Goodbye perfectly functional design! But we are on a tight leash here, and sacrifices have to be made.
Saying no to Level Design
I don’t have time to create levels or scenarios by hand, and I’ll also be pushing my luck attempting to design a procedural/random level generator that is sufficiently functional.
Luckily, at this point I have a pretty clear idea in my mind of what direction the project is going to take, which makes this potentially daunting constraint a little easier to handle.
It might be worth a quick recap of a few of the concessions we’ve made to fit within our constraints.
- Flat terrain
- No obstacles
- No complicated AI
Given this, it seems obvious that the game can not revolve around complex terrain or navigation. The focus of the game must be on the interaction between player and enemy units, and the focus of each ‘level’ must be entirely on the positioning of static enemy units, ready to spring to life in reaction to the player – which if we refer back to our argument against complex AI, all sounds very familiar.
This dramatically simplifies what is required for a procedural level generator, hopefully putting it into realistically achievable territory.
Saying no to Art
I don’t have refined art skills, and I do not plan to waste my time and effort on art that will serve to disappoint and frustrate me.
As such, art will be abstract, created using simple geometric shapes. This is actually a positive, and fits with the abstract themes that seem to be presenting themselves throughout this document.
Featureless terrain, unrealistic unit movement, enemy units that appear unintelligent, but interact with the player’s units based off a set of ubiquitous and meaningless rules – these are all starting to sound like solutions that complement each other.
It does however, make me think that the player could benefit from having some clear and concise goals, something to offer direction without hurting her head.
To summarise, we’re looking to create:
A single player experience containing strategy and puzzle elements, focused on interaction between player and enemy units, presented in both an aesthetically, and functionally abstract way. Despite the abstraction, the game will contain straightforward goals.
Great, now we have a real starting point. We have a direction to take the project in, and a pretty good idea of what we’re capable of achieving. It’s time to create some documentation to give us a clearer idea of what the game is going to become.
This link will take you to my google docs document. This document is living, and will be updated throughout the week. Anyone with too much time on their hands is free to take a look now, and again later in the week, to see what progress and changes have been made.
Tomorrow I’ll create a task list outlining what I wish to get done each day during the week, and begin some actual work on the project.
And with any luck, I’ll also have some pictures.