>What were you trying to accomplish?
Just, like... make game. Seriously though, what we wanted was to make and release a game. You discover things, both good and bad, by going through a complete release cycle that you wouldn't be able to discover any other way.
More specifically, what we aimed for as outlined in >>712
>a fast-traversal platformer
>where you have to escape a pursuer
>with some original character sprites and
>at least one piece of original music
So this now brings up the question of what a "game" is. I'll sidestep all the tangly stuff that can come with answering that question by simply saying what we
wanted was to have a game that
>worked on a "toy" level by being satisfying to control
>had a win and loss condition
>had a story of some kind, however thin
>Where did you hit or miss your objectives?
Miss: We didn't end up making a fast-traversal platformer - the final result was closer to a Metroidvania in style.
Miss: There was no pursuer, nor escape. In fact, the final demo had the player character looking for the NPC who was originally supposed to be pursuing them.
Hit: All character sprites and indeed all graphical assets were original.
Miss: No original music.
>What caused your results?
We'll leave aside exceptional life stuff, of which there was plenty, because circumstances conspiring to interfere with creative work is downright routine. But we ended up having less time than we thought we would, partly from the aforementioned surprises, and partly from fighting weird shit in Godot. More on Godot later.
Our sprites worked, I think,
We made the mistake of thinking that tilesets would take longer than they did, so initially we decided to never attempt them and instead made character animation frames that never ended up being used. Wish we'd decided to do that earlier, so that it could have been something a little more evocative. Strange to think
Might have become a little over-confident, too, because early work on the character sprites worked better and came out faster than we thought, meaning that we got a little complacent.
We ended up doing level design very late in the piece because we didn't really have a strong concept in mind. Given that we were thinking about how to design a pursuit, but that the mechanics we ended up being able to get in there didn't really support it all that well, the eventual pivot to a more exploratory style meant we were groping forward without any idea of what we wanted to achieve.
One of us was doing all the programming (the other not having the necessary skill level), and that programming ended up being way more time-consuming than we thought, mainly because of weird Godot shit that ended up eating huge chunks of time. (All engines have their idiosyncrasies, and we don't really have experiences in other engines to compare to, but Godot really threw some undocumented and long-standing bug curveballs our way.) The thing about unexpected bugs is that you can't predict when and how they'll hit - except perhaps in a statistical sense - nor how much time they'll take to overcome, so this meant that stuff we thought the programmer would be able to do had to be taken on by the other out of order.
This comes through in details like the lack of tutorial prompts, the thin script, the arbitrary level design, and so on. In situations where you aren't able to achieve your scope, it makes sense to reduce that scope - but reducing scope only meant that our non-programmer had less to do, and did nothing to resolve the fundamental issues the programmer had to attack.
Turns out that you need a whole lot of programming to make a game work. Who knew? We thought that using Godot would help - and to a degree it did, e.g. editing animations, sound effects, and so on - but in the end it didn't really take as much coding away as we thought it would.
>What should you start, stop, or continue doing?
Being both complacent about what you can do and over-cautious about what you think you can't do turns out to be dangerous. That's why end-to-end exercises like this jam are so important. Can't really think of a way to address this, except to try and keep attacking things as early as possible. Polish is easily up to half of the time spent on any given thing, and problems can leap out and wreck your shit at any time. You can't plan that away, unless you're both experienced and psychic - we are neither.
It's easy to say in hindsight that you should have planned more. Our problem was that we didn't really know, in detail, what would be required to make the game we envisioned. How could we - we'd never done it before! But what we could have done was to pay more attention to the game's design. Like, we have no lose state (except discovering one of our easter eggs), and no real win state. What we made isn't a game, at least not according to our own definition above. It's more like... half a game toolkit built on top of Godot.
Something we did do well was to secure early wins and then build on them. We tested the character concepts with rough animations first, and only once we were sure they worked did we animate the in-betweens and line everything up in code. We resisted the temptation to hard-code things; being able to change and adapt by only tweaking a few parameters was extremely useful. (It's not just the time something takes to change, but the energy and friction involved in doing so - the less changable, the less someone will be likely to experiment with changing it.) Though we ended up in a mad asset dash towards the end, I think that keeping and testing gameplay with filler assets was probably better than creating stuff we didn't end up using.
So, we should start to interrogate the game idea right from the beginning. We should stop getting complacent when things are going well. We should continue building things to be changeable, so that we can shuffle stuff around without trouble as we discover more, and we should continue trying to get our bases covered early.