AfterCiv: Probably a bad idea worth exploring
A Day of Paper Prototyping 1/
'A game of civilization set after a game of civilization has ended'
'A survival 4X game set after you've brought on the apocalypse'
'Choose your own apocalypse and rebuild civilization'
Ok so in spirit of making bad ideas into probably bad games, I've been plucking away lightly on a concept that I have found interesting - it's also in the spirit of MazeGame, which was a survival crafting game in a maze. It wasn't that fun, but I learned a lot about Blueprints and basic UE4 development in the process.
AfterCiv is a prototype concept to explore the idea of a game past the fall of civilization, but set in the genre of a civilization game/4X.
I started my work by creating some 3D prototypes to get an idea of a couple of key concepts:
- What would the game look like?
- What would the tiles look like?
- What are some interesting concepts I can capture in a mock-up?
But this 3D mock-up isn't really a prototype, it's basically a step too far over prototyping the actual mechanics to understand if we can define basic rules, gameplay and to find if it's fun at all.
I've been looking at some great resources for rapid and paper prototyping, and the first awesome talk I've been over was 'A game dev guide to rapid prototyping for fun and profit' by Mark Barrett
Following Mark's talk, I set out to define some key components of how I wanted to approach the goal of finding the 'base game' behind AfterCiv through some static prototypes. I wanted to get this down -today- and avoid some common pitfalls.
Being Efficiently Lazy
So firstly I want to make sure this is quick, rough and find a minimum viable interaction. Scope is often something that is thrown at game concepts, but I am of the camp that any inherently overly complex idea can be refined into multiple MVI components that work together to produce a minimum viable product as a whole.
definitions of urgency and importance when setting goals is quite
important, and this may filter back into the prototyping. Splitting
components into mechanics that are urgent can help establish an overall
loop that defines importance. But there is more to this concept -
finding the value.
Setting goals is an important component of this, and Mark's description of the SMART checklist is quite a resource to follow:
Specific - Precise description of what is to be accomplished
Measurable - Progress is visible and tracked
Attainable - What actions are needed to make it happen
Relevant - Meaningful and realistic
Time-bound - Estimated time for completion
The example he provides is a SMART statement that is quite perfect:
I will create a rapid prototype for a game (Specific)
that users will be able to test and offer feedback (Measurable)
by signing up for and participating in a Game Jam (Attainable)
This would make me a more resourceful dev (Relevant)
and will be completed in one month's time (Time-bound)
The SMART statement I think is most relevant to my needs and scaled to how I want to approach this prototyping phase is as such:
I will create a paper prototype for a game
that I can play to iterate rules and mechanics
by completing play sessions on a grid
This may give me insight into scope
and be completed in a day's time
I know this drifts from the holistic approach to SMART, but ideally I want to stress test the concept in a very rapid sense and find a reason to kill this idea early.
precursor to this prototype phase was to define the external barriers,
and prior to watching this talk to actually define these barriers even
before attempting this:
Time: I have a lot of personal time to be able to focus on this concept.
Resources: I am able to both draw, model and animate concepts rapidly.
Location: Australia, let's not get into that.
Opportunity: I failed to find games that intersect this genre of game with subject matter.
Competition: Civ, Endless Legend etc. - but by defining their hooks, features, context, I was able to identify an opportunity.
Start Where You Are, Use What You Can, Do What You Can
Directly quoted from Mark Barrett, this has been a core guiding principle in every approach I've read in regards to rapid prototyping - and I plan to stick to that.
General - Survival Game set in the 4X Genre
Theme - Post-apocalypse
Goal - Players must rebuild civilization turn by turn and overcome a set condition based on an apocalypse
UX - Players will
1. Answer a few questions at the start of the game
2. These questions will determine a few gameplay conditions
3. Players will spawn with 2 units at a random location on the gameplay area
4. Players will convert their assets into a static 'camp'
5. Players will move their units around to explore tiles and generate new resources
6. Generated resources will allow player to generate new assets.
7. Players can discover new items/equipment to place onto their assets
8. Players will explore, interact and move assets to follow a quest-line
9. Players will complete game-round when quest line is completed
Notice that I'm really not focusing on any of the themes - because whilst I believe this is an overarching theme hook, it's really actually a pitfall. The 'theme' of the game is something that needs to work further down the line with the core, secondary and progression mechanics.
Understanding the difference between world building and game design is extremely important and a common problem that plagues passionate game developers.
for this prototype I want to break this up into the following, and this
is an ultra refinement of every single Civ or 4x based game.
Core Mechanic: Player owns tiles which generate resources. Every single mechanic past this reinforces this central core mechanic, the idea of ownership and loss of tiles through a web of secondary mechanics that dictate the overall win or loss condition of the game.
The very start of any of these games has your units inherently owning the tile they are placed on. This is the root/core mechanic of the game.
Secondary Mechanics: Player can lose ownership of tiles, tiles have different values of resources and Player assets have resource production/loss on a shared pool. This is where you enter a potential quagmire, as it's easy to think this is a complete feature list of every permutation of interaction in the game. I don't believe it is, instead it is positioned to compliment the core mechanics and establish a loop. With these three definitions, I believe we have a core simple loop.
Moving, attacking, defending, exploiting resources on tiles or onto tiles themselves become a secondary mechanic. Projecting ownership, trading ownership, obtaining resources to own more and reacting to threats that retract ownership are secondary mechanics.
Progress: Player can build units and buildings on tiles to increase resource generation. Now I've specifically opted to exclude the idea of 'having more units' as a progression mechanic, because if you strip away everything to base elements in a 4x game, the principle idea is that you generate -more- resources so that you can obtain -more- resources. This extends to being able to build, research, even attack units on a map.
The idea of tile ownership of a core mechanic introduces the progression concept that every step you take in the game, from research to building, reinforces your ability to own or convert tiles. Progress is dictated by the growth of this mechanic and more importantly the ability to upkeep that progress; either in generating enough resources to build more things, or placing units appropriately, or by being able to produce more resource than you consume.
Narrative/Context: Player must slowly rebuild their camp into a town and journey into the world to uncover its resources and secrets. Again, I'm purposefully not even touching on the story, theme or world-building elements, as they are so further down the line that I can relegate them to being defined by just a few key art elements.
The player begins in a tile with survivors and a scavenger unit. Survivors make camp, establishing that tile as belonging to the player. The surrounding tiles are owned by the player. The scavenger unit can be moved tile by tile, and has a resource drain on the shared resource pool per turn. Player must exploit surrounding owned tiles to produce resources. When enough resources are produced, they can build a new unit or a building on their tiles, increasing ownership of surrounding tiles or increasing resources generated in those tiles.
So from this, I have established a range of core, secondary and progression mechanics I need to commit to a prototype on paper. Paper can be in Illustrator, so that I can at least digitize my efforts. Possibly then move that into Proto.io or a comparable prototype solution.