RainbowJam – Fursuit Run

For the month of September, I needed to take part in a game jam, but initially, I wasn’t sure which one. I looked through all the jams listed on indiegamejams.com and while you are spoilt for choice, not many were catching my eye. That was until one of my friends from the Birmingham Indie Developers, Kirsty Fraser, mentioned a game jam she was organising.

RainbowJam is a two-week games jam about exploring LGBT+ themes, running for its third year it’s partnered with the non-profit organization Queerly Represents Me and encourages representation and to “create games exploring and celebrating identity, gender, sexuality, sex, life, and love!” After working on Re(re4ti0n, I’ve felt a little urge to create some more experimental games that go against what I generally like, which would be arcade retro shooters/platformers with a neon glow or a retro aesthetic. I also knew I had some 3D functionality in Vigilante that deserve to be worked on enough for a complete game, so I spent a few weeks earlier in September to create a basic 3D game system.

Unfortunately, my 3D stuff was limited to what you can render. I consider Vigilante a 2D game framework with 3D elements, so I didn’t bother implementing 3D collision detection, but I had an idea: what if I make the game function in 2D space, but display in 3D space.

What I did was set up a small 2D enviroment with a tilemap and a basic sprite, and I set up the 3D models to display the scene based on the tilemap while the camera’s position and rotation is based on the sprite’s position and angle.

 

As you can see, I got the tilemape to display really well, the floor being a multi-segmented plane that could display mutliple different tiles in one model, and the walls being cubes that are scaled depending on where their neighbours are. Initially I was creating each cube as a separate model, which I felt was dangerously innefficient so I created a batch rendering group, creating one model but using multiple V3DObject instances to specifiy where that model should be rendered. I did need other things in the game though, stuff that the player can interact with, so I created a special model that could render a 2D sprite (including 2D animated sprites!) in a 3D enviroment, always facing the camera.

The last major thing I wanted was to add an additional level, as wondering a single room is good but extremely limited. As such I made a second tilemap, a model to represent a ramp of sorts and added variables and additional groups to tell what floor the player is on, and as such what should be displayed/collided with. The bigger challenge was implementing how the player will climb up stairs, as it also had to factor falling. Combining gravity with the player moving upwards if the sprite is overlapping the area where the said slope is situated took a lot of trial and error before I finally got a dituation where the player could fully explore the floor above and walk back down to the ground floor!

After making the slope look a bit more like steps, the demo was pretty much ready for RainbowJam.

To make a game for Rainbow Jam, I wanted to make a game that is about sharing love and making people happy. I went with a game about being a fursuiter because as a furry, I know the community is very supportive of LGBTQ+ people and as someone who’s performed in fursuits at conventions and meets, I feel the most important aspect is to make anyone you see feel happy, entertained and loved, even if it’s by portraying a character.

Making the attendees you interact with was probably the biggest challenge, I made a dough body sprite with frames for actions at each angle, and made the object switch frames based on what angle it’s facing from the player. As for the AI I considered setting up a finate-state machine, but fearing it would be too much work for a jam I went for a simple state model. I got my code for line of sight and path finding from previous projects in order to get the attendees  to walk around the floors they are on, wave at the player when they see them and either hug or prepare a camera for a photo, responding to what the player does at the same time.

To simulate the limited vision of fursuits was to overlay the screen with a mask. I added a little bobbing while walking for fun, as seen in the tweet below, however a fellow gamedev suggested getting the camera to bob in time as well, which ended up working pretty effectively!

All the graphics and audio was done on the last day, I used the dough sprite as a base while I apply the colour and details over it. I unfortunately realised the limitation I set myself using a 20×20 tile size, but I think there is enough space to see who is who. As for the enviroments I used some references for hotels, such as the carpet and ceilings. There is a chandelier on the ground floor, which I designed myself to be multiple 2D images rotated because I found most 3D models online to be needlessly complex.

At around 11pm on Sunday, I uploaded Fursuit Run to Itch.io making this the game for September. There is still a voting period which begins when the jam officially ends on the 6th October. So far the reception has been fairly positive, mostly from furries, some non-furries don’t appear to like the idea without actually playing the game as of writing. I’m pretty happy with how the game turned out, as well as the 3D system. There is definitely room for improvement, as there isn’t much optimization that could be done such as view frustum culling. I’m hoping to get it improve for my next games jam, 7DFPS.

Ludum Dare 42 – Closing in on Pascal

The game jam for August was Ludum Dare 42, so with it coming to a close, I thought it’d be good to talk about how the submission [Closing in on Pascal](https://ldjam.com/events/ludum-dare/42/closing-in-on-pascal) came about and what I learned from it.

Ludum Dare 42 was particularly exciting for me, as it was the first LD in a long time that I had a completely free weekend. As such, I decided to plan the first day entirely for gameplay, with graphics and audio on the second day. That way I get a solid game and then plenty of time to work on making it look and sound nice, you’ll find out why that plan isn’t flawless as it sounds.

When it came to the theme, I was already very pessimistic that it would be a theme I’d be happy with, it’s been a common trend for people to vote on the theme that no one wants. I even voted against the theme “Running Out of Space” but when it turns out to be the chosen one, I thought it was pretty good.

The concept of running out of space I had was inspired by the cartoon trap of the walls closing in on someone in a temple. I figured a game where the player has to reach an exit before the room crushes them to death.

Fortunately, I have a bit of experience with platformers in my game engine from a previous jam, so the tilemap, jump physics and mechanics such as wall jumping I have previously implemented.

LD42-00000.gif

The jump animations itself was done because I remembered the indie platformer INK having good squash & stretch. To achieve it I modify the scale so that it squashes inwards when going up and stretches outward. If I had more abilities to adjust the individual vertices I could do more fun aspects of moving like skewing.

LD42-00001.gif

Since my idea was inspired by a temple film/TV trope, I already had the visual theme in my mind. I also thought it would be good if I had a little cartoon character who’d look like Indiana Jones. It was fun working with pixel art and animation once again, but if I was to do this again I would have done a much simpler approach. The player character is way too small for the game screen, meaning that its animations are pretty much useless. I also had a bit of issue with making the colours stand out so it doesn’t feel all yellow and brown.

LD42-00002.gif

In the end, it took around 3 – 4 hours to work on the background environments and 5 hours to work on the player sprite and all the obstacles. If I went with a much simpler design or scrapped the temple theming and used the simple colours and shapes it would have been much clearer and easier to look at.

LD42-00009.gif

The sound and music was achieved with LMMS and BFXR. I like making NES-like chiptune in there but I do notice it’s restrictive in areas like tones and tempo, so I couldn’t get the sounds I want. It also didn’t help that thanks to the graphics, I had much less time to work on sound and music so it ended up rushed.

The post-jam has most of what I would have added or done better if I had time. Particle effects, using directional keys as well as the WASD buttons, and a better title logo. I would have also worked on more levels but seeing how many levels players are willing to go through, then maybe the existing levels should have been improved slightly.

I’m a little worried about what the rankings will be for this one, I’m definitely glad I could take part but I feel as though I wasted too much time on the graphics when a simpler approach would have been effective. You can go check out [Closing in on Pascal](https://ldjam.com/events/ludum-dare/42/closing-in-on-pascal).

Games on Command: Making of PEWBALL

For the month of July, I decided to take part in Floppy Jam as my games jam for that month. Floppy Jam was a small jam with a novel idea, make a game that could fit on a single floppy disk with the total memory capacity of 1.44 MB. I decided to take part but there is an issue, most of my typical development environments could not make a game that small, even if I made a completely procedural game. So I decided I should make a new engine, where it has the most basic elements (graphics, sound and input) in its smallest possible code. That’s when I decided to make a games engine using the command prompt.

 

The command prompt looks simple, there isn’t much you can output to the console and it’s typically slow, at least not fast enough for real-time smooth rendering. However, that’s if you use the standard iostream or stdio functions. The Windows library actually treats the console window like any standard window, with a handle for both input and output, as well as a screen buffer.

HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
CONSOLE_SCREEN_BUFFER_INFO csbi;

GetConsoleScreenBufferInfo(hConsole, &csbi);

SMALL_RECT rectWindow = { 0, 0, 1, 1 };
SetConsoleWindowInfo(hConsole, TRUE, &rectWindow);

COORD coord = { (short)SCREEN_WIDTH, (short)SCREEN_HEIGHT };
SetConsoleScreenBufferSize(hConsole, coord);

SetConsoleActiveScreenBuffer(hConsole);

It is possible to resize the window by shrinking the screen buffer to the smallest possible size, before scaling it up to the size you want. Frustratingly you cannot set the console to any size you want, as there appears to be a restriction that the size cannot be larger than 800×600 pixels. For the game, I ended up using 108×60 characters to make the game the largest widescreen resolution. You can also set the font and the font size, the window title and window position as well, which is enough customization you need even if it’s not possible to get fullscreen or “high resolution”.

Input can be read from the input handler, including focus, mouse and keyboard events. You can also use GetKeyAsyncKeyState() to get real-time input handling. Mouse positions can only be accessed from the input handler.

HANDLE hConsoleIn = GetStdHandle(STD_INPUT_HANDLE);

INPUT_RECORD inBuf[32];
DWORD events = 0;
GetNumberOfConsoleInputEvents(hConsoleIn, &events);
if (events > 0)
	ReadConsoleInput(hConsoleIn, inBuf, events, &events);

for (DWORD i = 0; i < events; i++)
{
	switch (inBuf[i].EventType)
	{
	case FOCUS_EVENT:
	{
		windowFocus = inBuf[i].Event.FocusEvent.bSetFocus;
	}
	break;

As mentioned earlier, using standard text input/output isn’t fast enough for real-time rendering, it’s also rather limiting. What we need is a way to render a full array of characters to the console screen, so how do we do that? And how do we display colour? Well, the best way deals with both birds with one stone, WriteConsoleOutput(). This function writes a full set of characters to the console, but you do not input strings, but a special Character format that allows you to set either ANSI or Unicode Characters, as well as what foreground and background colours for that element in the array. Command Prompts (as well as most pre-installed terminals) give you a maximum of 16 foreground and background colours each, although with the right character sets and other tricks you could create more colours. Once you have set up an array, you just call WriteConsoleOutput, using your console output handler, the array, the size of the array in width and height as well as the area you wish to draw to. A lot of this info I first discovered from the One Lone Coder through his ConsoleGameEngine tutorial series, as well as a header-only roguelike engine called rlutil.

///Buffer Screen
CHAR_INFO *bufScreen;

void drawChar(int x, int y, short c, int color, int bgColor = 0)
{
	if (x < 0 || y < 0 || x >= SCREEN_WIDTH || y >= SCREEN_HEIGHT)
		return;

	bufScreen[y * SCREEN_WIDTH + x].Char.UnicodeChar = (short)c;
	bufScreen[y * SCREEN_WIDTH + x].Attributes = color | (short)(bgColor * 16);
}

///Drawing the full buffer screen array to the console.
HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
WriteConsoleOutput(hConsole, bufScreen, { (short)SCREEN_WIDTH, (short)SCREEN_HEIGHT }, { 0,0 }, &rectWindow);

///Clearing the buffer is as simple as setting all the elements to 0.
void clearScreen()
{
	memset(bufScreen, 0, sizeof(CHAR_INFO) * SCREEN_WIDTH * SCREEN_HEIGHT);
}

For timekeeping, an easy way to get efficient time tracking would be to use the standard library chrono. However, to avoid overhead and allow support with older systems, I needed a more specialised solution. Fortunately, I remembered a Windows-specific method of timekeeping from a video by a game developer going by the name TheCherno. While in more recent videos he recommends newcomers to use chrono, in a C++ game engine tutorial he used QueryPerformance functions. Essentially, you call QueryPerformanceCounter(), which will return you a timestamp accurate to the nearest microsecond of the PC’s performance counter. You can get the timestamp from the start of your loop, and another at the end to work out the total time to process a loop. While it is platform specific, because it’s part of the Windows API there is little overhead, and it’s extremely accurate.

bool StartCounter()
{
	LARGE_INTEGER li;
	if (!QueryPerformanceFrequency(&li))
		return false;

	PCFreq = double(li.QuadPart);

	QueryPerformanceCounter(&li);
	CounterStart = li.QuadPart;
	return true;
}

float GetCounterNanoseconds()
{
	LARGE_INTEGER li;
	QueryPerformanceCounter(&li);
	return (float)((li.QuadPart - CounterStart) / PCFreq);
}

float GetCounterMilliseconds()
{
	return GetCounterNanoseconds() * 1000.f;
}

Finally, for sound, I only wanted the simplest implementation I could find. All I needed was the ability to load Wav and Ogg files, and play them in parallel. Fortunately, that is possible with a single library and a header file. Randy Gaul developed a large collection of self-contained systems, each could be used with a single header. This included cute_sound, which does exactly what I wanted. It does have some minor faults such as crashing if you tried to delay a sound, and needs a significant updated to be friendly with modern compilers because of how it uses goto statements, and unfortunately because of how the Vorbis library works you cannot make it header only, but it’s not complex.

void loadAudio(const char* name, unsigned int id)
{
	freeAudio(id);

	const char *dot = strrchr(name, '.');
	if (!dot || dot == name) return;

	if (!strcmp(dot, ".ogg"))
		load_sound[id] = cs_load_ogg(name);
	else if (!strcmp(dot, ".wav"))
		load_sound[id] = cs_load_wav(name);
}

void playAudio(int id, bool loop, float volume, float pitch, float pan, float delay)
{
	cs_play_sound_def_t def = cs_make_def(&load_sound[id]);
	def.looped = loop ? 1 : 0;
	def.volume_left = volume;
	def.volume_right = volume;
	def.pitch = pitch;
	def.pan = pan;
	def.delay = delay;
	cs_play_sound(ctx, def);
}

The engine’s structure is that the user simply defines preprocessors for constant values, and includes a single header to get the engine’s full functionalities. All they need to do is to set up a function for handling updates and rendering (if they want to use real-time functioning) or event handling, and then call a function called run to start the engine. Keeping it like this basically means it’s possible to create tiny demos and games with whatever external tools they want.

When the jam actually started (yes I built a two-header library about a week before the jam began), I wrote basic state management system for the two scenes I wanted (title and game), as well as renderable objects. Each interactable object used a game object struct that had basic physics for movement and collision checks. The pinball environment was achieved by assigning each wall an ID, and that ID also corresponded with the angle of the slope as well as how it appeared. While most other game objects were defined as sprites, an overridden game object that has an array to represent a single static image, the flippers was a special sprite that manipulated that array based on how long a button was held down for. It also had special collision responses based on what stage the flippers were in, which proved a challenge when sprites could easily go through them.

What made working on this engine quite exciting was it really encouraged you to work with proper limitations. Unlike pico-8, where the limitations are hard-coded into the engine and its fantasy console, the command prompt had a small resolution and a limited colour palette purely because it was not intended for real-time rendering and gameplay, and the 1.44MB meant I had to think outside the box to find ways not to use too much memory, although, in the end, PEWBALL was under 400KB (possibly smaller still if I could get a compress heavy linker like crinkler to work).

One way to optimise was to replace having a particle emitter with particle objects with the rand() function and lots of basic maths to work out where particles would be over time. This technique was used for the starfield at the beginning as well as the explosions enemies and the player has in the game. Guns used a simple fixed sized array as an object pooling system, a similar one was also used for the enemies, which had their own struct that could be overridden for unique behaviour. Ogg files were compressed to their lowest quality, which gives them a small file size as well as gives a slightly distorted retro feel, helped by the 8-bit inspired music and sound effects that I used.

While I could have carried on development up to the deadline on August 10th, I needed to get a game finished for July, so I decided to stop on July 31st and submit it, announcing it’s release on August 1st. Little did I know, there was also a voting session that went on for a while. Out of the 25 submissions managed to achieve 7th, and the overall winners were Floppy Bug (In Quality and Design) and Crates in a Crate (in Gameplay). I’m pretty happy with where I placed considering the challenge I had in creating an entire engine, although I’m definitely impressed with Floppy Bug because the team behind it decided to one-up me and create a full 3D OpenGL engine in two weeks that took up 440KB.

Regardless, this one was a rather fun challenge. It kind of makes me want to look into development for other primitive systems, maybe I could try developing for an old console next, who knows? As for Linux, that might not be as possible as I hoped it would be. The problem with Linux Terminals is that they don’t have the same level of control as the Windows Command Prompt. It is possible to do things like resizing the terminal window, draw characters at certain positions and set the colours of characters using ANSI escape sequence strings, however, it isn’t as stable as I once thought, and there isn’t much documentation on getting it to work.

If you want to check out the engine itself, it’s called KitConsole and can be found on Github, and you can check out PEWBALL on Itch.io.

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++…

New Years Resolutions

Good evening everyone! It’s no doubt that 2017 has been a hell of a year following what happened in 2016, but we fought through and we are still here fighting! This year has also been huge in terms of game development for me. I managed to finish SEVEN games this year, six from game jams such as #RemakeJam, PROCJam, Jamchester and Three Ludum Dares!

https://img.itch.zone/aW1hZ2UvMTYzMjc3Lzc1MjE2Ni5naWY=/315x250%23c/L0i8g2.gif  https://img.itch.zone/aW1hZ2UvMjAxMDM1LzkzOTE3OC5naWY=/315x250%23c/q5QpUK.gif

The seventh game was the nearly two year project Gemstone Keeper, which made an initial release on March 31st earlier this year and has since had numerous updates, although grouped together as four updates. The most recent of which was 1.0.4 that was announced on 21st of December. The game is currently on part of the Steam Winter Sale, and is currently 50% off!

Gemstone Keeper also had a second smaller release as it was ported to Linux, the build being available on Steam in June. I documented the progress to port the game in three blog posts (part 1, part 2 and part 3), and got a small amount of coverage from dedicated linux gaming websites as a result.

There was also an accomplishment in travel as well, 2017 was the year I went to both GDC in San Francisco and Develop in Brighton for the first time! Both events were great opportunities to meet up and socialise with fellow game developers and listen to talks from great minds such as Ken Perlin, John and Brenda Romero, Jordan Mechnar and Tim Sweeny.

As for 2018, I want to set some goals. As with many New Years Resolutions, chances are they will be forgotten and unaccomplished, but considering I managed to lose weight this year, I might pull through with a bit of committment.

First one is that I want to take part in at least one game jam a month, meaning I’d be finishing 12 games next year. I like the challenge and creativity from game jams, but this year I feel like six isn’t enough. At least spacing out the game jams to one a month will give me time to find a weekend or so to get my head down and finish something.

Second one is to get a game on console. It’s not like I haven’t bothered trying before (I’ve reached out to Nintendo about developing Gemstone Keeper for the Switch to no avail), but it would be nice to expand my work beyond desktop PCs and web development. Porting my own game to Linux should show how when I put my mind to it, building a game to another platform by hand is possible, and it would be great to show I can do that on one of the three main systems.

Thanks for reading and have a happy new year everyone!

The More You Have, the Worse It Gets

Ludum Dare 40 took place last weekend, the theme was the title above. Honestly it wasn’t the theme I was hoping for, but in the end, I took an idea I had and adjusted it slightly to work.

The idea I had was that a single level would slowly get corrupted and change, you can shoot away the corruption, but touching the corruption would kill you. This already could fit the theme quite well, the more corruption in the world means the worse it is for you. I wanted players to move around a lot, so I had the additional goal of collecting glitch boxes, which would create more corruption over time.

I used HaxeFlixel to develop the game, as it was bread-and-butter for me in game jams such as Ludum Dare, especially when there is not much time to work on an idea (I had spent the entire Saturday out with friends for winter festivities, all I did was write notes on what the idea would be, so in all I only had around 11 hours to work on a game).

b056


To get the corruption to update and move around, I used the tilemap system and updated the grid with Conway’s Game of Life algorithm, that way it gave the impression of mutating outwards or dying out depending on the numbers. Fortunately, with recent updates to HaxeFlixel, you could do collision response based on specific tiles, so it was easily possible to remove tiles and change the map when bullets collided with it. The extra artefacts also use Conway’s Game of Life. although the grid is 4 times larger than the main corruption grid.

The artwork was done in Photoshop, although it was a very simple and rushed job. The “corrupt” graphics was a multicoloured character set that I had to create and tweak by hand to fit into a 10×10 pixel grid.

The music was a combination of cgMusic and LMMS, quite a good combo to have because it meant I let one program generate a music set, then import it into LMMS as a midi file for me to set instruments (using soundfonts), effects and tweak the melodies how I like.

I managed to upload the game with around 30 minutes left before the compo deadline!

b05c

On Tuesday I fixed that timer, which appeared broken when you reached a minute because I messed up how the string was being built. It took a few uploads for those changes to appear, something that kind of frustrates me about HTML5 and how web browsers will not always clear out the cache if the content has been changed.

GIF

Feel free to play the game on itch.io as well as rate or comment on the Ludum Dare page.


This wasn’t the only games jam I did this winter, I also took part in PROCJAM, where I built a planet generator. It’s not my best work to be honest, although I was able to work and improve my 3D OpenGL rendering in the Vigilante Framework.

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

Gemstone Keeper – Quest to Linux Part 2 – GenLevelTools

Last time on Quest to Linux, I went through porting the Vigilante Game Framework to Linux, but the quest isn’t over yet. The next big task is porting Gemstone Keeper’s level generator and editor, the GenLevelTools, since I need to be able to get the caverns from somewhere.

https://upload.wikimedia.org/wikipedia/commons/a/af/Tux.png

GenLevelTools, aka the Procedural Level Editor, is a tool/library set that enables proceudrally generated grid-based levels to be modified and previewed in a level and used in games, while independent from any specific game engine or renderer. It was originally developed for my University Thesis on Procedural Level Generation and I later did a talk about it at the International Roguelike Developer Conference in Nottingham. The library is written in C++, so language specific quirks like forward slashes and for loops apply, so the main challenge this time around is the level editor, which uses Allegro 5 as well as the GUI library GWEN.

Allegro 5 is a C framework, although you can still use it for C++. Fortunately like SFML, it’s easy to set up for Linux since it’s part of one of Ubuntu’s repositiories. GWEN is a GUI library that was developed by Garry Newman (of Garry’s Mod). It was the easiest to set up for Windows but I had a few problems with the Linux version, as the gmake scripts rely on finding certain libraries and ending the entire scripts if those libraries cannot be found. This is different from running the scripts for Windows, which create Visual Studio projects that you can apply the libraries yourself. After tweaking the scripts and the source files a bit, I managed to get the GWEN and GWEN Allegro Renderer to build.

Aside from the main changes that I mentioned in the last post (using correct slashes, for loops) there weren’t that many changes I needed to make. I did have to add a lot more include statements, since despite being standard library stuff, GCC doesn’t immediately know what functions like memset, modf, floorf or ceilf among others off the bat, unlike Microsoft Visual Studio. After all these changes the library was able to compile smoothly. To make absolutely sure that it works within Linux, I wanted to build and run the editor, hence why I wanted to set up Allegro and GWEN. I managed to compile it with little effort, but something went wrong…

The editor crashed almost immediately, and the only reason I was able to show the following above was because I tried running the editor without the GWEN GUI rendering in the scene. It didn’t help that Code::Blocks debugger wasn’t working initially, and the closest I got as an error was below.

Fortunately I was able to configure Code::Blocks debugger to work, and was able to find the route cause of the crash being from the GWEN Allegro Renderer being unable to load the font, which is odd because the font I used (Lucida Sans) was able to load fine in my editor code, but fortunately GWEN provides an open source font (Open Sans) that runs just fine. So now with the GUI render up and running, I can test the editor!

I’ve been able to compile the library as both a binary and static build, as well as the editor. I could also compile the unit testing and C# wrapper for it too, but since I mainly wanted to get this done for Gemstone Keeper, I’ll leave it like this for now. Time for the main course!

Gemstone Keeper – Quest to Linux Part 1 – Vigilante Framework

So with Gemstone Keeper on Steam for Windows only, I thought I’d try my hand at getting a game to build to Linux the proper way. This series of posts will hopefully document each part of porting Gemstone Keeper to run on Linux.

https://upload.wikimedia.org/wikipedia/commons/a/af/Tux.png

The last time I made a game with Linux support was Secret of Escape, which used the Node-webkit to run HTML5 games to desktop applications. Node-Webkit essentially was a separate, precompiled application that functioned like a limited web-browser using the Chromium engine, all Construct2 did was build a HTML5 game and structured it in a file structure that made the application run the game. This way, porting the game to Windows, Mac and Linux took very little effort. This essentially means that developing for Linux was a completely new thing for me before releasing Gemstone Keeper.

The first stage was porting the Vigilante Game Framework. This is the underlaying C++ framework that uses SFML to develop games with state management, collision, visual effects and audio effects among others. It was partially inspired by HaxeFlixel, although with some of my own approaches that rely on C++ and SFML, as well as my own features (such as circle collision, multipass post process effects and a custom text renderer). Getting this to work on Linux would help me with setting up SFML and having a good idea of how Linux development worked.

Surprisingly, getting the framework to build on Linux ended up being the easiest part, because someone else already did it! I posted the framework to GitHub, and passed around the GitHub page to Twitter and Reddit, and SirFrankalot on the /r/gamedev subreddit was able to fork it and get it to work in Linux, and provided both written notes and a pull request to carry his changes over! The details can be found here, but these are the main points I wanted to get across:

  • Using Correct Slashes: When using Windows Explorer and Visual Studio, folders or directories will usually be represented with a backwards slash (\). If you are only developing on Windows, this wouldn’t be a problem. However Linux and Mac both always use a forward slash (/), so for portability you should use that. Using forward slashes also has the advantage of not having to deal with escape sequences, since programming languages use a backwards slash (such as \n, \t and \\).
  • For-Loops: These kinds of loops are good for looping a specific number of times using a defined iterator. If that iterator is a list of object or variables, you use a foreach loop, assuming your programming language of choice has that. When using Visual Studio, I found there is a foreach loop in the form of for each (type x in y) where x is a reference to an object in the list, and y is a container like an array or vector. Turns out this way is purely a Visual Studio extension, and the portable foreach loop is for (type x : y).
  • XInput: Microsoft XInput is the API used for Xbox 360 and Xbox One controller, which means that it’s works for Windows only, at least that’s what you would assume. Linux has both libudev and linux/joystick.h, which allows some Linux OSes to access XInput functionality. This would mean a complete rewrite, so SirFrankalot simply made all XInputDevice functions return false. I later found someone wrote a Gamepad API was maintained long enough to allow Xinput Controllers to work on Windows and Linux using the same functions. I’ve since added this on as an optional feature that can be set using a preprocessor.

https://upload.wikimedia.org/wikipedia/commons/3/3f/Logo_Linux_Mint.png

Next was using an IDE, I decided to use Code::Blocks because I have used it before, although it’s still much of a change of Visual Studio. Not to mention I was using a virtual machine, a VirtualBox with Linux Mint 18.1, and for whatever reason my configuration causes it to crash with no warnings. I also had to set up a load of dependancies, although using the terminal to get them is much easier than browsing for libraries online.

 

In the end I managed to build the SFML tutorial code and a few moments later, VFrame could compile! Aside from some small issues with 3D graphics, it was running almost just like it did on Windows!

Next time, it’ll be my ramblings as I port over the library that makes Gemstone Keeper’s caverns large and random, the GenLevelTools!

Ludum Dare 38 – littleBLASTplanet

Last weekend was Ludum Dare 38, not only is it the 38th main game, as well as the 8th or 10th one I’ve taken part in (whether or not you take into account failed attempts), but it also marks the 15 Year Anniversary of the competition/jam as a whole! Not only is it celebrated with another jam, but with a brand new website. For now you can still access the old website, but game submissions are currently being handled entirely on the new site.

ldjamalpha

The theme this time around was Small World, so I (like a lot of devs) made a game either around a small game world or a tiny planet. I went with the latter and drew up a run ‘n gun shooter on a little planet.

 

Sadly I had plans with my friends on Saturday so I didn’t start work on the game until around 8PM GMT, so development felt more rushed than a full games jam but I managed to make what I set out to design: littlePLANETblast

Similar to my past Ludum Dare projects, I used HaxeFlixel. It’s straightforward to use, multiplatform (Flash, HTML, Windows and Android maybe…) and it’s still being maintained so there have been several improvements. I’ve provided the game’s source code on Github so feel free to have a look to see how the game works.

The first problem I had to solve to make this game work is how to make a sprite orbit a planet. HaxeFlixel has a FlxVector object for vector math, so using that with a sprite’s acceleration meant having the sprite fall towards the centre of a circular planet was pretty easy, but how do you get the sprite to stop on the planet’s surface?

HaxeFlixel has no circular collision, only rectangtle collision. When I wrote my own C++ framework for Gemstone Keeper, which took inspirations from HaxeFlixel, I included Circular collision by giving each object a Radius property and writing my own circle overlap and separation functions. This would have been too much work for the time I had, so I wrote a hack method for a derived sprite class that always checked and updated the distance between a sprite’s centre and the planet’s centre, and if the distance was less than both the planet’s radius and sprite’s radius combined, then the game pushes the sprite up to the edge of the planet. This circle collision method is only applied between a sprite and the planet, and since rectangles don’t rotate then all sprites had to be perfect squares.

Bullets were one of the only sprites that weren’t built to orbit the planet, instead simply moving in an angle that combines the firing direction with the player’s current angle. I’ve had some feedback that said that the bullets should also be affected by gravity. I decided against it because it would make enemies on the planet easier to hit, while enemies in the sky would be harder to aim, not to mention the game loses a strategy element because of where bullets travel.

 

I went with three base enemy types: Rockets, Spikes and Robots.

Robots functions no differently from the player, except that it moves in a fix direction and smaller ones bounce by constantly jumping. Spikes has the same orbiting system, but it’s planet radius is much smaller to allow it to go into the planet. I use FlxTween and the FlxTimer to allow the spikes to move in sequence. Rockets simply spawn outside the screen at an angle and move towards the centre of the planet. If a rocket touches the planet then it would be destroyed, resulting in an instant game over.

I also added an escape object, which changes the planets side and makes the level a little bit more harder. This was for variety, so you wouldn’t have to stay on the same planet. If I had a bit more time I would have included more animations on the planet itself.

Speaking of the planet, that was one of the first objects I applied polished graphics to. To give it a more detailed pattern, I used the built in Cellular Automata function, and applied the pixels to the circle. Since it uses a random seed, the pattern is different on each playthrough.

The planet’s destruction is a particle effect that uses the planet sprite’s texture, a technique I used a lot in Gemstone Keeper. However one gripe was that I had to make a derived FlxEmitter class that could allow me to set how many frames I wanted based on the particle’s frame size.

Along with proper sprites, smoke was added to the spikes so that the game can provide a one second warning before spikes hit. I also added a distance check to avoid some unfair spike deaths. Finally I added a second camera mode incase the first one wasn’t interesting enough. The follow camera simply rotates with the player so they can stay in one spot while all the other objects rotated around. It did mean having to create a new Camera for UI elements, since objects can only be parallax scrolled by position.

The last elements I added were the title screen and audio. Sound effects were produced with BFXR and music with Abundent-Music’s Procedural Music Generator. Audio is one of my weakest skills so these procedural tools made that quick and simple, although I probably wouldn’t enter myself into the audio category for them.

I figured I add a smaller version of the planet in the title screen and have the player sprite on a bigger world to give a vague sense of a setting, with emphasis that the player is fighting on tiny planets and not just a giant on a regular sized planet.

And that’s basically how I made littleBLASTplanet. If I had more time I probably would have created more enemies and made proper transitions between planets. Aside from that I’m pretty happy with the results, particularly hacking the physics to getting jumping and moving around a 2D planet to be possible.

Voting for the game begins on Wednesday Friday, so if you took part in Ludum Dare, please check it out!