Project Context

This project came about from needing a direction change. I’d been pondering games with crafting/farming/etc systems for ages, but struggled to know where to start. I tried some sim-type prototypes last year that didn’t go anywhere, and still felt I didn’t know enough about how to approach these games, technically and creatively.

I decided to stop worrying about whether the idea itself was interesting/unique, push through the wall, try to get to gameplay. Hopefully in the process I’d improve my skills and perhaps spark some new ideas.

The idea

I called the idea “Mini Survival”. The (very vague) basis was that you start inside the safety of a fenced area. You need to leave this safe zone to collect resources, but being outside the safe zone causes your health to deteriorate until you return and heal. Time spent outside chopping wood, collecting resources, etc, therefore needs to be carefully managed. The player can edit the fence and use collected wood to build more. Explore the land, discover new areas and obstacles and upgrade your stats. A more concrete goal could be to rescue survivors that you find and bring  take them safety.

Prototype Development

I decided to dive in and try to bash together the different systems quickly, taking as many shortcuts as possible. That included basing everything on tilemaps, to test out whether that can speed up prototyping this type of game (even if the idea is not ultimately intended to be grid-based, or even 2D).  In I went.

The first obstacle

I started with the core mechanic of fences and…immediately hit a huge technical challenge I hadn’t bargained for. I’d made tilemap-based fencing in a previous prototype, so I knew the use of rule tiles to visualise it based on fencepost tiles would be easy. What I didn’t bank on was the can of worms of determining the inside vs outside of a fenced area.

Without going into too much detail, I did have some primitive versions working early on: logic that determined whether the fence was a loop, and then marked all the tiles within the loop as safe. At the start, forks or misplaced fenceposts would invalidate the entire fence, but it was quickly apparent that this was too fiddly to play with, even as a prototype. I tried some ideas for simple solutions but after a day or two I had two options: take the time to properly read up and understand this problem, or come up with an alternative mechanic. Watching a few videos on the topic (e.g. this one), I concluded that, though it did seem like a tempting and doable technical challenge, it would be too much time to sink if I wanted to get the prototype playable within a couple of weeks.

Idea take 2

So, the idea changed: instead of a fence, the player could go underground to be safe. They move between underground and overground by finding holes dotted around and placing ladders. They can craft struts to tunnel around underground. The rest - gathering resources, crafting, avoiding enemies and rescuing survivors - remains the same.

This version was easier to build, so I dove in and spent a week or two on making it functional. The current state of the game is - just about - playable, by which I mean, I am able to play it, and if you are willing to read a lot of explanation, you can also play it, though there is no end state. For now, the instructions are on a Miro board linked from the game page - attempt at your peril.

The learnings

Now is a good moment to stop and evaluate: what have I learned, do I want to do more with this project, if so then what? I’ll get to the latter points in my next post - for now, the learnings.

Working on a game you can’t test in 30 seconds is definitely a shift in mindset for me

I am not a patient person, which is both a strength and weakness. I’m used to making games where you can hit play and tell within seconds whether the mechanics or level design have improved and are starting to feel good (after all, I spent years working in mobile, where you have literally seconds to get a player’s attention - doubly so on platforms like Snap or Facebook Instant Games). 

So, for this type of game I need to embrace a slower pace. I need to enforce longer, more thoughtful playtesting sessions on myself, because otherwise I default to making things faster, more immediate - and that’s not the experience I’m after. I also need to consider features like save states as more critical earlier on.

Tilemaps were a good shout

It was so easy to set up new items, and to implement the saving and loading. I’ll definitely consider using them again for future prototyping, maybe even in cases where they might not seem like an obvious choice.

I am getting a feel for the scope and time investment of these games

The systems in this prototype are neither complex nor novel, and overall I was pleased with the pace at which I was able to put them together. Still, it does take time, and in particular means a longer period of things being uncertain and disparate before they start to come together. This is a topic I pondered a lot last year, hoping there was some hidden secret to expediting the process (other than paper prototyping). In the end though, I think it’s just a case of embracing it - after all, I enjoy developing these systems, so long as I don't expect results immediately.

Questions I have now

How easy will it be to iterate?

From where I am now, I have some new ideas I'd like to experiment with - but I don’t know yet how slow they’ll be to try out, given that the code is already quite tangled.

Will any of it be reusable? 

Early on, there were points where things like the inventory and crafting logic seemed generic enough that they could be a useful base for future projects with similar features. I’m not sure if that’s still the case - perhaps at the end of the project I should see if there are any scripts worth extracting.

Tutorials - When? How?

As a general rule, my design goal is always to need the least possible amount of tutorial. I either prototype games which need little explanation beyond controls, or, for level-based puzzles, I make a few easy levels to introduce each new mechanic or concept (usually just in individual scenes, each with a little text). 

That approach doesn’t really work here - there is a lot of information the player needs about each system before they can jump in, and it needs introducing at the right moment to not overload them. That makes playtesting without a tutorial very difficult - but doing the work to make tutorials this early on feels like a time sink and, more importantly, is another thing that could slow down iteration.

I’m not sure there is a good answer here, other than to figure out a) what to simplify to need less explanation and b) what the most basic and easy to change tutorial implementation would be and just give it a go. 

What’s next?

This has focussed on the process, and as mentioned, my next step is to sit down more patiently with the game to play longer and really consider if there are interesting elements I want to pick out and explore more. If not, then I need to decide on the final steps to wrap up this prototype.