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.
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.
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!
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.
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.
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!
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.
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!
Check out the Steam Store, and you’ll see that Gemstone Keeper has a page where you can add to your wishlist, purchase the game and write a review for it. I greatly appreciate seeing people buying the game and giving it a good review, it really means a lot after realising that this game has been in development for nearly two years (May 2015 – April 2017). Reviews in particular are important because I’d like to collect a list of issues and make fixes, and hopefully add a bit more to the game over the course of a year. Gemstone Keeper will also be shown at Insomnia 60 at the Birmingham NEC and maybe a few more events if people find an interest.
In particular I want to thank Vincent Rubinetti for his contributions for the game. While he was the person I had in mind to do the soundtrack from the point I listened to his music in INK, I was a bit nervous about approaching him with the demo I had. However after a few emails back and forth, we made an agreement and we were underway for producing a great accompanyment to the game’s visual art style and atmosphere.
In addition, I’d like to apologise for leaving this two days late; I couldn’t plan ahead because I spent the last few days sending out emails and twitter DMs in the hopes to get the game looked at by people; I fixed bugs and adding some last minute features such as damage numbers appearing whenever you hit something with your bullets and being able to type the seed you want to use in Score Mode.
On the launch day, I was at Rezzed, where I did talk to a few people about my game, but mainly walked around and tried out a selection of great titles. By the time 6pm rolled around, I hung out at an after party and chatted to a few developers.
Then the day after was my birthday, so I figured I would post on social media, but spend most of the time away from the game and more with friends and family to celebrate and relax.
As for my future plans, aside from this game’s maintenance, I’m hoping to return to smaller games for a while. In particular I want to try a few more game jams and experiment a bit more, I have a few ideas I want to try out, and now I have a little less pressure on me to work a bit on them.
Back in May, I made a simple demo for a University Thesis, now it’s less than two weeks away from being released onto Steam. This is such an exciting occassion for me, but also a nerve wracking one. If all goes to plan, Gemstone Keeper will be available on Steam on March 31st at 6pm GMT.
For the time being I will be working hard on polishing the game and getting the word out, I appreciate any help from that. There have been several updates from when the game was shown at LAGC, especially thanks to the feedback I got of the game from both GEEK Play Expo and GDC. Game has been balanced (repeatedly), boss battles have been redone and several bugs have been fixed.
I’d also like to give my thanks to Gemstone Keeper’s composer for the soundtrack, Vincent Rubinetti. He is probably best known for producing the music to the game INK, the colourful yet minimal platformer by Zack Bell. We’ve been in regular discussions both online and at GDC about the game’s music, and you can hear one of the tracks from the game’s brand new trailer above, I think it’s some brilliant work.
I’d like to thank everyone who has shown support for Gemstone Keeper over the last year or more, this game has been a huge milestone to conquer and I hope all those who try it will have a great experience.
It’s just amazing to think of how it all started…
On Friday, Valve posted on the Steam Blog that Steam Greenlight will finally be replaced by a new system for game developers to submit their games to the digital distribution platform. The new system will be called Steam Direct, where a developer can fill in a set of digital paperwork (such as company, tax and bank information) and pay a fee for each game they submit, with a small verification process to ensure that games will be able to run properly through the platform. With this news bringing heated discussions among game developers and journalists, I figured I’d put all my opinions down on one post to give my side.
While I have Steam Greenlight to thank for giving Gemstone Keeper the chance to be on Steam, I feel that Steam Greenlight has a lot of issues and is an easily cheatable system. It can make a game developer’s efforts a bit demoralising when they work hard on a game, pay the fee and spend time to create a good description and video to be placed on the page, when among the other hard working developers who put as much effort, you are also competing with people who either flip pre-made assets onto the store and could easily rack up votes by offering free Steam keys. Doing things the right way, as I talked to students about at a Staffordshire University conference months earlier, might take a few days if you are lucky, but more likely take weeks, months or (in a few cases) years to get greenlit, if you are greenlit at all.
The idea of having a fee per game, instead of a fee per account, is not new. It’s been suggested even why back when the idea of replacing Greenlight was first mentioned by Valve back in 2013, and I’m one of the group who agreed with the idea. This means that I was initially glad to see Steam finally announcing Steam Direct with this fee approach. It’s also worth mentioning that Steam has said that all games which have been greenlit, but have yet to be released, will not be affected by the transition and that it is possible to get a refund of the Greenlight submission fee if you do not have any Greenlit titles.
That being said, there are some concerns, namely with the vague and limited description of the approval process. While it’s all good to ensure that games released will actually contain an executable required to run the game, the question of quality arises. I’ve heard some ideas that a full vetting process would mean some really creative games would get rejected, which I do find valid since the appearance of a game is subjective, but I’d disagree on the fact that having a game that is quirky or unusual in appearance would still get through as long as it can run smoothly with a good framerate on average hardware and would be difficult to crash or bug out. It’s a concern to bring up, since part of the reason why Steam emassed such a large amount of poor quality games is because they allowed poorly made games to get through.
The other main concern is the size of the fee, to quote the blog post from Alden Knoll:
We talked to several developers and studios about an appropriate fee, and they gave us a range of responses from as low as $100 to as high as $5,000. There are pros and cons at either end of the spectrum, so we’d like to gather more feedback before settling on a number.
While a lot of developers are either worried or accepting of the maximum fee, citing either eliminating low income developers and developers from third world countries, I’m gonna be sounding like the optimist and say I doubt Steam would ever set the fee at $5000, unless they fully accept the risk of alienating a large amount of aspiring developers and reverse the progress of allowing indie development to be more accessible to bigger platforms. However it is because of reasons given like the fact that Valve and Steam are a business, submitting games has its own costs and there is a risk on Valve to allowing several games, especially if it’s unlikely they’ll make any money on the platform, that I do not see $100 being the fee they’ll decide on. Based on the several discussions I’ve read and the majority of developers preferring a lower fee, my best guess is that whatever fee Steam decides, it will not exceed $1000, maybe not even $750 if it would deter anyone who wants to use Steam as a way to make money with little effort.
Some have even suggested that the fee will bring a rise to smaller marketplaces for indie developers, as even Itch.io even joked about. I like seeing more variety, and I’m happy to see platforms like itch.io, GOG, GameJolt Marketplace and the HumbleStore growing their own communities, it would still take a few big named publishers to move to these platforms to topple Steam over.
Finally, I want to give my view to a point made by Jonathan Blow, who made a series of tweets criticising game journalists who write about Steam Direct being a reason for Indie Developers to panick, and not considering views who are on-the-fence or approve of Steam Direct. I don’t entirely agree with his viewpoint, in particular I don’t think it’s correct to think Kotaku/Polygon’s potentially biased reporting on the Steam Direct based on actual sources and “fake news” to be the same. However, considering that it’s only been a weekend and not every bit of infomation on Steam Direct has been finalised, I don’t think it’s good to treat every bit of detail in the Steam Direct announcement as negative, considering this is one of the first positive steps Valve has made in a while regarding Steam in a while.