Devlog:

Intro
Hi, we are the developers of Ziggy And The Not So Good Adventures Through The Cosmos, and here is our post mortem of our gamejam. We had some somewhat unique experiences through this gamejam and so we hope that this post-mortem can be useful for people.

The GMTK gamejam was hosted by Mark Brown of the Game Makers Toolkit YouTube channel, with a timelimit of 48 hours and a theme of Out Of Control. This gamejam happened ~2 months ago but we writing up this post-mortem now as we have just released our devlog about the gamejam: https://youtu.be/Iu5tlp06kzo (which will be covering slightly different content to this article, more of a devlog than a post-mortem)

Our game came 54th out of 5477 games in the overall category (#21 in presentation, #108 in originality, #306 in fun). We were not chosen for Mark Brown’s video but are still super proud of our result.

Development Practices
Our core team of 5 met primarily through the GMTK discord 1-2 weeks before the gamejam (where people could find teammates before the game jam), although 2 team members did know each other from previous projects. Managing a new remote team would be challenging and so we had some development practices to try to help with that. We found these development practices super successful, and will continue using them in our full game

Throughout the gamejam we would be in a discord call where we would continuously share screens. This can offer similar advantages to working in person in an office while at home. You can “check over someone’s shoulder” (look on the stream) to see people’s progress. This can be useful to see how close they are to completing something that you need, generally measuring progress towards the end goal, and motivating each other by seeing their work. Help can be easily asked for and provided, through the call and screen sharing.

We used SVN as our source control of choice. This allowed files to be easily shared between team members while ensuring that no changes would be overwritten. The SVN server was set up a week prior to development to ensure that there would be no hitches while using it during the gamejam. This SVN server was also useful when creating our devlog, as we had a full version history of the game. This meant that despite taking no recordings during the creation of the game a full devlog could be created showing footage of how the game looked at different stages of development.

Using Unreal Engine 4 is a less common choice for gamejams (so much so that in an engine usage breakdown graph after the gamejam it wasn’t on the graph, instead in “other”). As most of our team members were more experienced in Unreal Engine it made sense to use it as our engine. Knowing your tool is far more important than what tool you use. A disadvantage of using Unreal Engine was that for our less experienced team members learning different parts of the engine was difficult in part due to sometimes sub-par parts of documentation. Another disadvantage was the game file size. We had 0.5 GB zip download for a 1.3 GB game, which may have led to reduced downloads/plays. In gamejams people often want the least possible friction to try and play your game.

Scope management
An important thing to manage in games, and especially in gamejams, is scope. We felt that we scoped our game pretty well. This was due to constant scope re-evaluations throughout our development, where current progress, estimated difficulty of features and estimated value of features would lead us to quickly pivot our planned development. We had a clear vision of what our core gameplay would be allowing us to easily prioritize our planned features. Many planned features were often seen as “stretch-goals” where they would provide value to the game but were not required for our core experience. Once our core experience was added we could then see which of these features could add the most value.

Unintuitiveness of game
The game's biggest flaw in terms of gameplay is the first time player experience, due to the unintuitive nature of the game, an unskippable death cutscene, and lack of tutorial. It was difficult after 48 hours of near continuous development to see how a new player would see the game. This meant that at the time of development we were not aware that this would be such a big flaw. Having some more time to playtest with some people who haven’t seen the game would definitely help with this issue. 

The unskippable death cutscene meant that it was frustrating to try to learn the game, as there wasn’t much time before you died, and then you were forced to sit there waiting before you could try the game out again. Many players during this cutscene would just leave to play another game rather than managing to complete the game. The game was unintuitive as many separate actions were required in a specific order for the intended effect to occur. If actions were taken in the wrong order this could quickly lead to your death. There was little feedback as to what this order was (there wasn’t none but there clearly wasn’t enough). The complexity/length of this set of actions was chosen to fit the theme/vision of an out of control ship that you’re just about managing to keep control of by continuously keeping many plates spinning in the air. Due to the nature of the intended experience it is difficult to get this difficulty & new player experience balance right, and so more time should have been taken to improve the game in this regard.

Marketing jam
After the gamejam ends, the marketing jam begins! After the first day we got a few ratings but after the effort we put into the game we weren’t satisfied with just a few. So how do we market our game? We tried using Reddit & Twitter but to not much success (we don’t have a big following on Twitter and I don’t think we did the best posts for Reddit). One method that did bring in some ratings was rating other people’s games and leaving useful comments on them. This will often lead them to check out your game, but it isn’t meant to be a transactional deal, although that was another method that we saw being used! Where people would advertise rate for rates, where the rates would have to be confirmed through a screenshot. We didn’t go for that method but it did work for quite a few people. 

Our big success was using Twitch to advertise our game. There were some streamers that would allow viewers to submit their gamejam game to be played on stream, and in between the games that the streamer plays the streamer would promote their own gamejam game that they made. Submitting games to other streamers did get us some ratings (although we’ll talk about some issues with that later), but what really helped was streaming ourselves. On the first day of streaming (with 0 following before) one of our developers got peak 50 viewers, and averaged 24 viewers over a ~ 5 hour stream. These are crazy good stats for a streamer with no following! The developer continued streaming throughout the ratings week and hit affiliate (not the biggest milestone in the world, but hitting it in a week is still pretty impressive). Lots of the ratings that we got were from people that had come checked out the stream. Since the gamejam our developer have continued streaming and it has been a great tool to create a community around the game.

We had some issues when streamers would play our game. Due to lack of optimisations, an uncapped framerate and lack of quality settings many streamers struggled to play the game. While it would often look smooth to the streamer, the viewer would be getting around 10fps. Capping the framerate did help in some cases, so we did upload a capped frame-rate build for streamers (after checking with the mods that this would be okay to do) where the only change was that the frame-rate was capped. This didn’t always solve the problem but it did help. In general our game was very GPU intensive, which did limit our game to some players.

The feedback from people playing the game, while generally positive, did highlight some flaws, particularly in first time player experience. The game was not intuitive and was frustrating to try to learn. While we couldn’t edit the game at this time, we could edit the gamepage, and so we added more instruction to the gamepage, helping people better understand how to play the game, in lieu of a tutorial. We also uploaded some gameplay footage to visually show how the game should be played.

We also updated our gamepage with an animated thumbnail when people mouseover it to help improve click through rate.

Not having a playable in browser version of the game does somewhat reduce the number of ratings that you get and so I would recommend it if you can. While we still got a good number of ratings without having a browser version, I’m sure it still does help a lot.

We ended up getting 80 ratings which was in the top ~5% in terms of number of ratings per game.

We are going to continue working with this team making this game into a full commercial product, and hope to be here in the future with a post-mortem when that happens! Link: https://www.getziggyinto.space/