Gemstone Keeper (for the Switch) for the Public!

Hello everyone! It’s been a while, but my game development focus has been majorly on Gemstone Keeper for the Nintendo Switch! Significant progress has been made to it, plus Ironbell and I (as well as feedback from devs of Naezith) have been continuing our work on SFML-Switch, fixing issues that we find. The submission process is currently in its early stages and with any luck there will be an announcement on its release later this year.

The biggest areas of progress to Gemstone Keeper that have been made is that the Switch release has a local multiplayer mode called “Survival” where up to four players can fight an infinite amount of enemies until the last player dies.

Another big change to Gemstone Keeper is that the graphics have been significantly upgraded to a higher resolution to accomodate with the Switch’s HD displays. While it might seem strange to do this, but the painstaking process of using much larger fonts to generate the textures in the game results in a significantly sharper display overall. To the untrained eye it might not appear noticeable, but when compared side by side or in a split screenview, the differences become crystal clear (pun intended).

Back in June, the Switch port had a public test run at the Retro Revival Festival in Walsall (where I was also selling some games from my private collection). Despite some major technical difficulties, I managed to get some good feedback and players to try out the game, so I’d say it went pretty well!

From the event I also got to speak to Chris O’Regan from the video game podcast group Cane and Rinse, and after he got to have a go at the game and got in touch after the festival, he invited me on the Sausage Factory to talk about the game, as well as my development background and games design! I had a good time talking, although I usually get nervous when speaking in a mindset of having an audience, I like talking about my work and how I feel about games that show a more technical aspect over an artistic or epic approach to them. So if you have under an hour to spare, why not try hearing us talk for a bit?

Gemstone Keeper Episode of Sausage Factory

But that was back in June, what about now or next month? Well I’m happy to confirm that Gamepopper will be returning to the Indie Zone of Insomnia Gaming Festival as part of their i65 lineup (for the first time since i60 back in April 2017). Both myself and the game will be there for all four days of the festival, but do also come down for the rest of what indies have to offer.

There will be one more event in the near future where players can try out Gemstone Keeper, however I’m going to hold back on announcing it until after the final details get sorted.

 

Advertisements

Ludum Dare 44 and Console Game Development

As some of you were made aware, I took part in my first games jam of the year. While I said in my End of 2018 In Review that I’d be taking a break from game jams, Ludum Dare felt like the ideal event to take part in as it was in late April and is still one of the biggest and favourite of the online game jams. Even then I wasn’t fully aware it was happening until the week before when theme voting was about to begin, and it happened to be on the weekend where I had no urgent plans. So as the days drew nearer, I made my preperations for a 48-hour game dev session.

Continue reading

WizardJam – Re(re4ti0n

So June is almost over, and right now I’m writing as SGDQ is going on, but in the few weeks prior I was working on a game for my game-jam of June.

The game jam for this month is Wizard Jam, the seventh jam organised for the Idle Thumbs website and podcast. This was a jam that was fairly relaxed in comparison to most I take part in, being more than two weeks, with a very open themed convention. Instead of a singular theme, your theme is to choose from one of the many episode titles of the Idle Thumbs podcasts, which did take a while for me to pick, but I decided to choose one based on a little experimental project I was working on.

After being inspired from GDC earlier this year, I started work on a simple facial animation system to be used in the feature of a game. It used SFML’s primitive rendering system with interpolation and managed to get it to speak based on a simple string input. Wizard Jam gave me the opportunity to utilise it in a game with the theme “Read Our Lips” to test how effective it is.

The concept was a game where you were given quotes that are incomplete and corrupted, and your goal is to complete them based on your interpretation. The player had a short amount of time to enter their guess before being shown the next one. I went with giving the game a basic layout of an office, with a futuristic computer screen for the input and a faulty old looking monitor for the broken quotes. Thanks to SFML’s sf::Event::TextEntered, it’s incredibly easy to handle text input. It took less than a day to get the concept done, and an additional two days to get the initial layout done.

While I did take one day out to play around with the sfeMovie library, I spent most of the time polishing the existing game concept, improving the visuals and adding sound. I added camera movement so the text would be easier to see for a short amount of time. I updated the backgrounds so I could give a bit of a parallax effect.

The monitor was updated to use a lot of shaders, the title screen used the same amount of shaders. The main distortion shader was felixturner’s bad-tv-shader, combined with a fish-eye lens and scanline effect. I originally included a noise shader (as you can see in the previous tweet) but I found that darkened the colours so instead replaced it with the bloom shader that I’ve used in Berzerkatron and Gemstone Keeper. Finally, after some feedback, I added a simple chromatic aberration effect by offsetting the colour channels. It appeared to create an old and broken monitor effect that seemed to get some good impressions from people I showed it off on Discord servers.

There is no music for this game, just sound effects and ambient noise. Most of them were sourced from soniss’ GDC audio libraries, with some additional royalty free sounds for TVs and crowds. The name was kind of inspired by l33t speak, as I wanted to summarise the concept of the game (restoration/recreation) with the distortion you deal with.

The gameplay flow of having two minutes to guess as many quotes correctly was actually the last moment idea, originally you had to guess five random quotes with fifteen seconds each, but I felt that made the game too short for anyone finding it easy. One game dev on the Birmingham Indie Dev Discord suggested also making each quote progressively harder to start, but each would slowly become easier over a period of time. That way the game starts easy but gets difficult, but the currently displayed quote will slowly fix itself if you let it wait.

I was hoping to polish up the game a bit more over the weekend, but I went out to a party that unfortunately ended with the theft of one of my bags. While nothing game dev related was stolen, an expensive costume that I wear for public events was taken and it’s been reported to the authorities, although that didn’t stop the moment from dropping my emotional and motivational drive. I did get some last finishing touches done and missed the deadline by a few seconds, however the host was able to add Re(re4ti0n to the jam submission list the following morning.

You can play Re(re4ti0n by clicking the above image or right here.

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.

Gemstone Keeper – Quest to Linux Part 3 – Gemstone Keeper

Finally, after beginning soon after the game’s Windows release on Steam, and well over a month after I initially wrote my first post about this topic, I’m finally done with porting Gemstone Keeper to Linux (for the most part) and ready to write about what I’ve learned from porting it over. Since both the Framework and Level Generator have been ported, getting the whole game to compile and run wasn’t as confusing as the last two, but that didn’t stop it being tedious.

Continue reading

Graphics Overhaul and a Lesson in Font Licensing

So just as I was about to start on the next boss in Gemstone Keeper, an issue arose that I needed to resolve over the weekend. Due to licensing issues regarding the font I had been using to produce the graphics for Gemstone Keeper for over a year, I had to switch to another font. This would not be a problem for a vast majority of games, however when you are developing a game that uses ASCII art, with designs built specifically for that font in mind, this was a time consuming issue.

Continue reading