At the start of this month there was a pair of simultaneous jams, 7DFPS and proc-jam, both taking apart over approximately a week, and with very relaxed rules, essentially being "make something in first person" and "make something that makes something". I've had a bit of a dearth of personal dev recently (2020 huh?) so decided to take some time off work to make something for these jams.
A procedurally generated multiplayer puzzle game made in WebGL, the code is available to view on github
One Release a Month is a relaxed jam me and a few friends are doing in which the only goal is to release something each month. I'm working on quite a few different things at the moment - my HTML5 2D game library Hestia, an electron editor Hekate and my Unity ARPG Seekers - none of which are really suitable for a monthly release. So I've been spending around one weekend of each of the last two months dabbling with a voxel fort generator for 1RAM. It's more of a toy than a game, but I've enjoyed working on it and hopefully it's fun to mess around with.
I've been enjoying working in HTML5, and then I saw Ludum Dare was happening, so I decided to take part in the compo and battle test my library Hestia. The theme was "Keep It Alive" and I made:
"You are in charge of live cargo on a space hauler. Ideally keep them happy, at least keep them alive".
Xeno Tender is a very simple life sim, where on each journey you have to look after one of three creatures.
The source is viewable on github
A lot of ARPGs have abilities which simply happen when you press a button, then depending on the way you're facing they execute an effect. These types of ability were easy enough to set up using the scriptable object system I described in my last post on Seekers, by using the character's facing direction in the implementation of the game code implied by the definition classes.
These systems work fine for a single joystick and buttons - whether it's a virtual pad on a touch screen, a physical gamepad or with the controls mapped to the keyboard - but it doesn't really work if you're using a mouse and keyboard. Users expect your character to aim at your cursor position, regardless of which way your character is facing. Part of the challenge for Seekers is for it to be a multiplatform game, and hence supporting as many input methods as possible, this makes supporting aiming independent of facing direction something worth investigating.
Over the last week or so I've hacked together a text editor using electron and ace, but before talk about how, perhaps I should start with why! Well we're in lock down so looking for something to do I unpacked the Rasberry Pi 4 (Model B+) that bought on a whim a few weeks ago, setting it up I noticed it had 2 micro-HDMI outs and thought "Hmm it'd be pretty nice to have two monitors for this I wonder what extra cables I'd need to buy to be able to use both with my primary laptop as well?". I inspected my laptop's ports and found two things, one that I'd need a mini display port cable and two that the casing was starting to separate. Flipping it over to check and sure enough there was some localised swelling, cue the screwdrivers and sure enough...
A major aspect of ARPGs is the abilities of the playable characters and of their enemies. A warrior spinning both blades around themselves pushing back enemies, a mage firing a series of explosions forward damaging friend and foe alike, a boss striking the floor in rage causing the whole environment to shake.
There is usually a lot of these abilities, their effects wide ranging and they're subject to a lot of iteration and tweaking, so if you're making an ARPG you're going to ideally want a system that makes it easy to: specify many types of effects, create new abilities quickly, tweak existing abilities at run time, all with minimal code duplication and easy to extend with new features.
The basis of this system in Seekers is a set of scriptable objects of different types which specify the various aspects of an ability. Scriptable objects fulfil the "as many as you want", the "easy to create" and the "easy to tweak" requirements. The create asset menu attribute allows you create assets to represent your abilities (or their sub-elements) from scratch, being unity asset files you can serialize and link them from character definitions or scripts and you can duplicate existing abilities to make similar abilities or variations. You can also change their values at run time and see changes immediately without a recompile.
The first thing I do in any new game is get the player character moving and animating. In Unity there are three main options for animation:
Using the legacy animation component
Simple and direct playable of individual animations, but precludes humanoid animation retargetting.
Using the animator component using animation controllers
Fine explicit control of animations and transitions built using in editor visual state machine.
Using the animator component with a playble graph
Allows you to build state machines programmically at run time, which can be changed on the fly.
For an ARPG style game like Seekers, the primary use case is very simple direct "play this clip". I don't particularly enjoy using the editor to build visual state machines, and needing a different number of clips per character would mean either many making state machines or one very large machine, however I may wish to use humanoid animation sets across multiple characters. So I decided to use a playable graph with the animator component to try to recreate the simplicity of use of the legacy animation component.
Seekers is what I've decided to call my little, work in progress, ARPG / Roguelite game! The general idea being that each of the player characters is seeking something, that their motivation for adventure is different. Whilst don't expect to be putting much narrative into the game, I think it's helpful to have lore to help guide development whether or not you directly show it to the player.
As I alluded in my previous posts, this is intended as something of a practice project, trying to find something that falls into the "able to make", the "want to make" and the "want to play" categories (reference). My intended approach is to make the minimum possible that constitutes a game and then add features and improvements for as long as the project holds my interest and / or there is interest from others.
In order to try and generate said interest from others, to allow players to help guide development and to figure out if anyone wants to play this kind of game, I going to be making work in progress builds publically available as soon as I have that minimum viable game. As for what that minimum viable game entails, I'm currently thinking a single playable character and a single level that takes a few minutes to play through, ending in a boss battle.
As there has been some interest on twitter, I also plan to write blog posts outlining the major systems I've built that help me make this game as a solo developer. Thus far those are the animation system using the Playables API, the code driven timelines I use to create abilities for players and enemies, and the trigger / receiver system I use for 'scripting' events in the level. However as I tackle new features, say Boss AI or level creation I'm quite likely to make more!
As text only blog posts seem to be out of fashion, this is a gif of me testing the trigger / receiver system by spawning enemies when the player interacts with an object, and yes the main character interacts with things by hitting them.
In the first half of this year in my spare time I was working on the pixel perfect renderer and the multiplayer top down shooter, as well as doing a little pixel art. At work I was lucky enough to be leading a small team prototyping a multiplayer mobile action RPG, in the style of non-stop knight (but with more permanence and boss fights amongst other changes). The original idea being that your character would move and perform basic attacks without prompting and you would trigger special attacks. We couldn't get publishers to bite, so we moved towards no automation more inline with classic ARPGs and mobile MOBAs (like Mobile Legends: Bang Bang), which did result in a much more compelling game but the publisher we were in talks with already had a similar game so declined to take up full production, so sadly the project was put on ice.
There's a particular game design I've had in the back of my head for a few years now. A sci-fi cooperative shooter. Originally the idea was mash up of Left4Dead and Phantasy Star Online. Valve's cooperative shooter was the first time I'd seen a game so successfully engender team work, and was still a very immersive experience. The 'AI director' tech meant it took a lot longer before it was the norm to game the systems. I played PSO on the Dreamcast a few years earlier, and enjoyed the world, particularly the first few levels, the aesthetic and the space opera feel of the main story, even if the mechanics were a little clunky.
Sometime after playing L4D I found Alien Swarm , a free top down shooter from Valve with a strong 'Aliens' vibe, it seemed to incorporate similar swarming logic in it's enemies along with class specific mini-games. The fact it had classes and was a softer coop made it naturally closer to PSO, and yet still had the high skill ceiling / potential for mastery of the first person shooter which PSO had lacked. So the design shifted to being closer to a mash up between Alien Swarm and Phantasy Star Online.
At the start of this year I played around with PICO-8 and there were lots of things I loved about it! The focus on being a fantasy console meant that retro aesthetics of the sound, music and graphics were nicely in sync. The image memory and code character limits forced you to focus on achiveable games. The BBS system was very cute, worked well and had some of the "view source" mentality for game dev that helped me get into web dev.
However there were a few things I didn't like; the small caps font in the integrated IDE I found extremely difficult to parse and switching to an external text editor broke immersive beauty of the program. Whilst the focus on character limits and low memory was encouraging for small scope games, it forced you to write very imperatively which I think is kind of bad practice and prefer writing in an event driven style, and this meant certain game types were extremely popular on the BBS (2D platformers I'm looking at you).
After keeping the same design and broadly the same content for years, I've updated the site with a cleaner design and refocused the content. This includes adding this blog system, which should allow me to post about investigations, work in progress projects, and occasionally just stuff I'd like to write about!
It also includes putting up a page for Fury, the WebGL renderer I wrote a few years back, and sending some time updating the voxel terrain demo with improved performance and the ability to generate larger environments asynchronously, as it's a fun thing to play with.
The pixel art that I posted on twitter for Pixel Dailies earlier in the year are viewable on the pixels page, and I plan to post further pixel art pieces I make there too. Hopefully I'll get better. The new format of the site will probably better represent the fact I'm a bit of a dabbler.
I also took a little time to clean up the tutorials section, both updating a couple of the WebGL tutorials that had become out of date, and removing the Unity tutorials that were really glorified blog posts which were heavy on approach but light on detail.
I'm hoping to either polish up and post, or write a retrospective on, a few of the projects I worked on over the last year, as I've worked on quite a lot but not talked about or posted any of it! After that I plan to have a crack at actually completing a personal game, crazy I know.