Rogue of the Seven Seas – 7DRL Postmortem

Last week, the 7DRL Challenge took place. It’s the same game jam that I’ve done three times previously, where game devs have 7 Days to make a RogueLike, a turn-based procedural roleplaying game with permadeath. One of the benefits of this jam is that you’re free to choose which seven days to take, as technically the jam ran from the 5th – 14th March, but you could start at any time as long as you finish at the end of the seventh day. Funnily enough, the past ones I’ve only done on even years (specifically 2016, 2018 and 2020), but I figured I’ll make an exception.

The Idea

I decided to start the jam on Saturday morning, but I needed an idea. For the week before the jam started, the most I was thinking of doing was something in the realm of Smash TV or Robotron as a roguelike, I was struggling to get anything concrete. Then an idea hit me while, admittingly, I was listening to some sea shanties/acapellas on Youtube, a sea-based exploration and trading roguelike. The player would start out with a weak dingy and move their way up to a massive multi-sail ship through buying and selling items at ports, as well as making other ships surrender their supplies. It felt like a fun idea, so I went with it.

Rules

I have developed a mostly streamlined process for working on games in a jam enviroment, based on my previous experience. Coincidentally, I did a pechakucha talk for the local Midland Games Industry talks night:

To summarise, I often use this section that I routinely post during Ludum Dare:

EjL_Em8WsAYHmKA.png

Fortunately, I take advantage of 7DRL’s relaxed rules of pre-existing code and used a base template project that instantly provided me with a title screen menu with options and a blank state for gameplay, combined with some code for tile-based movement and tilemap features from my previous 7DRL entry, built in my own game framework that I’m very familiar with. That there is a good example of Know Your Tools!

Gameplay

Then was the first two rules, Gameplay First and Small Scope, which was what I wanted to focus for the first two days. I wrote myself a checklist of what I wanted in the game using comment blocks in my game’s code, there were three main things I wanted to focus on: Generating Land with ports to sail into, buying and selling stuff in those ports, and combatting other travelling ships.

First was the land generation, which I went on instinct and went with using FastNoise to generate a noise tilemap that I can then define which would be land and which would be ocean. I ultimately went with using a combination of Perlin and Simplex noise to get enough variation in the noise pattern, transformed it to have values between 0-63, and then through experimentation ended up with any tile with a value below 45 being sea and the rest of the values above could be a certain level of land.

The next challenge was to group each land tile into a group of them to make up an island, I ended up using a recursive depth-first search algorithm to go through each tile and all of their neighbouring tiles, using an array flag to avoid any tiles being checked twice, creating a box around each island so I could work out how many ports each island would need and avoid applying tiles to other islands by checking for overlaps.

For placing ports, I was admittingly lazy and decided to just randomly assign every beach tile (the lowest land tile ID) as a potential port and chose at random which one to use. In hindsight, this would cause scenarios where ports are right next to each other, or at least be close on the same island for easy back and forth. I think if I wanted to make choosing port locations more interesting, I might have use algorithms to determine suitable paths between islands near to each other, that way it would make sense for a port to be located close to a near, perhaps with A* path finding or delauney triangulation.

Despite this, I at least had a tilemap with islands separated out so I could start a ship on a random port, and then have it travel to other islands grid by grid. Since I had the data, I decided to make three more tilemaps to render on the sides and corners, setting their location depending on the ship’s location on the map. Combined with the game moving the player to the opposite end of the map if they go too far in one direction, and you have the illusion of a seamless map that wraps around.

Next were the ports and combat, both of which were menus. The port menu used mulitple switch cases, which I was foolish enough to use knowing that I also had my framework had its own Finite State Machine, which I would use with the combat menu. I ended up keeping the stock items (which players can buy and sell) in a separate array from upgrades (which you can only buy) so that stock could be easily increased and reduced in events such as trading and battles, while upgrades have a single purpose.

For battles, I had ships scattered randomly outside the player’s field of view, and those ships would only update when they were in view of the player in order to optimise for AI calculations. I actually had some fun with this, separating the ships into pirates and transport ships, and not only giving them different behaviour to give the generated world some life independent from the player: Pirate ships will always move towards the nearest ship, even if it isn’t the player. They can then engage against the other ship into battle, which means that other ships could sink without you being near them. Meanwhile, transport ships will aim to go to a port, and so will move along a generated path towards a random port.

By the Sunday evening, I had finished the base gameplay, with the most basic visual assets. Unfortunately, gameplay work never really finished because of balancing out the stats or both the player and other ships, not to mention tweaking the land generation. In the end, I’ll see what the reviews will say about how the game feels.

Art

