Guntastic - An arcade-ish game involving shooting, mayhem, gore and yelling

Hi guys, we’re finally confident enough to show you a little project we’ve been working over the past year and a half.

We recently started sharing some progress on socials as well as on our new dev blog, and we’d like to keep this thread updated with what we’re working on. The core game systems are now sufficiently stable, so in the coming months we’re going to focus on adding new content such as weapons, maps, characters, etc.

Please feel free to share your feedback: we’d love to hear back from you! :slight_smile: [HR][/HR]

An arcade-ish game involving shooting, mayhem, gore and yelling.

Battle with up to four local or online players in lightning-fast, one-shot one-kill matches over levels changing every few rounds.

  • Fast-paced, one-shot one-kill combat.
    Choose from a vast arsenal of weapons and powerups to wreack havoc on your foes.
  • Easy to learn, hard to master gameplay.
    Although the basics are easy to pickup, Guntastic offers rich gameplay possibilities so that two matches never play the same.
  • One screen, 4-players online/local multiplayer.
    Challenge up to three friends in local couch games or compete against people from around the world in online multiplayer matches.
  • Retro and over-the-top visuals and soundtrack.
    Everything in the game is reminiscent of the 16-bit era, and was born out of our love for the videogame and movie classics of the past.
  • Dynamic levels changing every few rounds.
    Use the environment to your advantage: most levels feature dynamic elements that create spectacular ways to frag opponents!

So cool!!!

Really cool, going to subscribe to this thread to follow.

awsome so cool

Nice ! Have you done that guys with paper2D ? Everybody say paper2D sucks but your game looks really cool

Thanks for the nice words guys! :slight_smile:

We started out with Paper2D, but currently use a custom 2D framework for sprites and flipbooks (tilemaps are still handled by Paper2D).

Speaking of Paper2D, I think it’s vastly underrated: it’s quite stable, has lots of features and fairly good tools. Unfortunately, development on it has pretty much ceased, so unless you’re willing to spend time fixing bugs and adding any missing features you need, you’re pretty much stuck. [HR][/HR]
A quick update: over the past few weeks we published a couple of posts on our blog that go over some of the design decisions we’ve taken at the very beginning of development. We didn’t cross post them here since they’re not really related to UE4, but here’s the links in case you’re interested:

  1. Baby Steps in Pixel Art
    This first post goes over some of the basic principles behind pixel art platformers (i.e. finding a good tradeoff between gameplay requirements and graphics resolution).
  2. The Basics of Guntastic
    The second one describes our approach to the issues outlined in the first post.

Arcade its soo Good !

Hi guys! A couple of weeks ago we implemented our fifth character in the game (which you can see below, Dragon Ball FighterZ style!), so I thought it might be a good time to briefly talk about our workflow when it comes to creating characters, as well as how they are setup in the engine. In the end, this came out way longer than expected so we decided to post it on our blog, but I still wanted to try and post it here in its entirety as well! I really hope the forum doesn’t mangle the layout too much…

In The Beginning…

The process begins with our artist Simone doing some quick sketches of different characters, from which we usually pick the one we like the most.

He then iterates on the design until we have something we like. Otherwise we drop a tear, throw everything away and start over.

Once the character design is final, he then proceeds to create all the required animations. It’s important for the design to be as refined as possible at this stage: altering it afterwards requires massive time as it involves editing all the animations frames one by one (a character currently has 162 unique animation frames – and counting!).

Although I tried to make him do the jump to a pixel-art drawing software (such as Pro Motion NG or Pyxel Edit), he stubbornly continued to use Photoshop for all the editing. This required some technical setup to allow for quick iteration times: each animation frame is on a separate layer, which is linked to a keyframe in the timeline for easy previewing. Each PSD usually contains multiple characters so that it’s easy to use previously created characters as blueprints for a new one.

From Photoshop To UE4

Exporting all the frames by hand would be madness, so we have a custom Photoshop script that automates the export process and generates a single PNG file out of each animation frame. Automating error-prone and repetitive tasks is invaluable for the overall workflow, especially for small teams with no fancy QA department. :slight_smile: Our export script also helps us maintaining a strong nomenclature, which is invaluable to avoid the risk of going insane tracking errors, duplicated sprites, etc.

Here you can see a video of the export process (which unfortunately the forum doesn’t let me embed).

We then use Texture Packer to compress all the frames in a single texture atlas. If you do any 2D game development and don’t know about Texture Packer, you really need to check it out: it’s a nifty utility that packs multiple sprites into a single file (A.K.A. atlas, or spritesheet). This not only helps lowering texture memory usage, but also keeps the assets tidily organized - which soon becomes a necessity when you have to deal with large amounts of sprites. Texture Packer also works from the command line, so this step can be automated as well. At the moment we have a single atlas per-character.

The next step is (re)importing the atlas into the engine. We started out using Paper2D, but slowly transitioned to a custom solution over time. This allowed us to have far more control over both the import process and the rendering of sprites and flipbooks.

