Twist Turn Shoot Burn: A Postmortem

This was originally written as a blog post on the Ludum Dare website back on October 10th.

Icon.gif

^^^ Click to Play ^^^

It’s now been just over a week since Ludum Dare 47 began, so an ideal time to reflect on how well things are going so far. I’ve been taking part in game jams for seven years now, and this was my 16th Ludum Dare, although you find that every game jam you do has a challenge that you never expect, no matter how many you do (and I’ve done over 50 at this point).

So the game: Twist Turn Shoot Burn is an auto-run ‘n gun, you run around a randomly generated path shooting red things from one of two lanes. Here’s how it was made:

The Idea

349b6.png

As I wrote in my entry post, I wasn’t a real fan of any of the themes. I was actually hoping “Technical Difficulties” would make it to the final voting round, but alas you make with what you do. My usual plan is to brainstorm ideas, with the goal to have at least one idea per theme. Ideas in this case is usually a simple phrase to describe a game’s setting or mechanic.

All I had for “Stuck in a Loop” was this: Run (and shoot) inside a loop.

Yeah, not sure why but even as I slept, my attempts to think of what game I could make around this theme always reverted to this. As such I just gave up and decided how on earth I was going to get a game to work…

Day One

So to people who know my approach to game jams (all five of you…), I have a set of rules that I always follow when working on game jams regardless of length. A lot of these rules were written and refined from experience for efficient development and maintain good wellbeing.

EjL_Em8WsAYHmKA.png

So day one was purely focused to develop on gameplay, and the first thing I needed doing was having the player run around a basic path.

Following rule four (stick mostly with what you know), I figured I’d do a tilemap but I was worried about how to do collisions. My engine’s tilemap system isn’t built to handle slopes and curved paths, and I wanted the player to go around a proper loop. I was worried that I was gonna have to figure out how do write a Sonic-style platforming system. Then I was literally booting up my PC, first thing in the morning, when I realised: I didn’t need to calculate collisions, I just need to calculate positions.

I made each game object stick to a specific position based on an X and Y value (between 0 and 1) what tile it’s currently situated in. The X value would position it from one side to the other, and the Y value would handle gravity and securing it to the floor. I originally had it up and running by midday, however in my original approach, the player would move fine on tiles that moved straight, but would float on turns. It took an hour’s walk, a hour lunch break and about two more hours for me to get it to work correctly.

LD47-00000.gif

It was also during that first lunch break and walk that worked out how to do obstacles. I only wrote four enemies: Same Direction, Opposite Direction, Bounce and Always Flying. I also decided to do something similar to Super Crate Box, have it so enemies would spawn the moment you defeat one. All the enemies use the same movement behaviour as the player, which funnily meant the Always Flying enemy was the hardest to implement because it wasn’t straightfoward to disable gravity.

LD47-00003.gif

You might notice the player had the ability to jump. The original plan was to have the player shoot, jump and change places. I eventually decided to diable jumping because I found myself always changing direction more than jumping.

Day Two

The base game was pretty much done by the end of Saturday, I did want to make the levels more random but I wasn’t sure how to do it, so I decided to leave it as something to implement if I had time. For Day two, it was all graphics and sounds.

This is where rule 5 (“Make Your Content Easy and Noticeable”) comes in. This rule was concieved after Ludum Dare 42, where I spent somewhere around five hours on a detailed player character, despite how small it actually appeared in the game itself.

Piskell is my tool of choice for doing pixel-based sprites, as it’s easy to pick up and test out frame-by-frame animation. All I can say for the player character is that I cannot confirm or deny whether the recent popularity of Among Us or Fall Guys had any roll, but I will say that the 2-bit palette of Downfall was deep in my mind when thinking of the visual design.

Visual effects are also a prerequisite for most of my games, partially because one of my game dev influences being Jeff Minter, and I’m a huge fan of his vibrant nightclub/psychedelic visual aesthetic. The main effects I use were Chromatic Abberation (distorting the red and blue colours), Bloom (make pixels glow), scanlines (TV effect) that constantly offsets, Bad TV Shader (to get the noisey distorted look) and a fisheye lense (to make it buldge out slightly).

