Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Steal the Summit Devblog 1 - Revision and the path to a good game

Shortly after making All 4 One for UDC Jam 24 I was hit with a realization:

gamedev is fun.


After the competition ended, almost right away I started thinking up game concepts with a sole principle in mind: keep it tight. 

Now, what do I mean by "tight" game design? I mean every element of the design serves 1 or more functions. I mean there's a 1:1 mapping from the player's intention to the game's response. Clarity, transparency, and consistency in decision making. A well-oiled machine.

To me, a stellar example of tight game design is Downwell.

Downwell's an elegantly designed game. Its creator designed the game with this key Shigeru Miyamoto quote in mind: "A good idea is something that does not solve one single problem, but can solve multiple problems at once."

That is exactly the kind of approach I want to take with my next game: Steal the Summit.


Apart from forcing the design to be elegant, it also keeps scope of the game in check. I want the game to be finished and published (on Steam and ... ???) by about the halfway point of the year.  


I need to make sure that the code is written and structured to allow for easy tuning of parameters - balance and tuning will definitely be a focus with this title. Apart from the design being elegant in each element being multi-purpose, to add to the 'tight' feel, extreme responsiveness is required. This will take feedback and many hours of experimentation and tuning. 

Sometimes I don't write code that way the first time through - often because I can't even perceive the problem in the first place. That brings me to the first real teachable topic of this blog post: revisions and the path to a good game.


People don't like going back on their progress. It feels like wasted time, misplaced energy, evaporated effort. All this... for what? I'm the same - that's why I only ever wrote "final drafts" of my essays and such in school. Couldn't be bothered to revise things. 

But games are far from linear endeavors. I learned from my game jam experience that for every thing you consider the player might do, players will always find a way to circumvent your expectations. For one, this can come from you as a gamedev having preconceived notions (assumptions, foreknowledge) going into a game. Given more time and testing, All 4 One could've been much tighter of a game. 

Furthermore, an amusing bug popped up during its development. So, in All 4 One you can control up to 4 little parts of your soul simultaneously - this was implemented as 4 separate player game objects. Now, if I wanted the entire group to do a single big attack as it can in its blade formation, I would send the signal to attack... to each player. The way I had implemented things, instead of one big attack coming out, four big attacks came out. Simultaneously. This led to some funny interactions like enemies that are supposed to drop a pressure plate on death would drop four pressure plates instead, and of course the corresponding attack sound effects playing four times... simultaneously...

I didn't have time to go back and implement this better for the jam, but now since I have all the time with the next game, I want to celebrate the idea of revision, embrace the idea of being wrong.


The starting point of a project. Where do you go from here?

Earlier in my life I could imagine a path to success in the following way: You begin, at the onset of your journey, at the very origin of some sphere of indeterminate radius. You can travel to any point within the sphere instantaneously. There is some region of space, a subset of the sphere, where the goal resides. Now, the best, most efficient path to get to that goal region would be to go from your start point at the origin and make a beeline to the goal! But the catch is, you don't know where this region is. 


You found some places you want to reach. How to get there?

Now, certain boons like knowledge and assistance can help narrow things down for you. Look up instead of down, for example. But for a number of goals, you can lurch forward in small, cautious steps, each step generally oriented towards the goal. 

But what about a goal as open ended and terrifyingly undefined as making a good game? It's much harder to pinpoint the goal region, and even easier to misidentify the goal (e.g. lying to yourself, settling for less). How can you possibly build a path to an unknown destination? 

Right now, for Scale the Summit, I have some idea of what that space might look like, but not so much the path there. Now, that's why I tried implementing my first failed mechanic as a gamedev: thieftime.

In STS, you've got to jump up a mountain. There's a lot of jumping, and you've got to decide where to jump. If you string multiple jumps together, you build a combo which you can cash in for points and perks, etc. The idea of thieftime came from a place of accessibility: I wanted as many people as possible to enjoy the game. How thieftime worked was: if you took too long to input the next action and broke your combo, the world would appear to stop and the player would have a certain amount of time to make a decision before the world moves again. The intention was to let comboing be an optional difficulty parameter for players, but allow people to play it like a turn-based game if they so wished. But in practice, thieftime was confusing, unintuitive, inconsistent, and most damning of all: not fun. It was not easy to understand and didn't afford the accessibility I hoped it would - it made the game worse. This was like overshooting the last step in your path to a good game, missing that coveted goal region by a longshot. I had strayed from the idea of tight game design that I'm holding onto.


A few cautious steps can be undone by a bad decision... what next?

Although I had spend some chunk of time designing and implementing thieftime, once I made these realizations, I had no hesitation to cut it from the game entirely. I implemented a different system that's significantly more understandable, intuitive, consistent, and most importantly: fun. The details of which I'll talk about in a later devblog!

So here's the idea. Before, I might have seen this cutting of thieftime as a step strictly backwards: going back on progress, wasting time and energy, etc. Like overshooting a goal region in that good game sphere or whatever. My metric for how well I'm doing is: minimize the distance traveled on the path. But, as I correct myself and bring the game closer to that golden goal region... I'm learning to instead see it as an update to that path. Instead of focusing on distance traveled, I'm thinking about displacement: if I end up where I want to go, the path that I took is largely irrelevant. 


It's not the distance traveled that matters, it's the displacement

Reader, if you ever feel like you haven't made progress, or even regressed in progress: try and think about what you really gained during all this time. You've surely gained something: knowledge, experience, efficiency, relationships... What might be a non-linear path of progress might be a straight shot to your goal in a higher dimension

Support this post

Did you like this post? Tell us

In this post

Leave a comment

Log in with your itch.io account to leave a comment.

Mentioned in this post

Death halves your size but doubles your possibilities in this short and sweet puzzle-action adventure
Puzzle
Play in browser