Chao Games

Good evening tumblrites.

It’s been a long time, but the wait has surely been worth it, for I bear a wondrous gift.

Here, a collection of fantasy short stories with philosophical themes written by myself.

Is the title, and each one speaks of a different topic of wildy differing application to reality.

If you wish to know what talented hand drew the above image, look no further than the instagram page here presented.

Looks like it's been more than a month.

oops

2DFPS

Abandonment Date: 19/09/15 Engine: Löve :) Jam: None

This was a simple concept executed in a simple way. It went pretty much like this, if you were in a 2d side scrolling world, theoretically you would only be able to see the world as a straight up and down line, just like how in a 3d world we can only see things as a 2d image. So what if you were a 2d character playing from that perspective. Well, this is what you would see.

In the middle is a 2d representation from the side, so you can kind of understand what's going on. Along the bottom is a light stripe, that's the close wall that you're sighting down. Things further away are darker, so the across wall gets darker towards the top. Those two brown things are boxes, there was some rudimentary physics.

So, looks pretty impossible to read right? Especially with the single coloured blobs. I guess we could replace the blobs with textures, and have it look a little better, but this is all avoiding the big question, why not just have the view go horizontal instead of vertical, doom style? I don't think there exists an answer to that question, so for the time being the idea is shelved.

It’s at this point in my game development adventure where the code really starts to get interesting though, as this is when I start messing around with physics.

Now this, this is awful. You thought that 27 argument function the other time was bad, but look at this. There's so much pointlessly repeated code here, I can't imagine the suffering I must have gone through writing it all out. I wouldn't write something this awful these days, even if someone tried to force me to at gun point.

Good stuff

Now that I've implemented it and seen how terrible an idea it is, I never have to think about it again.

Bad Stuff

So if you've been following my twitter recently you would have noticed all the gifs I've been posting of things exploding.

A couple weeks ago I decided that I wanted to be able to simulate sand for use in partical effects. Now, after a ton of fiddling with openGL, I've got it working. I thought I'd write a summary of how it works, not just to help others who might be thinking of doing a similar thing, but also to clarify in my own head exactly what monstrosity I've created.

The majority of the logic runs entirely on the GPU, which is fantastic, because that thing is fast as hell, but there are some parts of any physics system that can't be run in parallel. To get around this, we perform five steps in sequence, each one a parallel computation.

Force step

MoveMap update

ForceMap update

Move step

Delete step

Force step

All the forces on the pixels are processed here. This is things like adding speed for explosions and applying gravity. Each force is represented by a shader, and each force shader is applied to the speed map to update the speed of each pixel. How is the speed of each pixel represented you might ask? Well, the speed map is another image load of pixel data that overlays the image, and the speed of each pixel in the image is determined by the colour of that same pixel in the speed map.

The more red a pixel is, the more speed it has in the x axis, while green represents speed in the y axis.

There is an issue here already though, as a pixel only has 256 possible values for each of its r,g,b and a values. Because of this, we can't have negative colours, and we also lose some granularity in the speeds we can have. To get around this, each pixel on the speed map has a base red and green value of 0.5, or 128, and any value above that represents a positive speed, while any below represents a negative speed.

The speed is also represented as a fraction of the overall "max speed" defined in the pixel particle canvas. A low max speed restrains how fast the particles can move, obviously, but a really high max speed will create a cut off on how slow particles can move, as really low speeds will get rounded to 0. Once the speeds have been updated, it's onto translating them into movements.

MoveMap update

We can't just apply the speeds directly to the pixels of the image for a number of reasons. One of these reasons is that pixels in an image must be at an integer position, but we want our particles to move smoothly. To get around this, we have the move map, which essentially just records how much each pixel has been acted on by its speed in previous steps.

Just like the speed map, this is represented through the red and green values of its pixels. After we've got the move map updated, we can finally start getting some movement done.

ForceMap update

We're not actually going to make any alterations to the image map right now though, because first we have to figure out exactly what movements are going to happen. Each pixel looks at its move map, and if it's got enough accumulated movement, it draws onto the force map exactly which direction it is moving in.

It's a little hard to see, but each of those purple/cyan pixels is a pixel recording that it will be making a movement in that step. We could probably actually skip this step and have it be a part of the Move update, but its a little neater to have it like this, even if it does slow down the algorithm a little bit.

Move step

This is when it gets really interesting.

Getting the pixels to move might sound simple, but there are a couple things that make it hard.

Firstly, "moving" a pixel is impossible, we can only duplicate a pixel and delete the original.

Secondly, a pixel being processed can not edit the colour values of any other pixels in the image.