LD47-00004.gif

For sound effects, I used sfxia and ChipTone. If I wanted more realistic sound effects and wanted to go with the loose jam rules I’d mix and mash stock sound effects together, but I know with this game’s visual design that I was going with a retro-esque feel.

For music, LMMS. I’ve gotten comfortable with it as a music creation tool, although when I tried to mess around with soundfonts and VST plugins for retro inspired music. That’s when I went back to Jeff Minter’s games and decided to try a drum ‘n bass approach. Fortunatelly I did experiment with this for an earlier Tetris recreation project, and I was able to come up with a 1 1/2 minute long loop that I was satisfied with.

Based on my social media posts, I had everything submission ready by 4:30pm. That meant pleanty of time to get the submission details ready and add in stuff. I added a new enemy at this time, and tweaked around the controls, but I didn’t think there was much that I needed doing. It wasn’t until two hours before the deadline that I decided to give randomly generated levels a go, you can read up on how well that went here.

LD47-00007.gif

Conclusion

I’d say this game went better than I thought it would, I’m always into making small arcadey games and after this pandemic had drained me from doing personal game dev projects, this one just revitalised me in many ways. That’s not to say it was perfect. So time to explain some issues:

  • Camera: I had spent the last hour trying to figure out how to get the camera to focus in on the randomly generated level, instead of the full screen. Unfortunately time had ran out before I could figure it out, so I had no choice but to leave the camera in its full form. The “Player” mode I thankfully decided to leave as an option, as much as I thought it was a fun camera mode, I could tell it was disorientating for some players.
  • The Volume: So when I was working on the music, I had the PC and headphones on full volume, and I thought the volume was perfectly fine. Turns out my headphones aren’t as strong as I thought they were, cause players on some streams were taken aback by how loud the music was. I’ve deamplified the music for the post jam build, but I’ve also had feedback suggesting not to have full volume by default.
  • Menuing: Yeah, I probably could have spent those final hours adding some important stuff to the menus to make it clearer and easier to modify, especially the option to turn off the visual effects that might be an eye strain to some people. In hindsight, I also have a config class that I used in a past game that I could have easily dropped into this game, so saving options would have been a breeze.
  • Linux: As much as I work on Windows, I have a soft spot for Linux and major respect to their userbase. I usually have a Linux Mint distro on hand to easily produce a native Linux build of my games, and let users decide whether to download it or not. This time around, I was curious and posted to a Linux games community (shoutout to /r/linux_gaming on Reddit!) to get actual Linux gamers to try it out. Turns out quite a few couldn’t get the game to work due to a libcurses dependency, and one of the Twitch streamers that tried the game on Arch Linux (shoutout to @marcmagus) found out his gamepad ran funny with axis inputs when he played the game.

So yeah, there’s a lot to deal with. Perhaps in the next update I do to the post build, I should add a long warning for players with senstive eyes and ears before I do anything else. Thanks to everyone for playing, thanks to my friend Kris for helping me with brainstorming ideas and here’s hoping to a good ranking!

Icon.gif

^^^ Click to Play ^^^

7DFPS and Desert Bus

Don’t worry to anyone who has been following what I’ve been doing this year, I haven’t missed October or November. I’m so close to finishing this goal of mine for 2018 and my next post will include not only that month’s jam entry but a summary of what I have done over the year. But for now, more jam games.

In October, I took part in 7DFPS, as the name implies the jam is focused around games in the first person shooter genre. The jam itself is probably best known for being the source of the wildly successful indie title SUPERHOT, where the prototype was created for the jam back in 2014. I decided to take part in this jam to see if I can add to the 3D game system I developed in September’s game jam.

7DFPS-00001

One issue I had when working on this system was that I didn’t have a fully working software frustum culling system, this would allow me to avoid draw calls on 3D objects that were not in view of the camera. What you see above was the issue I had before. It took a number of trial and errors and reading on how to properly set up and transform the plans before I had it properly culling the right objects. I also added some other mechanics I need to make this a classic FPS, jumping while taking into consideration multiple floors and shooting projectiles.

