https://ldjam.com/events/ludum-dare/40/mutoid
Creating everything from scratch was a fantastic learning experience. I plan to complete a post-mortem sometime this week to discuss my hurdles and successes!
If you haven't played it yet, give it a shot! It's all in-browser.
I wrote a quick post-mortem on my first ever gamejam!
Check it out - https://medium.com/@gallen/ludum-dare-40-my-experience-96e1f15a78a6
If you still haven't played my game, give it a shot! In browser play link is at the top of this page - https://ldjam.com/events/ludum-dare/40/mutoid
If you haven't had a chance yet, give my game a shot!
https://ldjam.com/events/ludum-dare/40/mutoid
It's my first ever game jam and I put a lot of effort into making everything from absolute scratch in 48 hours! I hope you enjoy and give some feedback!
I'm excited to see Mutoid reaching close to 20 reviews! Only a few left until we get a score locked in.
If you haven't had a chance to play yet, you can play it here - https://ldjam.com/events/ludum-dare/40/mutoid
If you are interested in reading about the development process, you can read my post-mortem here - https://medium.com/@gallen/ludum-dare-40-my-experience-96e1f15a78a6
Here's a zoomed in view of a converted ally monster! I loved drawing the sprites for the game, even if it was time consuming.
So what's the purpose of the bagger enemy in Mutoid? This is one of the unfinished ideas that made it into my submission.
Originally, the bagger was supposed to collect bodies and haul them off-screen. Due to time constraints, I immediately knew the easier approach would be to have him just eat the bodies and replace them with a blood stain.
His path finding is actually dumbed down for the final submission, to just attack the player if he has no bodies to eat. What he was supposed to do (and is coded to do if you checkout the code), was escape off-screen repeatedly until he had collected 5 bodies. At this point he would evolve into a tougher enemy, and come after the player. This would mean the player had to keep an eye out for these quick, scurrying enemies and make sure they didn't collect enough bodies to level-up. This is why the original "body destroy" functionality was added to the game, so that if you didn't want to revive a mutant, you could still render the body useless for the baggers.
If you haven't played my game yet, give it a shot! I'd love to hear your feedback!
So I created a game for LD40 called Mutoid. I focused on fun gameplay, and I think it turned out pretty fun. If you haven't check it out yet, you can do so here.
The question is, where does the game go from here? I made the decision early on to use Javascript and the CraftyJS library to build this game, but that doesn't translate well to a more complex game design. I have absolutely no regrets using it to quickly prototype my game, it was quick and easy to learn. However, I want to take this game to the next level.
So I'm currently working on a complete port of the game into the Godot game engine.
My plan is to scale EVERYTHING up 3 times. If you have played my game, you know it looks a little fuzzy. This was an unfortunate decision by me to make the main character a 16x16 image. I figured I would save time on the art assets by keeping things tiny, but I didn't think about the fact that the screen itself would show up tiny! So I ended up using some CSS to scale the whole canvas up to a playable size. This makes things really blurry, and makes the game show funny on some browsers. So the first thing I've done is scale everything up 3x. This makes the character a 48x48 image, which is a little bigger than the currently scaled up Mutoid: LD edition.
Besides the various bug fixes that will be implemented in the new Godot version, I plan on expanding the game to my original vision of a full version. The full version will include a few new features like weapon pickups, new enemies (bagger evolution), a few bosses, and controller support. I also will be taking the time to redo some of the sprite animations and general art that I spent next to no time on for the LD.
I have a bunch of other updates on the way for the game and will continue to post about my progress on the port.
In the mean-time here's a glance at the Godot version with things scaled up a bit!
I added the sneks to the game because I needed a ranged enemy. At first I had plans for them to burrow underground and pop-up sporadically to attack. Due to lack of time, I scrapped my ranged enemy and simply made the sneks ranged. They fire 3 toxic projectiles, that when hitting someone, turn into toxic puddles for ~5 seconds. I wanted these projectiles to be dodge-able, so the player had to avoid them at the same time they were strafing around the mutant hordes. I don't feel like I did a good job making them very avoidable. While shooting horizontally, you may notice the spread is significantly better. This is because they target your exact location, then a few points up and down from where you stand. That means if the snake is below you, the spread is a LOT less (still just moves along the y axis). In the ported version of Mutoid, the spread will be adjusted to be based on the trajectory angle.
While in the rush to get the game out, there were a few enemies that didn't see the light of day. Namely the bagger enemy evolution stage, and the boss enemy (A hulking compilation of dead bodies that are held together by tentacles). With the lack of enemies, I was forced to find a way to make the game seem more completed than it was.
So I added a score and distance to the game-over screen, and scaled the difficulty way up! The sneks are not actually that difficult in singles or even duos, but after you hit the 4000 points mark they start coming in groups as big as 5-6. This makes the game extremely hard, and most people can't reach the finale. The finale itself is rather underwhelming without a boss, just a horde of enemies that when cleared gives you a game win screen. So I felt like losing before the finale was ultimately more satisfying than reaching the end of the game and it feeling like there was a lack of content. I still feel like this was the right choice given the options, and makes the game feel like there is more to it than there actually is!
I'm still working on porting the game to the Godot engine, progress is slow as I learn some of the quirks of Godot. Right now I have some basic collisions working with bullets and monsters.
When the port is completed in Godot, I will continue to work on making the game "completed". I plan to feature a few bosses, a lot more enemies, weapon pick-ups, new levels, and more!
If you're interested in following my progress, you can follow me on Twitter!.
Back with an update for my Godot port of my LD40 submission Mutoid.
After struggling to get a handle on the collision system (There's really a lack of good tutorials), I finally got bullets and damage working. From that point forward development gained some momentum. I haven now got scrolling background, mutant attacks and deaths, player shooting working, and player death working. Next up is collision with the upper buildings and viewport bounds. Then start and end game screens, and finally the other two enemies that are currently missing from the port.
After that point, I can start adding some of the new features I have planned. Lots of cool stuff planned, especially with the lighting built into Godot.
Here's a peak at the port progress.
Godot part is going extremely well! I have the base game completed now, killing mutants, death animations, scrolling background are all done. I took some time today to play around with some of the lighting features that Godot offers, as well as some particles (for blood in this case).
Here's a peek!!
I've spent the day updating the graphics on my LD40 submission Mutoid.
Originally I had created the characters as 16x16 sheets to keep art simple, but then I was forced to scale everything up real-time so it was easier to see what was happening. This made everything show up blurry. So I have now scaled all the art up 3x and fixed the corresponding code issues. Things are much cleaner now! It is especially obvious around the heads of the characters as well as the bullets firing. Checkout this comparison:
Before: 
After: 
My game is officially submitted to the compo (well was like 20 minutes ago). I had a blast again, this time I learned Godot (the good and the bad).
I hope everyone had a good 48 hours and I look forward to playing some interesting games for an... interesting... theme.
If you get a chance, give my game a try and leave some feedback!
When the theme was announced, my initial reaction (like most) was to google game genres. My biggest issue with combining two genres was that, by definition, if they were able to be combined they were "compatible". This was hard to wrap my head around at first, until I came to the conclusion that the theme should really be interpreted as "Genres that don't work well together". At this point I also hit another roadblock, if I'm making a game with a core that by nature doesn't work well, making a fun game could prove very difficult. I decided my best approach would be to take a game under a genre I knew I could make fun (Beat 'Em Up) and just add another genre (Art Tool Games) on-top of it as a slight twist.
I ended up coming across the Art Tools genre (Mario Paint Wikipedia lists Art Tools as a genre!), and immediately I thought of coloring tiles with enemy remains to draw a picture. The easiest combination I could think of for this, was a simple Beat 'Em Up game.
The vision from the start was to build a game where you walk into a room with a picture outline on the ground. You then have to fill in the picture, like coloring, with the blood of your enemies. Points would be scored based on how closely you manage to draw the picture at the end of the level, hence the ability to clean tiles. Unfortunately the final product isn't quite this, the levels are more like random colored tiles to be filled in and not necessarily pictures. I found that making the tiles small enough to draw a good picture made killing monsters too tedious. Additionally, levels proved too difficult if there were a large number of tiles to be filled in. I felt the game was more fun when I designed the levels to challenge the player in a specific way (i.e. blue tiles opposite side to green tiles to force the player to lure sucka's better).
My final submission does not have any pictures or real drawings in it, but the concept is still there. To go along with this, I had planned a way to upload an image and generate a new level to play based on the picture. This is something that will be in a future update (Yay post-LD versions!).
I plan to make more of these posts in the coming days, talking about things from music to why certain monsters were cut from the game.
If you haven't tried my game yet, give it a shot! I'd love to hear feedback, good and bad :)
In the spirit of Ludum Dare, I've not pushed any enhancements to the game, simply bug fixes and play-ability issues. If you're interested to see the specific changes since the deadline, you can click here now to see exact differences of the files. I've branched off a ludum dare maintenance branch which will NOT receive anything beyond bug fixes. I will, however, be starting work on a full fledged game with the concept and foundation code.
The changes I made to the game are below:
If you tried my game before and thought it was too hard, give it another shot! If you haven't tried it yet, give it a shot and leave some feedback!
One of my favorite parts of building games is putting the player in a scenario where they can triumph and feel good about their victory. Enemy design is a key factor in making that come true. AotK has a few interesting enemies to help generate these scenarios.
For starters, I knew I needed a generic enemy type. An enemy that is ridiculously easy to overcome, and feels satisfying to just mow through. This is where Enemy 1 comes in. They are very plain, they are slow, they have low health, and they deal little damage. They often show up in large numbers in the later half of the game to make up for their lacking strength. Attacking these guys is supposed to feel satisfying as you can kill them in two hits, quickly clearing a crowd if in the optimal position.
Next up, I needed a more vicious enemy. I took the base I had with Enemy 1 and made it a real threat. These turned into the red Clawer enemies. They move faster, have more health, and do more damage than Enemy 1. These guys don't show up in groups larger than 5 for the most part, because they are a force to be reckoned with. They force the player to move around due to their high speed. This makes it tougher for the player to position themselves to mow down groups of Enemy 1!
At this point, I discovered the winning strategy for this game. To win all you had to do was strafe around the arena, swooping in to kill an enemy in the opportune spot, then bounce back to the outside and keep strafing. This made the game sorta boring in my eyes. The enemies were too dumb to prevent this from being a winning strategy, so I came up with a different type of enemy. This is when the Sucka enemy was born. The Sucka is a unique enemy in that it never attacks the player. The Sucka code literally doesn't even have an attack function built into its loop logic.
What this forced the player to do, is move to the inside more often. The strafing strategy wasn't totally ruined, but it was definitely made less effective. If the player just strafed around constantly, the Suckas would eat the perfectly placed tiles before the player could escape.
This led to some interesting levels where the player was forced to lure the Sucka into blue tiles so they could be killed to fill the tile. The Sucka doesn't even move if there are no colors to eat! This did however, lead me to the fourth and final enemy I was able to implement in the 48 hour window.
The Slug is the counter to the Sucka. If a Slug appears on the map, it will randomly move about, ignoring the player unless they get too close. The trail it leaves behind GREATLY decreases the player's score if it doesn't get cleaned up, but it also lures Suckas away from potentially more valuable tile fills.
The Slug also comes in any of the three colors at random. This means they could be used to fill victory tiles be luring them over tiles to be filled, or that they could wander over tiles the player has painstakingly filled in. In later game levels, things can be chaotic and not noticing a slug can be a huge hamper to an otherwise winning strategy.
I hope you enjoy these write-ups on my game entry! If you haven't given my game a try, why not try it now? I'd love to hear more feedback! If you have played it but not recently, give it another try. The difficulty was slightly toned down to allow players to advance further on less plays and see more of the content!
As with any sort of timed programming challenge, I made a few decisions that I went on to regret. That's sorta the purpose of these though, to try new things and learn what works in an artificial time crunch. One of the mistakes I made, was making the art too detailed for my skillset. My previous LD submission (LD40), had an extremely low pixel count art style. Character legs/arms were 1 pixel wide, and that decision was made on purpose to make art take less time. My final version of the game however, seemed to lack polish due to the shortcut in art. This time around I decided on larger character sprites, starting at 64x64 and ending up with some larger 128x128 characters.
LD40 vs LD41 player sprite sheet
While the art does look nicer, I spent probably half of my allotted time just working on the art. This led to a few things (like the enemy spawners) being rushed, causing them to standout as being less detailed. Not only that, but it was time I lost for gameplay enhancements! Ultimately I think with more practice drawing, I can get to a place where I can pump out high quality sprites in shorter time. Until then I will probably move my resolution back down for the next jam so I can put more focus on making the gameplay awesome.
As I continue my game post-LD, one thing I had in mind was a mobile port. Using Godot this made it really easy. Last night I got it running with some placeholder controls, and it runs really smooth!
Lots still left to do before I release an official post-LD version. But exciting to see and play the game on a phone!
A lot of the comments I've gotten on Planet Jumpers have revolved around the procedural generation. It's not surprising, the game has a lot of RNG (for better or worse).
In this post I'm going to briefly cover how the planet map in the "explore" phase are generated!
If you haven't played Planet Jumpers yet, you can check it out here!
Before we get too far, it's important to know that every planet is generated with the following properties: - Planet radius - Gravity - Biome - Atmosphere Toxicity - Distance from galaxy center
When a player lands on a planet, and successfully passes the crash phase, the game generates a new map to explore. These maps are generated using the random walker algorithm. Essentially the game takes a point in the map, and walks in a certain direction until it hits a maximum "distance". At this point it picks a random direction and starts moving that way. This repeats over and over, until you end up with a set of coordinates that, in this case, correspond to "walkable" space for the player.
In order for each of these maps to be even more diverse, the game alters the presets for the algorithm based on a few planet properties. The overall dimensions of the map passed to the algorithm is equivalent to the current planet's radius multiplied by 4 and rounded down. For example, a planet with radius of 20 would have a map dimension of 80x80 tiles. The algorithm needs to know how many tunnels it should take before returning the result, the game generates this by picking a random number between the dimension times 0.75 and the dimension times 4. The max length of each tunnel is then randomly picked between 2 and 20 tiles. The last thing the algorithm receives is a random point somewhere on the tilemap to start. With this information, it generates a map of open vs blocked tiles.
Here is the code, which is probably more readable than my explanation:
var dimensions = int(floor(Game.currentPlanet.radius*4))
var maxTunnels = int(floor(rand_range(dimensions*.75, dimensions*4)))
var maxLength = int(floor(rand_range(2,20)))
var map = generateMapOpen(dimensions)
var currentRow = randi()%dimensions
var currentCol = randi()%dimensions
Now that the game has a map, it calculates how many fuel pickups it should place. It does this by taking the atmosphere toxicity of the planet, multiplying it by the radius of the planet, and diving it by 2.25.
var numberOfFuel = Game.currentPlanet.atmosphereToxicity * Game.currentPlanet.radius / 2.25
This isn't a perfect solution, and has been a main point of difficulty for new players. The calculation for fuel could definitely be improved. The 2.25 is simply a number that after trial and error I felt fit well on average.
These fuel pickups are then placed by randomly selecting walkable points on the map.
Maps can also contain shield repair kits for the ship. These are also a rather simple calculation. It takes a random number 0-4, it then subtracts 1 if ship health is already over 3, and subtracts another 1 if the current planet's atmosphere toxicity is less than 50% of the maximum possible.
It then places the repair kits (if any) randomly in walkable spots around the map.
The third item that is then placed around the map are "air pockets". These are weird growths on the ground that when stepped on give the player oxygen. These are generated by rounding down the planet's current atmosphere toxicity, adding 3, and then picking a random number between that and 0. The code looks like this:
var numberOfAirPockets = randi()%(3 + int(Game.currentPlanet.atmosphereToxicity))
It then places these airpockets randomly around the map on walkable spots. Additionally these air pockets are colored to match the general atmosphere color of the planet's biome (the same color you see when crashing in the background).
The last bit that is generated for the map, is where to place the player. Since the player has just crashed, it must create a large area for the ship itself to be, and the player to be next to. To do this, the game finds a random walkable spot on the map, and creates a square of walkable space around it. It then places the player and ship in the center. Additionally the game ensures that this new area of walkable space is fully enclosed so that the player cannot walk out of bounds. This code is not very pretty, but got the job done for me: ```
for x in range(playerStart.x-9, playerStart.x+5): for y in range(playerStart.y-7, playerStart.y+7): if $TileMap.getcell(x,y) < 0: $TileMap.setcell(x,y,closedTileIdx)
for x in range(playerStart.x-6, playerStart.x+2): for y in range(playerStart.y-4, playerStart.y+4): $TileMap.set_cell(x,y,openTileIdx) ```
Overall, the RNG for the maps is pretty straightforward. If I continue working on the game (highly likely), I will probably overhaul the system to something more interesting. I'd like it to ultimately be easier on specific planets and more difficult on others, but I would also like it to feel fair to the player. Right now a lot of the player's progress is based on luck, and picking the right direction to walk. I'd like to somehow guide the RNG to make it always "possible" to win utilizing the correct strategies.
Thanks for reading, and stay tuned for more write-ups on the development!
In Planet Jumpers' third phase of gameplay, you fly (or drift) through an endless universe. The goal, to get further than anyone else has ever been from the starting point. As of writing, that records belongs to a gas planet roughly 18 million miles away named... (checks notes)... uh... that's not that important right now... More about the leaderboard in another post. This post is to explain how the universe generation works!
Here's a zoomed out view of a new round with freshly generated galaxies! That tiny planet in the middle? That's the starting planet that everyone starts on each time.
So how does the game build this? Well let's start at the smallest piece, a single planet! Every planet is generated with four primary attributes. - Gravity - Radius - Biome - Atmosphere Toxicity
These different attributes give the planet a different look in space!
As you can see in the image above, these properties allow planets to have a wide variety of appearances! The player can even actively avoid toxic planets by paying attention to the slight color changes.
All of these properties are generated at random, with position being calculated during galaxy creation.
Here's the code for planet creation.
func generatePlanet():
return {
radius = rand_range(16,64),
gravity = rand_range(20, 80),
biome = PlanetBiome.values()[randi()%PlanetBiome.values().size()],
atmosphereToxicity = rand_range(1,MAX_ATMO_TOXIC)
}
So what is galaxy creation, and how does it work? Well, here is a simple galaxy, freshly generated.
Every galaxy has a star in the center of it. When a galaxy is created, it picks a random number of planets between 1 and 10. The first planet is placed 150 units away from the center, but the direction is picked at random. After it places this first random planet, it then picks a random number between 2 and 5, and multiplies it by the first planet's radius. This is then added to the first planet's distance to get the distance for the next planet. The direction in which the planet is placed, is again generated at random.
This is then repeated for each planet that is placed. The planets are limited to be at most 500 units away from center, causing planets to sometimes stack up at the edge (Not intentional on my part, something that I wish I had more time to tune!). Below is a diagram explaining the placements.
Here is the code that generates a galaxy.
``` func generateGalaxy(x,y,planets = 10, maxPlanetDistance = 500): var sun = sunScene.instance() sun.globalposition = Vector2(x,y) sun.planetsOrbiting = planets $Planets.addchild(sun)
var lastPlanetDistance = 150
for i in range(planets):
var randomDegree = randi()%360
var randomRad = deg2rad(randomDegree)
var planetVector = Vector2(cos(randomRad), sin(randomRad))
var newPlanet = newPlanetNode(x,y)
var planetDistance = lastPlanetDistance + rand_range(2*newPlanet.planetRadius, 5*newPlanet.planetRadius)
if planetDistance > maxPlanetDistance:
planetDistance = maxPlanetDistance
newPlanet.global_position += planetVector.normalized()*planetDistance
$Planets.add_child(newPlanet)
lastPlanetDistance = planetDistance
```
So now that we see how planets are placed within galaxies, how do galaxies get placed? Well galaxies use a very similar approach. When you first launch, the game generates what I've called a "space area". This area consists of x number of rings of galaxies. Due to performance limitations, the game currently only generates 1 ring of galaxies at a time. These rings are generated with a center on the current player position. Every ring is 1000 units apart. Each ring has a specific number of galaxies within it, the calculation for this is below.
var galaxyCount = 4 + floor(2 * distance / ringDistance)
Since I originally wanted multiple rings to generate at a time, the calculation takes into account the current ring's distance from the player. Since there is only ever 1 ring at a time, the current version of the game always generates 8 galaxies in one ring.
Once the galaxy counts are calculated, it picks a random degree to start with (0-360). It then takes 360, divides it by the number of galaxies, and that becomes the degree of difference between each galaxy in the ring. This makes it so that the ring has evenly spaced galaxies placed around it.
Here is the code for generating an area of space.
func generateSpace(centralPosition):
var ringsToGenerate = 1
var ringDistance = 1000
var maxGenerationDistance = ringDistance*ringsToGenerate
var distance = ringDistance
while distance <= maxGenerationDistance:
var angleDeg = randi()%360
var galaxyCount = 4 + floor(2 * distance / ringDistance)
for i in range(galaxyCount):
angleDeg += 360/galaxyCount*i
var angleRad = deg2rad(angleDeg)
var position = centralPosition + (Vector2(cos(angleRad), sin(angleRad)) * distance)
generateGalaxy(position.x, position.y, randi()%10+1)
distance += ringDistance
Below is a diagram showing roughly how galaxies are placed around a ring.
The final question is, how does the game handle when you go outside of the galaxy ring? The answer to that is somewhat disappointing I'm afraid. Due to time constraints, I wasn't able spend time figuring out a way to map areas that have previously had planets generated. I also didn't want to risk the player getting lag from too many planets. So my solution was to calculate a "play area".
A "play area" is simply a bounding box, calculated by looking at the furthest planets in each direction.
Here is a quick illustration of what a "play area" would look like.
When the player steps outside of this box (plus some margin), all planets that are currently in play are destroyed and a brand new galaxy ring is generated around the player. This is unfortunately crude, and causes both stutter during the game and noticeable flashes of planets at times. However, it does ultimately give the feeling of a never ending universe.
To sum things up, the random generation is relatively simple! Planets are placed at random distances on a random angle from the center of galaxies, and galaxies are placed along a radius from the player's position. With this we can get what feels like random planet placement in all directions. Generating a game each time really does feel unique, and despite a few hiccups and shortcuts I am happy with the result!
I've released my fourth Ludum Dare game and first one in TWO years!
Despite having to pivot my idea 4 hours into the competition, I was still able to put something fun together.
Play as an unstable person in this isometric shooter. Leverage your insanity to access new parts of the world and maximize your damage output. Swap weapons during combat to utilize better stun vs damage weapons.
This is a dark game and contains sensitive topics, so please be warned! I tried to make it a bit interesting and build something of a world. Give it a shot and see if you can discover the GOOD ending!!
If you find any bugs please let me know! I'm sure there are some in there and I'd love to fix them!
More posts coming in the next week as I unpack a post-mortem and talk about my aborted game!