I normally do pixel art myself with piskell and photoshop. However, despite having seven days, the remaining five days were also working days, meaning I only had evenings. That meant I resorted to open source/creative commons art assets. The main ones that helped me were Kenny-NL’s pirate pack for the ship designs and qubodup on OpenGameArt for environment tilesets, with photoshop to aide me in giving the assets a bit more of my own style. I also made use of stock images for the port menu to give a visual aid. I think the only original artwork I actually did was the side view of the ships, the UI box border, and a secret boss. I remarked that I wouldn’t get high marks for graphics, but some of the other participants reassured me that it looks fine. Fortunately, 7DRL doesn’t merit how games look and sound.

One downside to this tileset is that GIFs ended up being massive on the overworld.

Sound

So for sound effects, I used sound effect libraries from GDC audio packs and freesound, with the sound of oceans being ambient. However, with it being early 2021 with sea shanties being all the rage, I couldn’t help but make some basic renditions of my own. I didn’t go with any fancy samples and beats like I did with Twist, Turn, Shoot, Burn, just some basic NES chiptune using soundfonts. Of course one of the renditions had to be the Wellerman, since that one blew up on TikTok, but I also know a couple others so I also did renditions of “Leave Her Johnny” and “Bully in the Alley” as well.

What went wrong?

I really should have taken five days off to get the most out of this jam, doing five evenings from 5pm to 11pm (and Saturday 2am) is really tiring and you end up struggling with even the basic tweaks. I already mentioned the placement of sea ports, and how the sea port menu used switch cases when the combat menu used a finite state machine. I also ended up missing out on features that could add to the challenge, like a content weight limit (you can buy infinite amount of stock to sell).

Being better rested and prepared would have also helped me with submitting the game. Word of advice, never use Windows Explorer to set up a .zip folder. I don’t know why, but if you ever try to update a file within a .zip folder, Windows Explorer corrupts it. The best recommendation is to use 7zip or WinRAR instead.

In the end, I’m pretty proud of this game. It feels a lot more complex than KALQL8TR and yet just as novel, I might do a post-jam build some time this week to see if I can fix that menu and sort out the ports and whatever improvements I think I could make, but for now, I hope people enjoy it.

https://gamepopper.itch.io/rogue-of-the-seven-seas

Calculators of Pandemic Proportions

Good start of the decade, huh? In February I was enjoying a break from game development outside of patches for Gemstone Keeper, as well as spending a nice holiday in Sweden. Then March hits, and a virus that started in the Wuhan province of China spread to pandemic proportions and every country was starting to lock down and encourage people to either quarantine or distance themselves from others. For the last six weeks, I’ve been mostly working from home, my only travels are our long hikes around the local countryside and I’ve only been able to communicate with family and friends online in video calls or online games (Jackbox and Animal Crossing have been godsends during this pandemic).

It’s still a good time as any to work on some smaller games, and I’ve been wanting to get back into a few game jams, so during this pandemic, I took part in two big ones: The Seven Day Roguelike and Ludum Dare 46. This post goes over Seven Day Roguelike’s submission: KALQL8TR

UPDATE: The results for 7DRL were just released earlier today. Each of the 166 games were ranked in various categories. KALQL8TR was able to get into the Top 50 for all but one category, including 8th place for Innovation!

Continue reading

Gemstone Keeper is out on the Nintendo Switch!

By the time you read this, Gemstone Keeper will be available for purchase on the Nintendo eShop in most of Europe, as well as Australia, New Zealand, Canada, Mexico and the United States!

Gemstone Keeper is an action twin-stick roguelike shooter where a brave explorer can traverse a large and mystical cavern to search for rare and precious gemstones. The deeper an explorer goes into the caverns, the more valuable gemstones that can be found, however at the risk of facing more of the dangerous and hostile creatures that live there, including creatures that are larger than life.

Armed only with a gun, explorers must break through rocks to collect minerals and gemstones and fight off the creatures, and find the portal that can help them go back up to sell what they collect or go further down.

Gemstone Keeper uses ASCII art in both a pure and diverse form, as almost every part of the game’s look come directly from text and symbols while very loose in form. The weapon and bullet system is fully interchangeable, over 150 gemstones to collect, several creatures and bosses, different game modes and a soundtrack that echoes through the open spaces in-between the rocky walls. Gemstone Keeper is the shooter that is both fun and eerie.

It is honestly just crazy for me to think that back when I started making games nearly 10 years ago, I wanted to make video games for one of the big consoles, and now I have achieved that goal! Any and all feedback will be great, and I’m just thankful for everyone who has helped in some way, from the SFML team for being helpful for technical issues I had, Vincent Rubinetti for coming on to produce the brilliant soundtrack, to Ironbell for reaching out to me with the idea of working together to bring SFML to the Nintendo Switch.

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

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.

IRDC 2015 Review

So to sum up last weekend, when I went to Nottingham for the International Roguelike Developer Conference 2015’s UK event, I’m not kidding when I said I had little expectations, considering that the Roguelike genre is still fairly new to me, despite spending a year researching procedural level generation for my University dissertation. Despite this, I had a great time and was able to gain a lot from the games, the genre and the role of procedural generation from these two days.