As you can see from the projectiles, some of them were clipping unusally. This is a side effect of rendering textured objects in OpenGL with alpha transparency, any objects that are drawn after transparent objects will have the scene’s pixel data overwritten. The solution to this is to sort your 3D objects, first by making sure he fully opaque objects are in front, and transparent objects by their distance from the camera (aka depth/transparency sorting).

7DFPS-00007.gif

Then came the big additions, I used most of the same code from Fursuit Run for the enemies so they had the same 2.5D effect, but changed around the movement code and added the ability for them to shoot as well.

For the game’s hook, I wanted to have a mechanic based on Ikaruga, where only opposing colours hurt you and the enemy. As such I had to give the player and each enemy two batch renderers, one for each colour, to share one bullet group, as well as a flag for their current colour. Then I made sure the game checked what the colour of the bullets, players and enemies were during each collision to make sure that only opposing colours set damage.

7DFPS-00006.gif

Then it came round to the presentation, I decided to make the level much bigger (no easy task considering the original protoype used hard coded map sizes), changed the textures and added bloom so the game’s visuals had a neon aesthetic.

In the last few hours, I struggled to find how to give the game a proper goal for single players. As I was getting tired, I decided just to have an orb that the player must find to collect. The gun in the middle was the last touch, which also helped made distinguishing the player’s colours easier.

I managed to fix a few bugs later on, although I think I’ve done most that I can with this. Although one change that I don’t think will get finished but was cool was I managed to get multiple cameras working for one scene, which makes split-screen gameplay possible! So for making a number of improvements to my engine’s 3D capabilities, I call this a win. You can play RvB here on itch.io.

7DFPS-00010.gif

For November, I took part in the Desert Bus Game Jam, which started last Friday (9th November) and I managed to finish on Thursday (14th November). This jam is done in conjunction with Desert Bus For Hope, a charity video game stream to raise money for Child’s Play. The theme for each DB jam is around the desert bus, which itself is based on a notorious unreleased game of the same name.

I decided after two 3D games to make it slightly easy on myself while being experimental, so for my Desert Bus Game, you would see two perspectives, one to dodge stuff on the road and the other to keep your bus balanced.

DesertBus-00002.gif

Unfortunately, as of writing I do not have a proper physics system in Vigilante, so I made do with the standard collision system. The rear-view had a bus that leaned in the direction by changing the origin of rotation to the bottom corners. One low-level thing I did do for this game was to update the VSprite from using SFML’s sprite object to VertexArrays. This would allow me to adjust each vertex on the fly, instead of being restricted to a single square. It also allowed me to freely change the texture coordinates so I could do the endlessly scrolling roads, as well as skewing them. I hoped I would be able to get proper perspective to work, but even vertex arrays have their limits when it comes to skewed sprites.

You can play Bus on the Desert here.

One month to go!

SFML 2.5.0 Update (Or how I learned to hate RenderTextures)

 

 

On May 6th, the C++ Simple and Fast Media Library (or SFML for short) was updated to stable version 2.5.0, adding various updates including more optimial iOS support, bug fixes, added functionality for Text and Audio and various optimizations. For such a big release, it made sense to upgrade and get my Vigilante Game Framework updated, and why not update Gemstone Keeper while I’m at it?

Well it took nearly a month, but I did manage it in the end. Gemstone Keeper 1.0.5 has been uploaded to Steam, both for Windows and Linux!

As the title suggest, a lot of the work had to do with the updates to the sf::RenderTexture object. However, I don’t absolutely hate them, they are extremely useful for rendering a scene to an area of the screen, or to apply post-processing effects to. However the problem lied in how I was using them, and how the fixes done in the latest update effectively broke my engine’s rendering system.

The initial update showed promise, as my most recent game worked fine, but moving onto the framework’s examples and Gemstone Keeper showed that a lot of things weren’t rendering at all.