Once the atlas is imported we end up with multiple folders containing the sprites and flipbooks ready to use. To keep the amount of manual editing to a minimum, the system is also fed with spreadsheets containing useful defaults that are automatically applied to the sprites and flipbooks (such as frame rate, etc.). Additional animation assets are also generated in this step, which are used by our animation system to actually play the animations - more on this later.

Character Setup

Before digging into the actual animation system, lets briefly talk about how our characters are setup. In Guntastic a player can run, jump, shoot, fall, etc. – all at the same time. What’s more, a player can also aim at different direction while performing any of the aforementioned movements. We also have different weapon types, such as pistols and rifles, that require different character stances. Moreover, some animations such as jump, land and firing are one-shots rather than loops.

While prototyping the game, we soon found out that having full body animations for every permutation of the different actions a player can perform would soon make the animation count skyrocket, out of reach of the hands of only two developers. After some tinkering we ended up splitting the character into two different sprites: one for the lower body (legs, feet), and one for the upper body (torso, head, arms). This is similar to what it’s done on 3D characters, and allowed us to seamlessly play multiple animations on different parts of the body at the same time: for example we can have a walk animation play on the legs, while a firing animation is playing on the torso.

The Animation System

Our animation system is implemented in C++ in our custom Character class and works by using the descriptor assets that were generated during the import process. These hold references to different flipbooks, each representing a different movement state (i.e. idle, walking, etc.), a different weapon stance (i.e. pistol, rifle, etc.) or a different aim offset (i.e. forward, up, down). The system then sorts out which flipbook to use on the lower and upper body sprites based on the current character state.

We also apply some modifiers to the animations: for example, the walk cycle is played faster or slower based on the current movement speed of the character. The whole system was kept intentionally simple (~150 lines of code) by enforcing constraints on the animations, which also make authoring them simpler. For example, all animations runs at framerates that are whole divisor of 24 FPS (i.e. 12, 6, etc.) to easily sync them.

Wish List

While the whole system works quite well, there’s still large room for improvements (as it’s always the case in game development!). Something I would have liked to have the time to work on was a editor extension that would import the animation frames directly from the PSD files. The extension would then take care of packaging the frames into texture atlases automatically, thus eliminating the need for external utilities and scripts.

Something I also would have loved to implement was a visual, state-machine-based animation system for flipbooks - similar to what Unreal Engine 4 provides out-of-the-box for skeletal meshes. While presumably less performing than the current hard-coded C++ solution (but then again, performances are rarely an issue in modern 2D games!) it would have helped tremendously during the prototyping phase. [HR][/HR]Thanks for staying with me for this long! Please let me know if you have questions or comments! :slight_smile:

Hi everyone! I should really post here more often! The past months have been quite exciting at the studio. We’ve been to an handful of events including Milan Games Week and EGX Rezzed. Kudos to Epic for sponsoring part of the indie booth in Milan and the Unreal Showcase area at Rezzed.

Work on the game is progressing at a steady pace in preparation for the Early Access release (scheduled for later this summer! HYPE HYPE HYPE!).

Stability & Performance

From a programming point of view most of the work that recently went into the game has been aimed at increasing the stability of all the game subsystems. This was done to make sure new content (such as weapons, levels, characters, etc.) can be added more easily once we’re out in Early Access. Performance has also been one of our top priorities and the game can now run at a solid 60fps (capped) on an entry-level AMD Ryzen 2200G system using the integrated graphics. During the events, the game worked on this setup non-stop almost 10 hours a day, several days straight without ever needing a restart (or crashing).

Since to power the game we’re using a custom 2D framework atop of UE4 that I’ve written from the ground up, I’m quite proud of the results (so I’ll probably bore you with more details in the future :p)! As a side note, UE4 is a beast of an engine: it can power cutting edge ray-traced graphics while being scalable enough to flawlessly run our naive 2D game on low end hardware.

Arcade Experience

We also spent a lot of time refining the overall user experience. Since we want Guntastic to feel like a game you could have played at an arcade, everything in the game should be simple to learn and self-explanatory, but at the same time provide enough complexity to keep you hooked. In Guntastic players can only move, jump, pickup a weapon and shoot. This means one analog stick and three buttons and that’s it - a players knows how to play in seconds! Still, we worked hard to build a lot of complexity in the way weapons and powerups can be used and in the way levels can be played. Both players and journalists seemed to enjoy that, so we take it as a good sign that we’re taking things in the right direction.

New blog posts!

I also took some time to write a couple of blog posts (should do this more often as well, but days fly by while developing games!):

3 Tricks to Improve Pixel Art Rendering in UE4](3 Tricks to Improve Pixel Art Rendering in UE4 | Dev Blog | Ludicrous Games)

A series of tricks that we use inside Unreal Engine 4 to obtain a more authentic pixelated look in Guntastic.

Anatomy of a Level](Anatomy of a Level | Dev Blog | Ludicrous Games)

