Procedural Meshes: Generating Gemstones Part 1

So two years ago as a student researching for his thesis, I took part in the first procjam. Organised by Michael Cook, this is a games jam that focuses on procedural content, whether that be games, art, text, tools, anything that can make something. Last year I decided to go a bit basic, write some pre-existing noise and maze algorithms for the Haxe Programming Language, which I eventually tweaked and published on Haxelib and Github as MAN-Haxe.

Last year, I decided that for my current project, I was going to do something relevant, and this time use no pre-existing algorithms, this is where the Gemstone Generator comes in. I have images of the meshes below that show the progress from early successful generations to the final most generation test before the UI layout was cleaned up and the demo was uploaded. The generative process is now being used in Gemstone Keeper, albeit with a different rendering process considering I’m turning Unity’s Procedural Meshes into SFML meshes.

Capture Continue reading

Advertisements

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.

University Finished

Hey everyone, sorry it’s been a while, but for the last few months I have been incredibly busy with University work, plus I have had some technical difficulties which I’ll explain further later on. However, the good news is that it’s all finished!

That’s right, all of my remaining assignments, which includes one mobile game written in MonoGame, one PC game developed in Unreal Engine 4 with a full game development team of artists, designers and other programmers, my thesis on Procedural Content Generation to Create Levels in Games, and the combination of a Procedural Level Generator, Procedural Level Editor, and 2D Tilemap Shooter which makes up my dissertaion artefact, were all finished in time to make up my full University degree!

Continue reading

#PROCJAM, University and Final Year Project

Yesterday marks the end of #PROCJAM, a games jam all about procedural generation, or the idea of generating stuff from algorithms. For a whole week, your goal is to either produce a game that uses procedural generation in some way (and possibly follow the optional theme of INFINITY), or a tool that procedurally generates stuff to help out other developers. ProcJam is a games jam I’ve been pursuing because it’s a topic I’ve been gaining interest in for the last few months, with games like Spelunky and Rouge Legacy being really popular and the whole idea about creating fully usable stuff out of code, and being able to create new and different stuff every time is awesome.

Continue reading