I’ve been interested in game development for a long time. During my university years, I would manage to pass some of my courses with minor game projects. But due to a lack of time I could never approach this subject more seriously. So when one of us suggested participating in a game jam, I agreed without hesitation.
Rules of the hackathon
Jam is a term borrowed from the world of music, where it’s used to describe a gathering of musicians for an act of a joint improvisation. Similarly, during a game jam people gather together to form teams and they all create some game for a given theme under a given time constraint (usually 24 to 48 hours, sometimes even a week, like in our case). It’s a hackathon for game developers. When the time given for the development is up, comes a time for rating the resulting games. Each participant votes for other competitors’ games, after having previously played through them of course. Usually the voting itself is split into categories, such as the visual effects, sound design, gameplay, creativity or correlation with the theme. Because of that the overall ratings are more fair and it’s possible to award a game in a specific category. Based on an average of all of it’s ratings, the winning game is chosen. Such an event is a great opportunity to put oneself out there and gather a few people interested in continuing the project afterwards or taking on whole new creations. Usually such success motivates the devs to release a full-fledged game. Here are some of the well-known games which were born during the game jams: Super Hot, Goat Simulator, Surgeon Simulator, Gods Will Be Watching.
The game jam we picked was Bored Pixels Game Jam. We had a week before the beginning of the jam, which would last for another week. The jam’s participants were signing up in teams of various sizes. The jam’s main theme, which could serve to impose an artistic direction or even game’s mechanics, was picked with a survey that all participants could take. After the theme was announced, all participants would’ve had a week to submit their works. An additional condition was to design the graphics in spirit of pixel art, that is imitating the graphics of old 2D games which are widely considered nostalgic by gamers. Our team signed up a whole week before the announcement of the theme. It consisted of Piotr, Adam (myself), Maciej, Remik and Martyna. And so would await us two weeks filled with excitement.
Game development is software development
The subject of game development is closely related with developing any other IT project, although it does have qualities significant for the industry. The most important matter for independent developers, who don’t have any publisher above them, is to simply finish the game. It is very often that the devs eagerly start a project but the longer it takes, the less of the initial enthusiasm is left. Not too long afterwards they find themselves putting less and less time into the project, until the startup fades into obscurity and it never sees the daylight as a result. Another cause with the same effect is devs focusing on adding more and more functionalities, while the existing ones are not finished yet. Consequently, despite investing a lot of time and effort and project ending up huge, there is not a single element which works all the way through. At this point in development it is very difficult to tie everything up, because it seems like a dull, time-consuming chore and often projects get permanently stuck in this state of pseudo-progress. This problem is not specific for the gaming industry alone - a lot of startups face it trying to please their consumers with new functionalities, while forgetting about the basics.
Create MVP first
Luckily there are several ways of dealing with these issues. Often in order to avoid getting stuck, a decent start is required. A crucial strategy is creating a MVP (Minimum Viable Product) first and only then start adding new elements as complete modules. This way a stable working version is constantly available, which can be tested or presented to someone, whether it’s a potential publisher or target consumer. As for the devs themselves, a direct profit comes in form of an awareness of constant progress and satisfaction from having a portion of target product that already works. Therefore it’s better to focus on 3 key elements at max which best describe our gameplay. In case of a game about a well-known plumber saving princess, those would be running, jumping and dying by falling into a pitfall. In order to learn more about the MVP, read the following post on our blog which fully covers this topic.
Having something that already works, it’s important to hand it over for testing as soon as possible to a person unrelated to the development process, who would be able to judge the product from a fresh perspective. The sooner we learn something doesn’t work as well as it should, the easier it will be to diagnose it and it would cost us less to fix or even remove entirely the faulty code. For instance, if during the development of that plumber game we mess up something in the jump mechanics, we won’t be able to detect what’s the problem, if we have tons of enemies to defeat. The players will feel that something is off, but they won’t be able to tell what exactly, they might even give a different reason altogether. Fail Faster!
Technologies we used
Without prior knowledge about the main theme, we focused on choosing the base tool we would use. We chose the Godot Engine. It’s a 100% free, open source alternative to Unity and Unreal Engine. Godot takes up less memory, compiles faster and natively supports 2D games. By default it uses its own scripting language named GDScript, the syntax of which is very close to the Python language. Python is a leading programming language used for development by the Code Poets. Thanks to the whole knowledge on Python we have gathered previously, it was easy for us to take on this new technology. We then gave ourselves a week to get familiar with the environment.
A view of Godot’s user interface
As soon as we learned about the jam’s main theme we met to plan out the gameplay. In our minds a wide array of gorgeous, massive titles with complex mechanics and intriguing storylines was born. However, one cannot plan endlessly and we had to get to work fast. After all, we didn’t have hundreds of people on our team or a multimillion budget like the AAA games. It wasn’t until the very end of the organizational meeting when we cooled down a little and realised that we must focus on three things at most, otherwise we wouldn’t have been able to make it. We decided to make a top down shooter with an enemy wave spawning system.
We had to split the tasks. We needed music, graphics and all of the mechanics such as shooting, dealing and receiving damage. Maciej took on creating the music, Piotr and Remik focused on game mechanics and I stuck to the pixel art, which turned out to be a lot more difficult than it previously seemed. Unfortunately being able to present your vision with merely a few pixels is very tricky. Since the development of the game mechanics was going smoothly unlike the graphics, Remik joined to help me with it.
Interestingly enough, the project pretty much managed itself - a lot of that is owed to Code Poets’ philosophy, which emphasises self-organization. Each one of us would report a need for specific resources on a corresponding Discord channel, which we were using for communication. For example, if Piotr knew he wanted to take on the shooting mechanics, as soon as he had finished the current task, he would have reported at the “pixel-art” channel that there’s no shotgun sprite that the character could use for shooting. The lack of hierarchy and sense of responsibility over the given task had a positive influence for both the velocity of development as well as decision-making.
No crunch, no fun:)
Although each one of us tried his best to spend as much time as possible for the game development during the working days, by Saturday we still had a lot to go before we even had a working demo. In face of the upcoming deadline, which was due Monday morning, it became necessary to prioritize the tasks and narrow them down to the required minimum. Ultimately during the weekend we completed the largest portion of the gameplay and tied everything together. It required crunching - massively stressed out, our team would work on finishing a stable, working version until the very last minute. All the bugs which were making the gameplay harder got the first shot. Later we moved on to the user interface. But we did it and it was worth it! The result
Despite the major difficulties regarding the amount of remaining tasks, major stress and issues with internet connection at the crucial moment, ultimately our game made it to the submissions. After submitting the game for rating, the participants could still patch the game until the very end of the competition, in order to fix any concerning bugs, which of course popped up in a few places in our game as well. The voting and rating lasted for another week. Ultimately, our game took second place among the eight entries. The final result of our work can be seen here. We felt immense satisfaction from all the effort we put in and a motivation to further pursue our common passion. We’re planning on continuing the development of our game in hope that one day it might become something more than merely a “game for competition made in a week”.
If you think we can help you with the development of your project, you can fill out this simple form and we will get back to you with a free quote within 24 hours.
A gameplay screenshot from a finished game