Day Zero

Although I have met the event organiser Mark Johnson and Roguelike developer Darren Grey from the PROCJAM conference organised last year, I wasn’t sure if I was able to meet anyone at the pre-meetup, especially since Mark unfortunately went down with food poisoning before the pre-meet began. However I decided to head off to the Bell Inn and see if I could find anyone.

By chance, I went to the bar and a man sitting at the table asked me “You here for IRDC?”, that man was Johannes Kristmann, and with him was Paul Jeffries. We talked about games, had drinks, and they joked about IRDC events of the past and eventually more people showed up, including Alan Charlesworth, Tom Betts and Ido Yehieli. We all decided to have more talks and drinks at Darren’s apartment block until we all decided to head to our respective hotels to prepare for tomorrow.

Day One

These were all the talks that were given that day (taken from Mark Johnson’s blog):

1025 – “”And [my bot] vowed to return victorious!”: Spelunky as an AI Benchmark” (Tommy Thompson)
1050 – “Dungeon Crawl Stone Soup Development” (Pete Hurst)
1115 – “Alternative Death Systems” (Darren Grey)
1140 – “Generative Design” (Paul Jeffries)
1205 – “Modability and You” (DarkGod)
1330 – “Making a Roguelike that uses Twitter Data” (Sean Oxspring)
1355 – “KeeperRL Development” (Michal Brzozowski)
1420 – “The Curious Expedition Development” (Johannes Kristmann)
1445 – “Murder Puzzle – No Longer a Roguelike” (Ido Yehieli)
1510 – “Scaling Brogue“ (Flend)
1535 – “Creating a Procedural Level Editor” (Me)
1600 – “Sir, you are Being Hunted Development” (Tom Betts)
1625 – “Algorithmic Generation of Global Racial, Cultural, Religious, and Architectural Variation” (Mark Johnson)

There were so many great talks, some were really funny and others were really informative, I even managed my talk, despite all my nerves. I spoke about a part of my University dissertation, the Procedural Level Editor.

https://i0.wp.com/i.imgur.com/LpRWHmy.jpg

https://i0.wp.com/i.imgur.com/N96tsAW.jpg

If you didn’t catch them on Twitch, all of the talks will be online on Youtube in the coming weeks. These talks were followed by curry, and then drinks at Ye Olde Trip to Jerusulem, possibly the oldest pub in England.

https://i2.wp.com/i.imgur.com/s4TEZqW.jpg

Day Two

This was an experimental part of the day, where members of the public got to try out some classic and modern roguelikes such as DoomRL, Angband and Incursion among others, as well as a selection of board games that possibly inspired Roguelikes.

https://i0.wp.com/i.imgur.com/6yAauak.jpg

https://i1.wp.com/i.imgur.com/lgqNwtW.jpg

https://i2.wp.com/i.imgur.com/Cd4yqz5.jpg

So I had a really fun time, and got to speak to a lot of talented game developers about procedural generation and gaming in general. I got to talk about my University dissertation, and I also got to speak on roguelike radio about the conference, which should also be online soon as well.

https://i0.wp.com/i.imgur.com/Sa877Nz.jpg

So I think it’s time to announce my new main project, during my dissertation I wrote a short prototype game to demonstrate the procedural level editor. I’ve decided to extend this game to be Gemstone Keeper, the roguelike twin-stick shooter. It will use the Procedural Level Editor, which I will also release for public use when it comes to a stable enough point.

https://i2.wp.com/i.imgur.com/3R45Qzw.gif

Speaking at International Roguelike Developer Conference 2015

On June 27th-28th, there will be a two day unconference on Roguelike Games at the National Video Game Arcade in Nottingham. IRDC has been running since 2008 and each year has taken place in a different country, but this year two unconferences have been organised, with the other one being in Atlanta back on May 30th.

UltimaRatioRegum

UltimaRatioRegum, one of the many modern day roguelikes likely to make an appearance.

Today I can confirm that I will be one of thirteen speakers at the IRDC, where my talk is titled “Creating a Procedural Level Editor”. I will be talking about the development of my dissertation project, the Procedural Level Editor, which I initially wrote about more than two weeks ago. The talk will be on the Saturday, and there will be a public showing on Sunday where attendees will be able to play a load of classic and modern Roguelikes. More information about the conference itself can either be found on the organiser’s page here, or on the IRDC Europe page on RogueBasin.

https://i0.wp.com/www.leftlion.co.uk/images/galleries/479/DaveParry-LeftLion-NVA-0585.jpg

National Videogame Arcade in Nottingham

If you want to watch the talks, but do not have the means to travel to Nottingham, not to worry, as with the Atlanta Conference, the conference will be streamed live so you can watch it all. I shall pass around the link nearer the time of the event.