If that second point didn’t make a huge amount of sense, remember that we're doing each step completely in parallel, so if we were to edit the colour of another pixel other than the pixel we are currently processing, that would break the parallelism.

To get around this, we do something painful, but necessary. Every empty pixel does a scan of the immediately adjacent pixels, and if it finds a pixel that is signalling that it wants to move into its space, it copies the pixel into its space, making the same copies in the move map and speed map.

It is very important that only empty pixels are allowed to do this, as this is where our collision logic comes from. If a space is occupied, it is impossible for another pixel to enter that space in that step. Even if that pixel is itself moving, we still don't want to move another pixel into its space, as we don't know whether the movement is going to get blocked by another collision.

There is more to the collision system than just blocking movement however. Colliding particles transfer some of the speed to the particle they are colliding with, as can be seen in the gif below.

Without this logic, you can get some really weird behaviour with opposing particles forming solid walls in midair as they try to move past each other. We implement this simply by letting each filled pixel also do a scan of its surrounding area, but only move some of the speed across and leave the colour behind.

BUT WAIT, what if we move the speed across but then in the same step the pixel we're moving it across to itself moves? Remember that we're doing it all in parallel, so the speed we copy for each moving pixel is the speed that we started with at the beginning of the step.

We can fix that in the next, and final, step

Delete step

All that's left to do is delete the original copies of each pixel that we duplicated, and handle that last speed moving case I just mentioned.

Deletion is also kind of painful, as it involves another scan. During the move step, we also leave a signal on the space the pixel moves into that records exactly which space that pixel came from. You can see these signals as little purple/cyan dots in the following gif.

Each filled space does a scan of the surrounding spaces, and if it finds a delete signal pointing to itself, it deletes. These signals also serve another purpose however in solving the problem we have with moving speeds over correctly for collided pixels. Each pixel that moved this step uses its delete signal to find out where it moved from, and updates its own speed to match the old tile. This catches all the changes that were made in the move step.

And all that goes on each step of the simulation, sometimes with multiple steps per frame. I skimped on some of the details, but hopefully the overall picture made sense. If you want to see exactly how I implemented it in the code, I've uploaded it all to github in the repository below.

https://github.com/Cowinatub/pixelparticles

If you are a Löve user yourself, feel free to use the code for whatever you want, including as an example of bad practices in lua, but be warned that my comments are sparse at best. I don't plan to stop working on this yet though, so I'll write more rigorous comments and documentation, if people are interested.

Next, in chronological order.... They’re all going to be in chronological order btw

Galactic Wizardy

Abandonment Date: 28/08/15 Engine: Löve Jam: None

remember pretty clearly what the idea for this was supposed to be, even though it's been like five years. Imagine Magi, if you ever played that, but on a planetary scale. The idea is that you would play a super wizard jumping around between planets in the galaxy, fighting other wizards and stealing their magic.

The catch is, if that isn't cool enough, that you draw your mana from the planet itself, and each planet has a delicate ecosystem that defines what types of energy you can collect from it. For instance, a desert planet would have a lot more fire energy available, while a water planet would have more water energy. This is not just a static state though, but a fluid ecosystem with energy levels flowing between each other, and is manipulable by the dueling wizards.

Sounds cool right? Check out this screenshot.

If that was any more of a clusterfuck, I would be banned.

That pack on the left, that's all the different forms of life turning into death, and death returning back into life. There are even different kinds of arrows, and arrows that need other arrows to let them run. Some of these connections are so complicated that I'm amazed I could even be bothered implementing them.

This is a classic case of the simulationist within me getting in the way of the designer. I wanted to have the planet simulation as accurate as possible, and kind of forgot that someone has to actually play with it. This is an issue that I will be tackling with in the future, and will be popping up in many of the postmortems still yet to come. I'd like to think that I've since gotten over it.

I also had another mechanic, fitting in with the planetary battlefield idea, that there would be a period of the game during which you have to find your opponent, since you are both at random points on the earth. Attack spells increase the "visibility" of your opponent, kind of by a process of elimination, but would also increase your own visibility, kind of like how a sniper reveals their position as soon as they fire.

For instance, the spell below has a huge area of effect, so can hit your enemy without a precise idea of where they are, but also greatly reveals your position.

Think Chaos Reborn kind of luck stuff. It's kind of unclear whether that was actually a good idea or not, the fuckery of the connections system got in the way of any clear testing. Perhaps I'll try it out again some day.

On the code side of things, it didn't look all that bad. Which sucks, kind of, cause I'd like to think that I've improved in the five years I've been coding in lua. That said, I did find this abomination.