A writeup of the workflow we use to build levels for Guntastic.

PS: we now have one of those things cool kids are using nowadays, a Discord server! Feel free to join and have a chat with us if you feel like so! :wink:

As an attempt to try and force myself to publish progress on the game on a more regular basis, I’d like to start writing about what we work on during our internal dev sprints. These usually take two weeks to complete, so posts will mostly be on a fortnitely (bad pun intended) basis. I’ll be cross-posting these from our dev blog, but I’ll make sure to add additional UE4-specific insights here as appropriate.
[HR][/HR]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!

To try and cut on the amount of sprites, the different color variations are implemented using a texture gradient containing the different color shades (i.e. from dark red to light red for player 1, from dark green to light green for player 2, etc.) for each player. This gradient is then fed to a simple shader that samples the correct color and applies it on the sprite using a mask.

Additional Changes
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. Implementing this in UE4 was surprisingly straightforward!

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!).

As a side note, I wished that handling network errors was easier to do in UE4 and won’t require digging into several different classes such as UEngine, UGameInstance, UOnlineSession, etc. just to find out what the engine does (and especialy what it doesn’t do) for you out of the box.

That’s it for now! :slight_smile:

Wow! It’s already been two weeks (okay, maybe three!) since the last update. :eek: Let’s see what we got to share…
Restyling the Sewers

The “Sewer” environment was the very first one 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 our artist 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.

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’ve done up until now is still 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! Please feel free to share your feedback! Expect more in the upcoming weeks as I wrap my head around the remaining screens, dialogs, fades and actual implementation!

And that sums it up for now. :slight_smile:

Time flies! Welcome to our third dev log.

Logo Refresh

Over the past few weeks we worked on refreshing the Guntastic logo as part of our ongoing effort to polish things up in preparation for Early Access.

The old logo had a number of shortcomings, the main one being that it didn’t properly represent the game as a whole. Guntastic is a crossover between a shooter, a party game and a brawler. While the shooter vibes were strong in the old logo, we felt the other genres simply didn’t get through. Feel free to head over to our development blog for additional details!

Main Menu, Cont.

Work on the main menu is progressing at a steady pace. In the last post I showed you a mockup of the options screen built in Photoshop. Here’s the fully working in-game version:

A lot of time and effort went into making sure the user interface was flexible enough to support fades and animation and be usable regardless of the input device the player is using, being it a keyboard, a mouse or a controller.

Coming from a web development background, I wish different UI frameworks were available for UE4 that would save me the time of having to build UIs from the ground up (including controls, fade & animation logic, tweening support, focus management, different state handling – i.e. hover, focus, pressed – etc.), so that I could only concentrate on the actual graphics, layout and high level logic.

As always, feel free to share your feedback! :slight_smile:

Man it’s really awesome!!!

Thanks! :slight_smile:

Time for a new update!

New Blog Post: The Music of Guntastic

Our composer and sound designer goes over how he created the retro 16bit-like soundtrack for Guntastic using modern production techniques.

Say “Benvenuto!” to the Italian Localization

Localization support finally found its way into the game as part of the ongoing user interface work. We decided to start with an easy language to test things out: Italian.

It was surprisingly easy to get localization working in UE4: documentation is excellent and tools just work. I initially thought about using String Tables to manage localized text, but then went with PO files as I found the workflow to be more intuitive. Asset localization also simply works, although asset reloading isn’t supported in packaged games which is a severe limitation IMO.

New Character Portraits

The character portraits we had in game until now served us well during development, but were really just placeholders. As part of our ongoing effort to polish things up in preparation for releasing the game, all characters now feature updated portraits in the lobby and ladder screens.

The lobby screen itself got a small layout update to better handle the new portraits and now only lacks a couple of features (all related to online play) before it can be considered “gold”.

That’s it for now! If you happen to be in Milan next week, come play Guntastic at Milan Games Week 2019 (you’ll find us in the indie booth!).

Hi everyone! After nearly two years of development, we feel the time is right for a public beta test. So we’re extremely excited (and a little bit scared! :p) to announce that Guntastic will be in open beta from Thursday, 24th October to Sunday, 27th October!

The goal of the beta is to make sure online multiplayer works in preparation for the game’s release. Feel free to register if you feel like joining some arcade action and help us squash some bugs! :slight_smile:

Hey everyone! After the great experience running the beta last month we felt that developing the game in an open conversation between us and the players was the way to go. As such, I’m really happy to announce that Guntastic will release in Early Access next week, on Thursday 21st November.

I’ll continue to share insights about development here during Early Access. :smiley: We were also featured in last week’s Community Spotlight. Thanks Epic!

I can also finally announce that a Xbox One version of the game is coming in 2020! I didn’t have much time in my hands to properly play around with the SDK, but I managed to get a build of the game compiling and running on the console. Doing that (apart from some initial issues setting things up) was surprisingly easy. Great job, Epic (and Microsoft)!