Vigilante Framework currently renders 3D models using Modern OpenGL, and while it was working fine with SFML 2.4.2, it rendered nothing with SFML 2.5.0. The solution was embarrassingly simple despite the amount of effort put into fixing it, including implementing my own version of SFML’s glCheck function and re-writing SFML’s own OpenGL example to run with modern OpenGL. When rendering the 3D scene, I modified some of the OpenGL states, which wouldn’t be an issue before but now those OpenGL states carry over into other contexts. The solution was to simply make sure that the GL states were reset BEFORE rendering the scene using a sprite object.

 ///Render 3D scene and apply to a sprite.
 RenderTarget.resetGLStates(); //Reset the GL states to the default for SFML
 Sprite->Draw(RenderTarget); //Render the sprite.

Gemstone Keeper however uses legacy OpenGL, and while I could have updated the VFrame source code but that could take more time to fix. Regardless, I was able to get it working by rearranging other objects that define sf::RenderTexture, including the bloom post processing effect and the help popup terminal.

Gemstone Keeper’s other graphics were another story. The approached I had been using up to this point was to render text objects onto a single rendertexture, and then store the generated texture to be used as a sprite, particle or tilemap. While this was okay for the time, but it is rather inefficient and bad for graphical memory.

I wanted to do a single-texture approach, where all the graphics are rendered onto a single texture, and a rectangle area is specified when creating renderable objects, for a while but I kept putting it off. SFML’s update, causing any newly created render textures to dereference generated textures, it was time to take this approach on. The best part is that most of the work was already done by myself with the additional code of Jukka Jylänki’s MaxRectBinPacker algorithm, all that needed doing was to change how I defined renderables from setting the texture to whatever the name of the genrated texture is to the name of one texture sheet, and to get the correct rectangle from a map/dictionary, searching by string ID.

CaptureCaptureCapture

Now this doesn’t mean the entire game’s visuals are rendered from one texture. Including the 3D gemstones, any assets that use a repeated texture grabs a subsection of the main texture as a copy, same applies to the VBackdrop as well. Getting the icon was a more painful looking process of converting the entire texture sheet to an sf::Image, so I can load in a subsection to a new sf::Texture object, and then convert the new texture object to an sf::Image in order to set it to be the application icon.

sf::IntRect iconArea = TextureData::p()->GetTextureRect(TextureData::p()->GetPortalTextureName(true));
 sf::Image image = VGlobal::p()->Content->LoadTexture("TextureSheet").copyToImage();
 sf::Texture tex;
 tex.loadFromImage(image, iconArea);
 VGlobal::p()->App->setIcon(iconArea.width, iconArea.height, tex.copyToImage().getPixelsPtr());

Like I said, not pretty.

So enjoy Gemstone Keeper, the number of you who own it. Now back to doing more stuff in C++…

Managing Content and the Joys of Smart Pointers

Hello everyone, I figured I’d write a post about something I’ve been working on for the last week or so, partly as a bit of advice for some budding programmer wanting to write a bit more low level games programming stuff, but also to try and explain why it has been several weeks since I last posted about a small prototype I’ve been working on, and why I have been posting less stuff on Twitter than usual.

To put it basically, a lot of C++ work, mostly involving Gemstone Keeper. I decided to go back to it one more time after a lot of bugs and feedback came in. By the time I’ve posted this, Gemstone Keeper has been updated to version 1.0.3, which includes bug fixes, UI updates and two new enemy types.

j7fcaz6

 

While most of this wasn’t planned (most of this would have happened much earlier if I was notified on Steam within days of it being reported), but it had been on mind for a particular reason.

To put it simply, I have been updating my C++ game framework, the Vigilante Game Framework. This is the framework that I had built up alongside the game it was made for, Gemstone Keeper, before open-sourcing it in the hopes that it could be improved for more projects. I noticed a problem with the content management system, and as such I had spent the last two weeks researching and implementing a new way that would make it more optimal while keeping it stable. Because of this, Gemstone Keeper will soon be updated with this improvement among other bug fixes, and any future games using the VFramework will feature this too.

dytc50n


Here is the original code for loading and setting an sf::Texture in my content system, according to the repository for Gemstone Keeper this was initally written around Feburary 2016, and aside from one change in April this remained how it was:

bool VContent::LoadTexture(const sf::String& name, sf::Texture &texture)
{
   if (FindTexture(name))
   {
      texture = textureDir[name];
      return true;
   }
   else
   {
      if (texture.loadFromFile(name))
      {
         VLog("%s loaded", name.toAnsiString().c_str());
         textureDir.insert(textureDir.begin(), std::pair<sf::String, sf::Texture>(name, texture));
         return true;
      }
   }

   VLog("Error loading texture: %s", name.toAnsiString().c_str());
   return false;
}

The approach should be fairly straightforward:

  • If a texture exists, set it to the texture object and return true.
  • If it doesn’t exist, load it using the texture object. Return true if load is successful.
  • If it cannot load, return false.

However there is one problem, setting the texture object doesn’t set the reference, despite passing the object in as a reference (hence the &). Instead it creates a copy, with a new texture ID and references.

Performance wise, this doesn’t have much of an issue, however memory wise there could be a concern with creating several sprites with the intention of using the same texture, but it isn’t. The intent of a content manager is to load, unload and store a single instance of an asset, with any objects merely referencing that content. I investigated a number of approaches (and spoke with eXpl0it3r of the SFML team) to find the right one.

The approach I finally went with required the following changes:

  • The load function should return the object itself as a non-pointer reference, not a bool. This is to ensure that if the loading or finding process goes wrong, the program should let you know and fail. The reason for a non-pointer is to ensure you wouldn’t return a NULL object. Returning a reference makes sure not to return a newly created copy.
  • If it cannot be loaded, an exception should be thrown. Exception handling is an ideal alternative to responding to function returning false, because it’ll make a function closing on failure much easier.
  • The texture should be stored as a unique pointer.

The reason for a unique pointer, instead of a regular or “raw” pointer, is to ensure that the object only has one true owner, and that once it’s dereferenced (either by closing the game or unloading it) it’ll be properly destroyed and unable to be used by other objects, all with little to no difference in performance. While a unique pointer cannot have more than one reference, the raw pointer can still be obtained and used, just make sure that once the content is unloaded there aren’t any active objects still referencing it.

This is what the texture loading function looks like now (from the Github Repository):

sf::Texture& VContent::LoadTexture(const sf::String& name)
{
   auto found = textureDir.find(name);
   if (found == textureDir.end())
   {
      std::unique_ptr<sf::Texture> texture = std::unique_ptr<sf::Texture>(new sf::Texture());
      if (texture->loadFromFile(name))
      {
         VBase::VLog("%s loaded", name.toAnsiString().c_str());
         textureDir[name] = std::move(texture);
      }
      else
      {
 #ifndef __linux__
         throw std::exception(("Error loading texture: " + name.toAnsiString()).c_str());
 #else
         throw ("Error loading texture: " + name.toAnsiString());
 #endif
      }
   }

   return *textureDir[name];
}

To use the functions in this format, I had to change a lot of objects around the game. Textures, Images, Fonts and SoundBuffers all changed to use raw pointers, and the returned values from the functions are converted to functions as well.

texture = &VGlobal::p()->Content->LoadTexture(filename);
sprite.setTexture(*texture);

This ensured that the object being set is has the same reference as the object being returned, no more copying data, no more instantiating new objects to handle the copy.

I’ve also turned a lot of other objects into unique pointers, particularly the objects in VGlobal, which is intended to only have one instance of. It’s ideal since these ones are all destroyed at the end, and in a scenario where an object could be replaced with another one, the unique pointer can destroy the old one in order to replace the new one.

Other small changes I’ve made to update the framework includes all objects that load textures now having an optional area rectangle. This was mainly put in if multiple sprites use the same texture, but different atlases. Best example would be in the LoadGraphic and setSize functions of VSprite, where the default parameter will ensure the whole texture is used, else the animation system will restrict the render area of the sprite to that rectangle. While sf::Texture does have the ability to load a rectangle area of a texture to an object, I feel like this only adds a separate texture, instead of the one loaded and taken from VContent. At some point I’d like to use this more for Gemstone Keeper and other games, as I see reducing the texture count and having more render calls using the same texture would have additional benefits, no matter how small.

Hopefully more changes like these will benefit games I make with this framework, I’d also like to use more smart pointers, maybe shared pointers for my general objects, but for the time being, I’ve got a project to get back to.