Unstable Grounds – Ludum Dare and the Future

So it’s been been several months since I last made a post here, life has been busy and it’d been more difficult to motivate myself for games development than it has been in the past. Most of my time outside of work had been preoccupied with personal writings completely irrelevant to games, including a book project that I had been working on and off since May 2019, and after Rogues of the Seven Seas, I was doing lots more writing and walking around the lakes and countryside than writing code.

That being said, in April of this year I decided I was going to set a weekend aside to work on a games jam, a simple bullet hell game for a bullet hell themed game jam. It went alright, but in my stupor I failed to realize that this game jam was a week before Ludum Dare 48, and so as a result of mental exhaustion, I decided to opt-out.

Fast forward to this month, and needless to say, things went a bit crazy. To start off with the easiest, I decided I was going to take part in Ludum Dare 49. Because I’m kinda lazy, I’ve copied over the postmortem I wrote on the website to explain how they went.


Although I’ve done several game jams over the last eight years, this time was rather worrying for me as the last game jam I actively took part in this year was back in April. Not to mention, I had fallen back to my low, unmotivated, state that I thought I broke out of back in LD47, so I had done little to any hobby game development during the months since then. When I said I would take part in LD49, I was incredibly rusty.

The Idea

Ludum Dare has a tendency of the majority theme being something a lot of people hate, and “Unstable” was no exception. I initially gave it a positive vote, until I found out that all I could come up with during my brainstorming session was a physics balancing game, so I changed to a negative vote.

When the theme voting results were released at 11pm on Friday, I couldn’t think of any other idea, at least until I talked it over with Kris, a friend that I usually talk with about game ideas for Ludum Dare. When I told him that all I had was a physics balancing game as an idea for the theme, he replied “city building game about balance right?”

Since I was working with a mostly 2D game framework, and a physics based city builder sounded like it’d work with 3D, I was doubtful of how good the idea would be, but I had nothing else to go with.

I quickly set up a physics world in my project, and using the custom shape object to create a bowl shaped world and some randomly placed blocks in less than an hour. The resulting GIF was slightly more popular than I thought it would be.

LD49-00000.gif

Day One

As with other previous Ludum Dares, I work on a set of rules. First two rules are Gameplay First and Small Scope, to put it simply I make sure the gameplay that I want is done in the first day and I make sure the scope of the gameplay is not too big.

The three things I wanted the game to do first and foremost is to place buildings, move them around, and have little people walking to and from them. Prior to this, I had worked on adding phyiscs in my engine, and I wanted to make it easy to add and remove physics to a game object. As such, all I need to do when clicking on a building was to remove the physics, and then add the physics back in when I click again to place a building.

I also wanted to avoid buildings from being dropped at high places, since blocks tend to bounce when they land, and might not go exactly where the player wants it to. As such, I had to go back to trigonometry to calculate the point on the ground to place buildings based on the mouse’s position.

As for gameplay logic, I figured having buildings not only of different sizes, but different types. Houses and apartments would house people, shops would be wider and be a place people can go to, power stations would be the largest (and therefore heaviest), hospitals can produce more people overtime, and police stations would reduce crime (and hence reduce the chance that people would die).

LD49-00002.gif

Unfortunately, I didn’t have the day completely free, it was one of my friend’s birthday, and we all went out to a fancy Indian restaurant to celebrate, followed by more drinks afterwards. Considering the lack of social gatherings because of the pandemic, I didn’t want to miss out, so adding people was rushed in past midnight. It proved to be harder than getting the buildings to work, since the people needed to walk from one building to another. I wanted populations to be kept track of, so buildings needed a count of how many people are in them, with the count changing when people leave and entering buildings.

Not to mention that getting people to move on a constantly wobbly surface isn’t straightforward in a physics enviroment.

Day Two

One of my other rules is [Make your content easy and noticeable], which is primarily a rule I apply for doing art for the game. If I decided to go with doing the 72 hour jam instead (or was able to produce more art at a faster rate) I would have done more detailed fully coloured pixel art, but given the rustiness I have (and I had recently transitioned from Photoshop to Photopea), I went with the 1-bit minimalist approach.

Texturess.png
LD49-00003.gif

Looking back at the first GIF with art for the houses, I kinda like the effect I put in with the outline of the ground drawing around buildings when they land, it’s a pretty easy trick that didn’t require any shaders to pull off, however I wasn’t a fan of the lack of detail the bowl ground had, even though in hindsight it looks like the city is balanced on some Figgy pudding.

As for music, I went with LMMS. After the suprise success of the audio in my LD47 entry, I used my same approach of utilising samples and instruments for the music. However, I couldn’t really come up with something long and complex enough that could fit the city buiding theme, which was ultimately why I took out Audio rating for this game. I’ve heard some people say they still like the music, but I don’t think it’s worth getting a ranking for.

Sound effects were also just random chiptone samplings. I kinda wish I had more options to create sound effects for games so they don’t all sound the same.

The last thing I added for the game was the weather effects, which was a combination of a random applied force and particle effects so it looked like either snow or rain. I felt like I had everything done by 9pm on Sunday, and as such submitted it to the compo.

Conclusion

LD49-00005.gif

I think the game went well, the biggest positive I can say from this game was that it was the first time using the implemented phyiscs in my engine in a game project, and it went remarkably well. There are a few hiccups that I can’t figure out (notably when game objects jump in the air after a certain amount of delay between frames), not to mention the code I used to handle the amount of people in the city was broken, leading to people being visible despite the city population being zero, as well as a lack of transparency inside the game regarding to how buildings work.

But as long as other people enjoyed it, I’m happy with it. Glad to know I can still make games in two days with only a few bumpy roads.

LD49-00006.gif

As of writing, that was several weeks ago, voting has since finished. One of my friends asked what I’d hoped my ratings would be, and honestly I thought the game was too simple and the hiccups would put people off giving it high scores, and with my Ludum Dare 47 having my best results so far in the compo I didn’t think this game would top it,

Well…

Capture.PNG
EIGHTH PLACE?!

I still cannot believe it, even after going to the game’s page multiple times. but there it is. After eight years of participation, I’ve achieved a top 10 ranking in the Ludum Dare comp. It was surreal seeing my game on the results page without the need to scroll downwards.

Still, words cannot describe how happy I am to achieve this. Thank you to everyone who played it, shared it, and provided feedback on it.

The Future

This part is quite important, as it has both good and bad news.

I’ll give the bad news first, following from Gemstone Keeper on the Nintendo Switch, I started working on a new big project, a bullet hell shooter. I had gotten up to a pre-alpha demo before the pandemic brought a lot of things to a grinding halt. I’ve decided to place this project on hiatus for the forseable future, if not indefinitely. This is partially because the inspiration that got me to work on it has all but faded out, and although I did use some of the code for Bullet Hell Exam, so it wasn’t all to waste.

If I get new inspiration, I may pick it back up again, possibly starting from scratch, however there is a new career that I wish to focus on. This is the good news.

Starting near the end of November, I will be working for Team17. I have had a great time with the company I have spent six years with, but this is a career opportunity that I have been working for since the beginning, and I’d never forgive myself if I didn’t take it. Team17 has been around longer than I have, and I’ve enjoyed the Worms titles from my childhood, and their decision a few years ago to move into indie game publishing has shown to be impressive. I look forward to joining them, and seeing where my future will take me.

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