Ludum Dare and Steam Greenlight

This last week of April is going to be a busy week, and May will be even busier, so I’d figure it’s best to write this out now. Last week I took part in Ludum Dare 35, with 48 hours on a surprisingly rare free-weekend (my weekends are usually filled by going out and hanging out with people or going to events, such is life). The theme was shapeshift, so obviously a lot of games involve changing shapes with a few that either use shapeshifting in either the levels, the monsters or even in the mechanics.

While the theme voting was going on, one of the suggested themes was “Two Colours”, and so all my ideas were pretty much blurred out by one of my favourite games of all time: Ikaruga. So I decided to combine shapeshifting ships with colour shifting bullet absorbing, this is where Spinstar comes from.

 

This was quite fun to make, particularly with the animation and the bullet patterns, you can go vote on the game here or play the game directly on itch.io here. I’ll be voting on games still, hopefully I’ll get a good score like my past entries.

On other pressing matters, I plan to take Gemstone Keeper to Steam Greenlight. I have already been working on the Steam page itself, but I’m giving myself three weeks to fine-tune the page, get the trailer finished and let as many people know about it as possible.

Steam Greenlight Anouncement

I’ve been working on the trailer, I’ve had difficulties getting game footage until recently, I might write about it once the Steam Greenlight page goes online but it all comes down to trying to find a method that outputs videos with the least washed out colours and as little blurring as possible.

I’ll also keep progress of the game where I can, I’ve been working on bosses and I want to get started on items.

 

Advertisements

Weapons of Gemstone Keeper

So for this week (11th – 17th January) I decided to focus on weapons, a pretty important element of twin-stick shooters. I didn’t want to stick with using one weapon for testing, so I decided to see if I could make a few more for the game. This should explain how I approached the problem and what the weapons system currently looks like for Gemstone Keeper.

Continue reading

Understanding ASCII Art

It’s pretty easy to see that I’ve taken the step of using ASCII art in my next game, Gemstone Keeper, and it’s pretty difficult to not notice it if you see the screenshots I’ve been posting for #IndieDevHour or Screenshot Saturday.

This writeup will explain my understanding as mainly an outsider and relative newcomer to the ASCII art and Roguelike Development scenes, and hopefully explain my reasons why I chose to move to ASCII art, and how I am approaching it to make my own style to the art form.

Continue reading

Allegro to SFML (aka How I learned to love VertexArrays)

If you have been following me on Twitter, you may have noticed that after game jams, I’ve returned to Gemstone Keeper. Since I started work on my thesis project, GenLevelTools, I have been working in Allegro 5, using my previous experience and the already functional graphics rendering, for both the GenLevelTools and Gem Finder, the simple prototype that is now Gemstone Keeper.

However I decided that I would change the underlying framework from Allegro 5 to SFML 2, the thought of changing systems has been in consideration since IRDC 2015, which came about for numerous reasons:

  • The Gem Finder code needed updating, as it was written during a time where I was under pressure to meet a deadline and have something to show, for what was essentially the most important part of my University degree. Now that I have graduated, and have gotten a full time job, I have a bit of flexibility and less pressure for me to make some improvements. If I was going to update the current code, I needed a framework that could satisfy the needs of a new system. I could rewrite the code with Allegro 5 with my experience and confidence behind me, but…
  • Allegro 5 has limitations, which makes some of my concepts for Gemstone Keeper less feasible. The last stable build of Allegro was back in January, yet it lacks certain features that you’d find in other C++, C# and even Haxe frameworks. Specifically shader support for effects, and gamepad support beyond DirectInput. While shaders are a feature of Allegro 5’s unstable builds, there is the issue of stability and compatibility. My attempts to get the unstable builds to work have been less than futile, and even when I finally got a functional build of the unstable release, I was met with a lack of certain libraries to run shaders (namely libpng1_6.dll). It wasn’t worth it, and if it was a struggle for me to get it to work, then it would be worse for me to help get the game running for other people. Also Xbox 360 controllers are recognised as DirectInput devices, which does have some limitations, specifically with the analogue trigger buttons.

This is where SFML comes in. Like Allegro, SFML is a set of C++ libraries that can be used to develop games for PC, Mac and Linux with experimental Android and iOS ports. However, SFML does have shader support with little to no issues installing either the latest source code or direct download from their stable release. While neither have XInput Gamepad support directly, the SFML community have had no problems showing how easy it is to make an XInput wrapper for SFML.

The real seller for me is that SFML’s text rendering has a much superior output, but also support for wide literal characters. This is a big deal for anyone who is developing games that rely on text, such as games with ASCII graphics.

Firstly, Allegro’s text rendering seems to struggle with rendering text that isn’t a factor of two, or below a font size of eight. This is pretty reasonable for using TrueType Fonts that may not have data for all sizes, but software that uses a lot of text have algorithms that help keeps the quality of text consistent regardless of size. In my tests, SFML handles this quite well, while Allegro has issues such as lack of transparency and defects with certain characters at small sizes.

Rendered text comparison.

Left: Allegro build Right: SFML build

Secondly, being able to use wide literals means that I am no longer restricted to characters in the ASCII format, which have less than 255 usable characters, now I can use over 1000 possible characters in the Unicode format, which as of C++ 11 is fully compatible (SFML says that they don’t support unicode formats at the moment, but as long as the font supports them, SFML should render them!). This means more possible creative designs, so more enemies, environments and other features are possible!

Use of unicode characters in game.

Copyright symbols as enemies, because I can now!

Most importantly, SFML is being constantly updated, like I said earlier, the last stable release of Allegro 5 was back in January. In comparison, since starting the framework transition back in August, SFML has already had two updates for SFML 2. It also benefits that SFML is an active community, and appears to have more of a social media presence. These factors help in both finding framework issues, and possible advice for certain functionality.

The new framework I’ve been working on has a slightly different approach, more similar of an approach to Flixel, like what I did earlier with my MonoGame framework Ricoh2D. As such, I’m using an inheritance of a singular base class, as well as a heavy use of object pooling. This way I plan on having updating, rendering and collisions accessible for each object, to make it easier to add and remove objects at runtime. Like Ricoh2D, I’ve aimed to have collision checking handled on a single function call, with the option to pass in a function for collision response.

Because I’m using SFML, I’m also hoping to produce a more optimal and performance with the aide of VertexArrays. All renderable objects in SFML use Vertices to determine the coordinates, texture coordinates and colour of each point of a graphic. During development, I’ve found it is highly efficient to use VertexArrays whenever you can for more custom rendered objects, as there is some overhead whenever you perform a draw call, although the effect is larger in debug mode. For example, when I initially built a tilemap renderer that drew each tile as a separate sprite, I was getting around 400 FPS. When I changed it use a single VertexArray object, where each four vertices is a single tile, the framerate shot up to 1200 FPS. I have since used VertexArrays to replace SFML’s built-in text renderer with my own, that allows me to have text alignment combined with multi-line rendering, when the built-in renderer only had multi-lined text while aligned left. I am considering creating a sprite-based particle system using vertex arrays, as my current system uses multiple sprite objects.

As of writing, the transition of features from the Allegro version to SFML version of Gemstoke Keeper is around 75%, most of the basic rendering has been implemented, the level generation has been transferred over. I need to implement the current enemy behaviour as well as level progression and other enemy screens to have a complete transfer. Once that is finished, I should be able to work on my plans for new features, and should start planning on releases.