Welcome to the second installment of our biweekly (more or less!) dev log. Let’s dive into what we worked on over the past few weeks!
Restyling the Sewers
The “Sewer” level was the very first environment we worked on for Guntastic and it started to look dated in comparison to the other levels as a result. Over the past few weeks Simone gave it a fresh lick of paint:
This work is part of our ongoing effort to polish the content that’s currently in-game in preparation for Early Access. We feel that it’s important to ship with everything at the same quality level, so that once the game is out we can concentrate most of our resources on keeping the game fresh by adding new content rather than devoting all of our time polishing up what we have!
Main Menu, Pt. 1
One last major task is now standing between me and the game’s release: the main menu. This is a major undertaking that will keep me busy for several weeks. Most of what I have now is too experimental to show, but below you can find a sneak peek of the new “Options” screen.
Please note that everything is subject to change! I look forward to your feedback. Expect more in the upcoming weeks as I wrap my head around the remaining screens, dialogs, fades and actual implementation in C++!
As a side note I don’t like working on UIs. At all. It’s a very time consuming process and I can’t seem to ever be satisfied with what I end up with. I hate it! There, I said it.
As we step up the pace towards finally releasing Guntastic in Early Access later this summer, we’d like to start sharing more insights into the actual development (better late than never right? 😄). Our goal is to write these kind of posts on a biweekly (in the fortnightly sense) basis or so. These will include things we’ve been working on during our internal dev sprints. So, lets get started!
Things has been moving slowly over the past few weeks due to one half of the team (that is, me! 😃) being on a short annual leave. Nonetheless, we got some cool things to share.
Meet Mr. Poopypants!
First of all meet our latest playable character:
The concept for this character was born as an inside joke, but, the more we talked about him, the more he fit with our long-term goal of creating as many different designs as possible. Hope you like how he turned out!
Color Tinted Character Variations
One of the most popular request we got while showcasing the game at events was to make characters more easily distinguishable, especially in situations where two (or even more!) players choose the same character. We already had some hints in place: weapons and projectiles, for example, were already tinted of the player’s primary color (i.e. red for Player 1, green for Player 2 and so on). Characters also already featured a tinted outline. Listening to your feedback, we took things a step forward and also tinted the characters themselves!
Support for Private (Invite-Based) Games
This has been on my to-do list for a long while. Private games are now fully working, including receiving and accepting invites through Steam.
Improved handling of network errors
No one likes getting disconnected from the server while a game is in progress, but things happen. In preparation for releasing the game we worked on gracefully handling the most common errors, with visual notifications popping up on the player’s screen (UI still a work in progress!).
That’s it for today, see you in a couple of weeks! Don’t forget to join us on Discord to stay up-to-date with the latest news. 😃
Over the past few months we spent quite some time iterating on levels in preparation for Early Access. Most of them now feature improved graphics, a dedicated music track and countless gameplay improvements. But how does a level in Guntastic come to be?
The workflow we currently use is the result of our past work experience with 3D shooters and experimentation done in the early production phases of Guntastic. If you’re only interested in the actual workflow, feel free to jump to the final section of the post. Otherwise, read on.
In The Beginning…
When we first started working on Guntastic we didn’t know much about what the game was going to be, apart from the fact that it would be an arena shooter at its core. We decided to go this way in part because we love shooters and we believe that going indie should be about building the games we love (take this you cold, number-crunching business people!), but also because most of our past work experience involved building shooter games. With so many things that can go wrong developing a game, we felt that a shooter was our safest bet (reality check!).
One of the fields in which we benefited the most from our background was level design as most of the guiding design principles for 3D levels can be applied to their two-dimensional counterparts. In particular:
- Gameplay and visuals should work in tandem. Always design for gameplay first, but having an idea of how the level should look like in the end makes the final result feel more natural.
- Using a modular approach based on grids and reusable assets makes it easy to think about, prototype and build the levels. It also promotes visual clarity, aiding players navigating the world in an intuitive way.
- Each level should look and feel unique, both from a visual and gameplay point of view. Players are more likely to remember how to play a memorable level rather than an uninteresting one. (Plus, memorable usually means more fun at the design stage!)
Prototypes! Prototypes! Prototypes!
Guntastic, however, was still our first 2D game – and a very particular one. A whole level needs to fit on a single screen and have enough room to accommodate four players at the same time, which puts severe constraints on the level design. We also had character movement to sort out: how high could a player jump? Were there going to be special movements such as dodges or wall jumps in the game at all?
Since the best way to figure things out is through experimentation, we started creating rough level shells to play with. The following is the prototyping kit I originally put together in Photoshop back in 2016 and that we still use today to block out level shells. It includes tiles of various sizes and shapes that can be combined in a wide variety of ways. The idea of having half-tiles came a bit later, and proved crucial to deal with the very limited amount of space available on screen.
We spent several months iterating on an handful of levels as we tweaked the movement mechanics to our liking (more about this in an upcoming post). Dynamic environmental elements such as moving platforms, lifts, jump pads, areas with lower gravity, teleporters, destroyable elements, death pits, traps and more were gradually introduced into the mix. Working almost exclusively in Blueprints proved invaluable at this stage, enabling very fast iteration times – although most things were later moved to C++ for additional flexibility.
During this time we also started investigating the production of tile sets and environment pixel art. The first environment we envisioned was an underground sewer. While definitely not the fanciest way to start, it provided us with a good amount of artistical challenges in a small and controllable scope. It gave us a chance to practice with different materials, rounded shapes, backgrounds, lights, decorations and more and proved a great learning experience overall.
Of all the levels built during this stage, only two survived in the long run – with the rest being discarded because overly complex, difficult to navigate or simply boring to play.
Summing It Up
As we built new prototypes we found ourselves relying more and more on dynamic elements. Doors, jump pad, lifts and destroyable elements not only helped players move faster around the level and created unique gameplay opportunities by encouraging players to be creative with their surroundings, but also made levels far more unique and memorable. Some elements simply didn’t work and were cut. Moving platforms, for example, required way too much room to work, leaving no space for anything else. We also realized that having traps and death pits that killed players on touch (which counted as suicides, resulting in a one-point penalty) was frustrating and often left players wondering as to how and why they died and lost a point.
The turning point with environmental traps was the lift in what later became the Sawmill level. The lift needs to be activated by a player and has buzzsaws underneath that kill opponents on touch, rewarding the player who activated the lift with a point when that happens. This was a big paradigm shift. Players were now in charge of activating the traps found in the level and could actively exploit them to their advantage without risking penalties. This gradually pushed us into implementing dynamic elements that were more audacious, to the point that new levels could be built around a main dynamic element which also set the overall visual theme of the level.
The Actual Process
This brought us to the process we currently use to create levels. We first envision a strong dynamic environmental element and then block out the level around it. During this stage we search the internet for reference images and prepare mood boards to help later on in the process. The first sketches of both the layout and visuals are carried out using pen and paper. Things don’t need to look pretty at this stage (and in fact they don’t).
Once the layout looks promising we rebuild it inside the editor using the prototyping tileset. Dynamic elements are implemented at the same time. We test and iterate on the level until we’re satisfied about how it plays, changing the layout and the way dynamic elements work as we see fit. If we don’t like where things are going we simply throw everything away and start over.
The next step is what we call the mood pass. I take a screenshot of the final level layout (this is one of the few cases where having levels that fit on a single screen actually helps 😄) and do a paint over in either Photoshop or Pixel Edit blocking out the main foreground and background elements. Things don’t need to look pretty yet, but it’s important to discern what’s what. Special care is also put into making sure everything is tidily aligned to the grid. A base color palette is also defined at this stage to set the overall mood.
The level now pass on to Simone who uses the mood boards and additional references to perform the main visual pass.
Once the visual pass is complete, it’s my turn to break everything up in an easy-to-use tileset. This is important to rationalize the graphics and helps in case we need to do small adjustments to the layout later on (which we try to avoid, but things happen!). The level is then reassembled into the editor, where we add all the final bells and whistles such as lights, eye candy and visual effects.
The whole process usually takes a month from start to finish. Naturally, it isn’t always possible to follow this workflow to the letter, but the price paid in terms of additional strain and time needed to complete a level in those cases can be pretty high. Game development is a messy business! 😄