I guess I didn't know how to use loops or something.

Good stuff

Dude, that idea is fucking sick.

Bad Stuff

Shame about that execution

Higher complexity makes a cooler simulation, but not really a cooler game

Uncertain Stuff

It was brought to my attention recently that I've published over the last years 19 different games on Itch. That's a lot of games, almost too many. Most of those are game jam entries, and although I've always held with the idea that smaller vertical slice projects were better for learning design, with that much released I can't possibly have really analyzed and taken everything I could get from every one of them. And in truth, I have been neglecting postmortems and that kind of thing. I did used to do them for a while, but I lost that habit a long time ago (around about the point I was 4k words into one of them and lost interest), and haven't in a long time. So, with this body of work behind me, and coming up to my 20th release (it's going to be LD46 btw), I've decided to go through everything I've created and write a short postmortem for each one. Not just for my Itch releases, but for everything. Every half finished wreck of a project, and every idea that I wrote a line of code for and then abandoned. Without further ado, let me begin with...

Aqua Mechanus

Completion Date: 22/05/15 Engine: Löve Jam: None

I wrote this a loooooooooooooooong time ago, and although I had written stuff before it, this is probably the best place to start. Everything before this is so horribly unfinished and unplayable that it isn't really worth looking at. This, on the other hand, is very finished. I remember my main objective creating it was to try and finish something, that being quite the challenge at the time, and I've gotta say it definitely did get finished. The idea was a simple arena shooter, where you play as a mecha squid that shoots torpedoes out of its head. You had to fight against a myriad range of robot opponents (three different types), until you were eventually overwhelmed.

It plays pretty okay, though some of the mechanics are pretty unintuitive, and it encourages some pretty terrible play styles, but it's fun enough. Those colours though, man, why did I think that would work for a background. And it's also kind of confusing to tell what's going on, overall visual clutter is pretty bad. I finished it though, it's fully playable with the enemy waves and everything, and that's the important part.

I was also looking through the code to see how much I'd improved. There were a lot of global variables and stuff around, and the enemy behaviour was literally just one giant if statement, but other than that it didn't look too shabby. I did come across this gem though.

Beautiful.

Anyway, in summary.

Good stuff

Simple gameplay loop, implemented kind of okay.

It's finished.

Bad Stuff

Awful colour choice, and the aesthetic is generally pretty cluttered.

It's got some music. It's not very good.

The mechanics encourage really unfun ways to play.

Extra credits ran another jam, which I participated in this time!

The theme was passage, so after 20 minutes of thinking about the theme, I started working on stuff and seeing what stuck. The idea I came up with was a dungeon building game, where you have to connect different rooms together to create paths for the denizens of the dungeon. Kind of like one of those flight control games, I forget the name if it, but you’ll know what I’m talking about if you’ve seen it.

I’m pretty happy with how it turned out, it ended up having some pretty interesting and emergent gameplay, despite my extreme lack of planning. It’s been a while since I did any jams, so I kind of rushed into this one to make sure that I actually managed to finish. In retrospect, this was a bad idea (just like it was a bad idea the last 300 times I did it). Next time though, next time I’ll plan it all out and think about the design and stuff BEFORE I start making it.

Oh MAN it’s been a long time since I posted here. For the most part I’ve been working on improving the map editor, implementing more features into it and fixing problems that arise. I already did a post on that though, so you know, what can you do.

I did recently make something worth posting about though, specifically, a new enemy.

Equipped with a mining drill, it charges at the player and drills them to death.

It can also do this, but I’d be surprised if this ever actually happened in game.

It also sucks. It’s only ever fast enough to catch up to the player when charging down a long corridor, and the drill doesn’t even do that much damage. I’m intending it to be an early enemy that really serves more as a distraction from actual dangers than a threat in itself.

What doesn’t suck is the tech I made to get this guy working.

Look at that drill. It’s all done through shaders.

Other than that, I guess here’s a screenshot of some of the textures I’m working on for the new level.

I’ve got a bunch of free time coming up, so expect more regular posts.

Oh yeah, and there’s also this.

Hey, welcome to all the new followers! There’s been a bunch of you over the last couple days, I... don’t really know why, espcially since I haven’t posted anything recently. Anyway, thanks for following, and feel free to let me know what prompted you to follow me if you see this, I would love to have my curiosity satiated.

Anyway, onto todays topic. Over the past months I’ve been working on revamping the systems for my current/old project, and I’ve recently gotten to a point where everything “works“. So, I’ve started working on the thing which is going to bring it all together, the map editor.

