#raylib

It's about getting chased by Satori Komeji on a maze... the game design is intentionally retro lol. Runs on both mobile and pc on web --- no need to download anything so try it out once ^^

normally i dedicate my public facing social media accounts solely to sharing my finished artwork, but I figure some reflection on the past few years of my development as an artist would be worthwhile. I was initially trying to find an old gmod map I made (I didn't find it), and in the process I found a number of screenshots of WIPs spanning the past 7 years. for many of these projects, they were abandoned because I got too busy with school/university.

from march 2017. made in unity. I don't remember the specifics of this project. I think I was trying to make a short narrative walking sim.

from december 2017. I wanted to make a short smw romhack. I remember drawing level designs on a spare piece of paper after finishing a secondary school exam early. one day I'll make a romhack, one day...

from may 2018. I had just replayed marble blast ultra after finding it had a PC port. shortly after I found all the textures were just in the game files and could be modified easily. myself and an old friend wanted to make a 'games repainted'-esque mod. I claim full credit for every marble game since that's included a 🤔marble skin.

from march 2020. a mockup of a piece I was calling 'alignment chart' for the first time I had ever applied for a bursary. this used a mixture of generative art pieces i made in processing and graphic design. this piece is interesting to look back on because it marked the development of my art style for the first time, and the psuedo-cuneiform generator ended up being a recurring feature of my art. my application was rejected because i did not read the terms and conditions to realise it wasn't open to university students - and I was still studying computer science at the time.

from may 2020. I was aiming to participate in the low res game jam but never got to finish due to university work taking up my time. I never fleshed out the mechanics of the game, but the goal was to take care of the tree in the center of the map. it doesn't look like much, but I really pushed myself (or rather, tortured myself) by not using a game engine and writing this in C++ with raylib instead.

from april 2020. this was going to be a browser based demake of five nights at freddy's (a game I've never played and have no interest in) titled "five years at yanderedev's". I figured that it felt too close to participating in lolcowing someone and that it was in bad spirits, so I scrapped it.

from september 2020. a mockup of my homepage sharpfourth.net. I kept the logo and general layout for whats on the site currently, but didn't include the scanner warped images.

from october 2020. I wanted to make a walking sim in the quake engine, but once again, university work got in the way. however, this got me familiar with the basics of using trenchbroom (a map editor for quake), which came in very, very handy for later projects.

from october 2021. myself and some close friends had planned to make a zine detailing how to do DIY feminising HRT in Ireland (and maybe the UK). we never got around to writing it (partly because we feared potential legal repercussions for disseminating medical advice lol), but this marked a further development of my art style.

from october 2021. I had hoped to make a first person RPG in godot. once again scrapped because I got too busy with uni. I spent ages trying to implement a wonky movement system that could be exploited, being inspired by bhopping from source or strafe jumping from quake. the dialogue system was the last thing I worked on. I used trenchbroom again - this time with qodot - for making the prototype map. while making this demo, I realised the potential use of godot and trenchbroom in visual art, something i would revisit during my first gallery residency.

from march 2022. this might be the most unassuming piece in this collection, but it marks a significant turning point in my life. I was tasked with making diagrams for a group project in uni, but given that I was facing extreme burnout and apathy towards the course, I instead "doodled" with the elements of the diagram. this spiraled into me writing my zine/short-story EATARTHU, which I then used to apply for a gallery residency. I was fortunate enough to get the residency, and I dropped out of college to pursue art.

This is fuckin huge.

Fuck electron apps loading up your 8Go of ram with a single one open, embrace real GUI in C, C++, Odin and many more to come with Clay

I'm so in love with this. It's C99 style, single header, very elegant and nice to use. Works with raylib, opengl, sdl, vulkan, and ANY OTHER RENDERING ENGINE.

Video tutorial and presentation under the cut:

Recently I've been getting into retro game development. I don't mean pixel art and PSX style game development, those are nice but they don't quite scratch the itch. I'm talking about developing games with retro tools. Because of this, I decided to give Raylib a try.

For those of you who don't know, Raylib is a C framework targeted at game developers. Unlike Godot, which I used for my previous project Ravager, Raylib is not a game engine, it doesn't offer physics, scene management, or any kind of graphics more complicated than drawing textures to the screen. Almost everything that makes a game a game, is something you have to do yourself. This makes it ideal to scratch that "retro" itch I've been feeling, where everything has to be made on my own, and a finalized game is a fine tuned engine entirely of my own creation. Raylib offers bindings for almost any language you can think of, but I decided to use it's native C.

Setting the Scene

Since Raylib is so barebones, there's no concept of how the game should be built, so the first thing I had to do was define my engine architecture. For this initial outing, I decided to build a simple Scene+Actor system, wherein at any given time the game has one Scene loaded, which contains multiple Actors. I settled on this mainly because it was simple, and my experience with the C language was very limited.

Since Raylib didn't have any concept of a Scene, naturally it had no way to build them. While I could just hardcode all the entities and graphics in a scene, that would be unmanageable for even a basic game. Because of this I was forced to invent my own way to load scenes from asset files. This gave me the opportunity to do one of my favorite things in programming, defining my very own binary file type. I won't get into it too much right here and right now, but in this format, I can define a scene as a collection of entities, each of which can be passed their very own long string of bytes to decode into some initial data.

The main drawback of using binary files instead of a plaintext format is that I can't write the level files by hand. This meant that I had to write my own level editor to go along with my custom engine. Funnily enough, this brought me right back to Godot. The Godot engine offers some pretty powerful tools for writing binary files, and it's editor interface automatically offers everything I need in the way of building levels. It's sort of ironic that my quest to get away from modern engines lead me to building yet another tool in Godot, but it sure as hell beats building a level editor in C, so I don't really mind all that much.

Getting Physical

After getting scene management out of the way, I moved on to the physics system. My end goal here is making a simple platforming game, so I wanted a simple yet robust system that allows me to have dynamic-static physics that allows for smooth sliding along surfaces, and dynamic-dynamic collisions for things like hitboxes. For the sake of simplicity (which seems like it's going to become my catchphrase here) I decided to limit physics to axis aligned rectangles. Ultimately I settled on a system where entities can register a collision box with the physics system and assign it to some given layers (represented by bit flags). Then entities can use their collision box to query the physics system about either a static overlap, or the result of sweeping a box through space.

Raylib offers built in methods for testing rectangle overlap, so I didn't have to worry much about overlap queries, but the rectangle sweeping method is something a little more special. The full algorithm honestly deserves it's own post, but I'll give the basics here. The core of the algorithm is a function that determines where along a movement a given rectangle touches another rectangle, and that edges of the rectangles touched. It makes use of the separating axis theorem to determine when the shapes will start and stop intersecting along each collision axis. If the last intersection happens before any have ended, then the shapes do collide, the axis they collide on is that final axis, and the time of collision is the time of the final intersection. Looking back I could easily extend this algorithm to any arbitrary shape, but that's for next time I do this.

Going Forwards

I finally got around to actually making a working front-end for the clone of The Witness that I started back in mid 2023. Here is the official release.