The map editor I used to have was really barebones, everything was made through keyboard shortcuts and edited through dodgy windows. I’m aiming to be way more extentable with this one, with all kinds of great features that were missing from the last one.

For instance, copying sections.

I’ve also got a rotatable snap grid, so angled corridors should be really easy to make, where they were horribly impossible last time. This gif doesn’t actually show that functionality, but it still looks cool.

I completed a particularly large milestone recently, implementing saving and loading of maps. At this point it’s pretty much done, at in the underlying systems, all that’s left now is to add all the different features (enemies, items, etc.)

So I’ll probably be making a map next, and then after that, who knows, a playable demo or something perhaps. Exciting stuff.

Finally, here’s a picture of the greater program showing the entire interface.

They open.

That’s not all they can do though, along with the doors comes the more general capability to just have moving walls, so I can do stuff like this.

Not only will doors help break up the linear path of the level into more interesting chunks, but having moving walls should generally make the levels feel more alive. And when this is a feature

I didn’t implement doors. Instead, I thoroughly revamped the damage decal systems. Now they stick to walls, and don’t overlap the edges of the model.

Here’s a gif of me abusing a barrel.

It’s been a while since I’ve posted anything about this, mainly because I’ve been making small incremental changes and fixes rather than big system reworks, and twitter works way better for that kind of thing.

That said, twitter’s character limits are a pain in the ass, and pretty much limit my posts to “lel look at this amusing feature“. Here’s a more detailed description of the stuff I’ve been doing.

Probably the largest change I’ve made has been around weapon reloading.

Tumblr’s gif size limits don’t display it very well, but as shown above, when in fullscreen the weapon interface is very far away from the center of the screen. This is an issue, as it means that to see the status of your weapons you have to completely take your focus off your character, which could easily lead to death.

So, the solution is to put the most important parts of the interface around the focus of the player’s attention right? Yeah, in fact there are already examples of this in the game, like how the player is more or less on fire depending on their health.

This has problems as well though, as cluttering up the area of the player’s focus can also be an issue. My first attempt to strike a balance between these two extremes came out as follows.

The cursor is also a significant area of focus for the player, so positioning some stuff around that can also be useful. The yellow fill in the circle shows firing cooldowns, while the little gems around it each represent a weapon, with the one directly above the cursor being the currently selected one. If it’s coloured, it’s not reloading, and the grey border shows whether it’s ready to fire or not.

I’m hoping this will be sufficient, but I’m not going to know for sure until I can get some testers in. Who knows, maybe I’ll be making a similar post in the future.

Also related to weapons,

you can hold down the reload button to reload all weapons instead of just the selected one. This is a lot less painful than scrolling through them all pressing reload.

So yeah, you can see the reasoning behind the delay when that is the largest feature.

Another large thing, that didn’t actually take long to implement at all, is rudimentary pathfinding for enemies.

Here you can see some bots being awful at getting around a wall. This kind of behaviour makes the game way too cheesable, which encourages the player to play in a boring and frustrating way.

Pictured above, bots being decidedly good at getting around a wall. Don’t worry about the extreme screen shake, they’re just also very good at destroying the player.

And, for the smaller features I implemented these badass freeform polygon walls.

And also two new weapons, the Slugger, which can be charged up to fire all its chambers at once.

And the Slave Bots, which fires a cluster of homing projectiles.

So yeah, those are the changes I’ve made since last time.

I’m probably going to do something big next, maybe implement doors or something.

Lets see if this gif gets through.

I guess I’m gonna just have to wait for it to get appealed.

I did 7DRL again this year, with great success.

I don't remember exactly how the idea came to me, but I wanted to do something where attacks were triggered by specific sequences of movement. For instance, moving left left right might trigger an explosion or something. Other than that, my other key restraint was the knowledge of how little time I was going to have this time around, so my scope had to be quite small.

So after much deliberation my basic design came out as follows.

Spells are cast by moving in specific patterns.

These spells confer a variety or buffs, or trigger a variety of attacks.

These spells are used to defeat incoming waves of enemies in an arena.

I went with the arena approach so that I didn't have to deal with level generation, which always takes up a large portion of time.

There were a couple more aesthetic choices that I wanted to play around with too, specifically I wanted to try messing around with a non-fixed tile system similar to what I used in 7DRL 2017. The 'dancing' combat system reminded me of a dervish, or a monk type character, so setting the game in an Arabian desert made sense, which then led into the connection with the tile system, having the arena be the cleared center of a sand storm(this also provided the title, "I of the Storm").

As well as that broad overview, there were a couple design decisions I made that shaped the game a fair bit:

No variable direction arrows/patterns are always the same

I've finally learnt my lesson after all these years, and accepted that greater complexity and choice does not necessarily mean greater strategy. Oftentimes it can just mean greater confusion. So, instead of deciding on an overly complicated system at the start and having to remove it later like last year, I just put my foot down at the start and decided that I would have no arrows changing directions.

I thought this was going to mean that I couldn't have any aimed attacks, but I got around that later on by having aimed attacks targeted by the move you take immediately after completing the pattern.

Limited number of rounds, ending with a boss

I've had a philosophy for a while now, that in general endless games are a bad idea. This is because with an endless game, the 'end' is the point where the player gets bored and stops playing, and the player is therefore left with a bad experience of the game. Following this idea, I decided to have the game run for a limited amount of time, and end with a larger boss enemy.

So, with those ideas in mind, I got to work.

There weren't really any noteworthy points in development(unlike last time), just progress as usual until it was done.

I was happy in the end with how it turned out. It ended up about how I had envisioned it, which is as much as anyone can hope for really. I managed to implement a decent number of different spells to play around with, and the difficulty was sitting in a pretty good spot I think.

My biggest failure this time around was two part, but was mostly to do with forgetting about accessibility. Firstly, the spinning storm effect turned out to make people pretty sick sometimes. I actually predicted this one near the start, but for some reason I convinced myself over the period of the jam that it wasn't going to be a problem, so I never implemented a toggle to turn it off. The second issue was that the text size was quite small, due to how many words I wanted to fit in the description boxes, and the low resolution that I like to design for (just in case people are playing on laptops or something, you know). I fixed both of these post jam, but I really should have predicted this and added in countermeasures before the end.

For anyone wondering why I wrote all that flavour text for everything, I've just kind of been in a writy mood recently. I've been reading the Necronomicon, so a lot of the descriptive style was inspired by Lovecraft's stories. Most people probably won't read it, but I'm hoping those that do find it enjoyable. Copious writing is something that I find a lot of people don't bother with these days, but I find it enjoyable, and I feel it's a good goal to try and make things that you yourself would enjoy.

So yeah, that's how 7DRL went this year for me.

If you want to check out what I’ve been writing about for the last 750 words, link here.

I recently implemented a new texture to replace the ugly looking rocky wall, and I know you guys love it when I go into detailed posts about the underlying mathematics of my systems.

As a point of reference, here’s what they looked like before.

Look at that, so ugly. Ech.

For the new walls, I wanted less overlap and more prominent cracks. For that, I decided to go with a bunch of hexagons with random vertices.

Here’s how that started out.

This is pretty much a map of the corresponding indices in an array for each hexagon. From this I figured out a formula to generate a list of the points that correspond to a given hexagon, and after that it was just case of actually generating this array of points, and randomizing their positions slightly.

Don’t worry about the 120 degress typo, it’s just. Just don’t

Anyway, here’s what it ended up looking like in the end, or at least the general shape.

And here it is in game. (notice how it blends on the corner, it’s pretty neat)

Now I don’t know about you, but that doesn’t look like much of a wall to me, it’s just too flat and joined with the floor.

But that’s where lighting comes in.

I also wrote a shader to draw a nice shadow along the wall edges, to give it that extra depth.

I did it by calculating the distance of the pixel from the wall and determining the red based on that, then taking the pixel with the highest red so as to have colliding wall shadows blend nicely. Finally, the opacity of the shadow is determined by the amount of red.

Now scroll back up to the top and look at how ugly that original wall was again.

Anyway, hope you’ve enjoyed this glance into the mathematics behind a wall shadow.

Just finished LoveJam2019. Back when I was working on detritus walks, I fucked up the wall canvas drawing in a very particular way, that was actually pretty cool. Now I’ve come back to explore the idea more, with the following unholy results.

Apart from looking extremely weirdy, it’s also got pretentious poetry and some okayish platforming.

Yes, I spent a week making really nice weapon boxes. Hear me out though, it might not seem like it but this kind of small detail is a pretty big deal. With the sheer volume of weapons I want to have implemented, it’s important to make sure the first impressions of each one are good, and those impressions start with the visuals of the pick up itself.

Opening the box also has to seem exciting, hence the big activity with the two parts of the contianer flying off, and all the particles flying out.

Here’s the corresponding interface element.

I wrote a pretty cool shader to give it the more spherical look.

Just look at that shader. Unbelievable.

Finally, here’s a comparison photo, from original concept to finished in game implementation.

Anyway, that’s all for this week. I’m not sure exactly what I’m going to work on next, I might patch up some of the background textures.