And the game development progresses.

The goal for this stage of game development was to produce a 'vertical slice', a short demo, containing as many of the game's features as possible, but minimal content, which can be polished to a degree where it can be shown off as a thing.

I am not there yet. Development is slow. In part this is by design, I am streaming the entire development, which means that, with distractions and limited time available, only a small amount of progress can realistically be made. However this choice was made in part as the act of streaming it helps with motivation. If I'd done it differently, the velocity would have been higher, but I'd have burnt out long before this.

The vertical slice was then decided to give me a shorter term goal, it was also something which would help me decide on game design decisions that had I could not make before actually implementing them. Have I finished it? Nope, not at all.

I have done one third of what I want to do. Kind of.

I have broken the game design into three parts. Action, Adventure, Shmup. I have been working on one of these, the adventure game section.

This is only in part because of my love of adventure games. I have a plan for this: Adventure game system to create basic gameplay, interaction etc, then extend that with combat and exploration for the Action game system, and finally reuse what I can if I still have energy to do the Shmup game. I would like to add spaceship combat in the shmup sections, but as it's a very different game style, it's very much a lower priority right now.

With the adventure game then, the idea was to pick a scene from the story of the game, and implement it as a short puzzle. The point was not to make a particularly difficult problem, but to have some mandatory narrative/exposition. This is not a pixel-hunting adventure game, or an inventory hunting one. You need to go to the right places, and talk to the right people. Hopefully it will get you to connect with the crew of your little ship.

At this point, the implementation of the adventure game portion is pretty much complete. The story for it is complete and implemented. There are some bugs, including sequence breaking ones, and some logical inconsistencies if you do things in a different order. There is also a CPU stall, at least one crash, and some graphical issues that need to be fixed. And it's missing content, half of the rooms aren't decorated, and most NPCs don't have a walk cycle.

Regardless, I have made the demo, as it stands, available for download now, just so people can see how it's coming together. Updates will continue. For the most part I'll be leaving the adventure game as it currently is for a time though.

Or, I probably will. I keep flip-flopping between what I want to do here. Part of me wants to work on the important code parts, which would now mean moving onto the action section, and part of me wants to just polish the adventure game until this bit is done.

The current plan is to pivot to the action part. This will be more Metroidvania than I've currently done. While not immediately important to the action part, I want these gameplay parts to have more exploration. So I want to work on stations. Stations should be made of rooms like ships, but should also be different configurations. This will mean I have to create a system to be able to stitch together station modules to have a semi-randomised layout, then I can work on improving the exploration/platforming mechanics, and add NPCs to interact with, before implementing combat.

A lot of things.

A number of these posts have ended getting published together for a few reasons, but development has progressed. Unfortunately there has not been a massive amount to show in the intervening time, it was mostly rewriting sections to use the new memory systems, fixing issues, and starting working on the demo story.

So let's talk about that. Not the story, but the demo.

I've been saying that I have been wanting to make a metroidvania for a while, and I do still intend for that to be what the game is, at least in part. That's not what I'm making though.

The thing is, I don't really know what balance of things I want the game to be at this point. Metroidvania is a bit difficult to reconcile with the space station/space ship idea. I have some ideas, but implementing anything that makes sense, expecially on the Jaguar where I'm writing everything from scratch, seemed like a fairly tall order. I know I want story though, and I like adventure games. I don't have to have a polished platforming system for that. I don't have to figure out how to shoehorn a combat system into a universe that hasn't had any on-screen personal combat to this point. I could start by implementing some of the basics I would use, and get a demo.

So that's what this is. It takes place part way through the planned story, when the player has already met all of the crew (the intention is to use crew as some of the Metroidvania unlocks, so you build the crew up as you go) It is a simple short event, with some narrative, dialogue, a very short and straightforward adventure game style puzzle, and that's it. Probably no more than five minutes of gameplay, and that is if you're reading all of the available dialogue slowly. It is not necessarily intended to be a section of the game, as much as proving out some of the systems.

After this demo is done, I want to do a similar one showing some combat, perhaps boarding an enemy ship, and fighting their crew. For that I definitely need to rewrite the physics (currently, if you bang your head on anything, you snap on top of it) and obviously work out a combat system. I will be grilling Helge to see if there is any reference in any combat in canon lore that I could take some inspiration from. While this may be a separate demo mode, in the game itself, it is intended that these are not independent systems, and you will change between these fluidly.

There is also the plan for a spaceship shmup mode, where the player can pilot the ship against oncoming enemy ships. Implementation of this mode is probably a bit easier than the rest, but I have no experience with making this fun at all, so this scares me, and I don't have any assets for this yet, so that will come later.

How far have I got with the adventure demo? Quite far actually.

I have a story system, which acts as the script for what is happening, who goes where, and says what. There is a dialogue system, although currently the only branching dialogue is done by the player choosing to talk to one character over another. I have NPC animations. I have points of interest that the player can interact with. I have music. Pretty much the only actual feature that I'd need to complete the demo is the index the images, so that I can do full screen effects by palette swapping. I need a considerable amount more content - sprites to flesh out all of the rooms, character animations, sound effects, and then scripting the remainder of the scene, but I'm fairly confident that, at this point, the majority of the features are implemented.

So, what's next? Well, the image indexing for one, and adding more content of course.

In terms of posts, I have a few things to talk about optimisations, plus some waffling about the dialogue system. We'll see what I feel like talking about next.

Back in days of yore, there were a couple of ways to get music into a game. The first relies on the computer to have a synthesiser chip. The most famous of these is probably the Comodore 64's SID chip. These are miniature hardware synthesisers. The computer itself does little to no work to acutally play music, it just says "play this note" and it's the chip's responsibility to go and find a way to replicate that note. This is what chiptunes are - tunes generated by the chips.

The other option is for the computer to play samples. These can be entirely synthesised, or recorded. They are then modified by the computer to be the correct pitch, and then played in the correct order.

Of course there is some overlap between the two, and as with anything, it's not such a clear line. The Game Boy for example is very much in the former camp, but at the same time, one of its four channels is able to play short samples. The Atari Jaguar kind of goes the other way. At least with the sound engine I'm using, U-235SE, it can play any samples you give it, within certain limitations of course. However, despite this fact, it does have a dedicated chip, Jerry, for handling this. The CPU does not do the mixing. Jerry is a programmable RISC, but it still sits somewhere in between a pure chiptune machine, and the sample-driven system which would become modern music authoring software.

In the previous attempt at this project, I approached Matias Sosa on fiverr to create a variation of Foundations, the main menu intro music for X4 Foundations. He did a great job, and I'm keen to use it in this iteration of the game development. When I added the file to the game, it jumped up to 1.5MB. Now, this might not seem like a massive size in 2025, but we're talking a cartridge games console from the early 90s. The absolute maximum size of the ROM could be 6MB. If the game is at 1.5MB with one music track, a handful of roughly laid out locations, and very little gameplay, then I'm doing something very wrong, or going to end up with big problems.

To explain the problem, we need to discuss the file format that the music track was delivered in. It is a 'mod file' - a tracker format used initially on the Amiga. Looking up the format, the short version is that there is a 1084 byte header, which is a fixed size regardless of the track. Then you have multiple 1024 byte patterns. In the example of Foundations, there are 10, making up the 60s of the track. Following that you have the instrument samples. The lengths of these are defined in the header. In the case of the track I was using, this was then a little over 1kb of unavoidable data, 10kb of song data, and then 850kb of instrument samples.

Matias has been amazing and helped strip this down. It is now a hair over 350kb, and I think we can get it further, but I'm less concerned about this at this point.

But what does this mean? 350kb for every minute of music in the game? I'll still run out quickly.

No. The actual song data is 10kb per minute of audio. The intention going forward would be to have a library of instruments which all tracks can use. This library can be added once, into ROM, and could even be compressed. At runtime this can then be copied into RAM, along with the song data and header. U-235 can then play the mod file from RAM rather than ROM. This will mean that I'll need to allocate enough memory for the rebuilt mod file in RAM, but it will mean that the ROM doesn't grow at a crazy rate, and I can fit a lot more music into the game!

At this point, I honestly don't know how tight memory usage is going to be, but I'm assuming somewhere in the region of "very". However one thing was obvious - I'm going to have to keep an eye on the memory usage. If I were writing in assembly at this point, I might maybe try to manually specify memory locations for everything I need - I may still do this. But for now two things make this a bit more difficult. Firstly, I'm still writing mostly in C - while I can specify memory locations to place things, C's stack and heap doesn't necessarily respect the fact that I just used that location. The other thing is that, at this point, I don't know what I'm doing. I have ideas for gameplay, ideas for story, ideas for implementation. None of them are anything like fully final. It still feels like I'm very much in a prototyping phase still. I don't believe that I have the experience to create a flexible memory map, or a solid enough design to just wing it.

So. Right now the very hacky way that the game is written is, most things are stack allocated in main, and pointers stored globally - this is because I seem to have a bug where, for some reason, allocating anything globally just doesn't work. I haven't looked into why, but globals are bad, so I didn't worry about it too much, figuring I'd remove the pointers anyway.

So, I've written allocators.

I have written three allocators. A final one will be added, but that will basically be a NOP, with the intention being to use it to block out memory, which can, at a later date, be used as above, in a more standard memory map.

The first allocator to be implemented was an arena allocator. This works by not actually reusing memory, but just continuing to allocate at the end. Then, at a later point, the allocator is reset. This can be used for per-frame allocations, with the allocator automatically reusing the same memory every for every frame, with no need to manually free it. In my initial test case, this is used for the room data. When you enter a room, it starts populating it, and this is then all allocated from the room alloctor. When you change room, this allocator is flushed, and the new room can start fresh. On debug builds, each allocation is prefixed with some metadata including the source file and line number and size, so allocations can be tracked. In release builds, nothing is stored. In release builds freeing results in basically a NOP, while in debug it does mark it as being freed, so when the allocator is finally flushed, some information about how much memory had been previously cleaned could be provided.

The next allocator is a stack allocator. This requires all deallocations to be made in the reverse order as the allocations. Debug builds will check for this and can assert if this is not the case. This is currently in use just for UI, where opening and closing UI elements can follow this pattern. Like the arena allocator, this will store some additional information about the allocation in debug builds in front of the allocation, however in release builds it will just push the stack back to the element that has just been popped off. As long as the logic doesn't change between debug and release (it shouldn't!) this is fine.

Finally, a fixed size allocator. The intention for this is that it acts like an pool of objects. There are currently two in use, one for the character objects, and one for sprites. No additional information is stored about each allocation, and unlike the other allocators, there are very few differences between debug and release builds. This functions by defining a bitmap at the beginning of the allocator. This is one bit per element. It acts as a flag to show which elements have been allocated, and which are free. 1 is defined as being available, and the bitmap is set to 0xFF. This means that I can step through the bitmap in bytes, checking if any are non-zero, before looking at exactly which bit, and therefore which element, is able to be allocated.

The only thing remaining to allow full control over memory is the system allocations. Using libraries by theRemovers meant that a few of the things used malloc or calloc internally. It was fairly trivial to create my own functions for these which just passed to a stack allocator. A couple of the libraries needed to be slightly rewritten to ensure deallocating in the correct order. This then meant that every dynamic allocation in the game would run through one of these allocators.

I put these at the bottom of RAM, from 0x1000, and defining the size of each, meaning that they automagically laid themselves out in memory. I could then write a simple printer, which would interrogate the allocator's current state, and let me know how much memory I am using. I have sized the allocators to being "sensible" for now, which means I have a bit of headroom over what I'm currently using. These allocators are using roughly 700kb of memory. To modern eyes, that's a tiny amount, but keep in mind that I have only 2MB to play with. The intention is therefore to keep the bottom 1MB for dynamic allocations, and use the top 1MB for things I can manage more directly, such as for example the current music track being played. This is not totally accurate, as the stack also grows down from the 2MB mark, but I'm checking that it doesn't grow above 64KB, so I can still use the majority of the top 1MB for these allocations.

Still to be added is adding a pattern to the last few bytes of the allocator (0xDEADBEEF, 0xCDCDCDCD etc) and then check that this remains intact in debug builds, whenever an alloc or free is called on that allocator, to ensure that nothing overwrites them. Also, once the game has game states, any error in the allocators in release should push a debug error state, probably styled after a Windows BSoD.

The allocators haven't improved the game, they haven't added any gameplay features, they feel very much like busy work or perhaps yak shaving. However they are making me more confident about my ability to make an actual game going forward, now that I can be more in control, and more aware of memory usage.

I am going to have to draw up physical memory maps to ensure I know what memory is going where.

Having said that, I'm not a streamer. I have no intention of being a streamer. By which I mean, I pretty much just hit go on OBS. The layout I had until recently was just a facecam, and a couple of window captures. I really don't want to try harder.

But then I had an idea.

Now, don't get me wrong, this is a stupid idea. But it did allow me to add some "polish" to my streaming.

I would create an overlay… which would run on the Jaguar (or, at least, in an emulator)

At this point, the tooling was already at a point where I thought I could do this relatively quickly. It just needed me to decide on a layout. So I threw ones together based roughly on the theme for this site, and set about creating a layout scene in the game.

This taught me a lot about how the game was working, how the tools were working, and the shortcomings. For one thing, all of the rooms, spritesheet etc to that point had been created based off a handwritten seed file. I had begun the spritesheet json file by hand, and it had grown manually before I wrote the tooling. Trying to make a new setup from scratch uncovered bugs that I wasn't aware of, and hardcoded assumptions that were just not valid.

The scene itself is pretty straightforward. Background tiles, then a border around each of the elements, and a green box that OBS can then use to colour key and display thing inside of. One thing I hadn't thought of, but was a nice addition, was that the player sprite spawns and just hangs around.

Of course, I could have created all of this very easily with a static image in GIMP, with a little animated gif. Right now there's no functionality. And any functionality I do add could also be done outside of a Jaguar. I am definitely not denying that. But this was a fun aside, and I am much more enthused about this overlay than I would be if it were made any other way.

As for the additional functionality, I have already added one-directional "UART" to VirtualJaguar - granted, it's not actual UART support, but it is enough for me to have implemented output to stdout in my game, which has helped debugging significantly. If I make this proper bidirectional UART, then I could then pass information back to the game, and I could make it react to things. The first thing would be to add chat support - I have already written an IRC bot which works on Twitch. I could fairly easily get it to forward all messages to VirtualJaguar's UART, and then have the chat be rendered by the game. I could also at that point also parse the chat messages and get the game to respond. At this point I don't have anything functional that the game could do, but I'm sure I can figure out some fun things.

I do also intend to stream to other services… I just haven't set that up yet.

Attempting to run the game, however, led to a realisation. The game was slow. There was nothing happening in "the game" at this point, so it had to be the room setup. This has basically changed the next few goals for the project to: profiling and optimisation.

There are two possible options for what might have been the problem here. The first is that it is simply just too many objects, and Tom is stuggling. The other is bus contention Tom and the Motorola 68000 CPU both use the same bus, and if one is accessing data, then the other cannot use it. This means that memory access from one chip can throttle the other.

Thankfully, both of these have solutions which were already planned. I'm still going to investigate, because in part this will give me a better understanding of the hardware, but also, in doing so, I will build up some tools that will help me debug down the road. Building them now when I have a relatively small test case will mean that it should be fairly easy, and they can be improved and refined over time.

If we have a bus contention problem, then the solution is for the GPU to request less data from RAM/ROM and request it only when the CPU doesn't need the bus. Currently the images are stored as 16-bit CRY images. The intention was always to replace them with indexed images. This would not only reduce the size of the image data significantly, but would also allow for some cool image effects. Switching to an indexed image might save as much as 75% of the space (16-bit to 4-bit per pixel) meaning that Tom has to request that much less data.

If, on the other hand, the issue is just the amount of objects that Tom has to process, then the solution is to provide far fewer objects. Initially, prior to the spritesheet setup, the game used a single large image as the background - this had several drawbacks, but the primary one was size - each room required a lot of unique data. The ROM for the game, with just the Peregrine rooms (and no actual game) was already 1.4MB. As the hope is that the game is much, much bigger than that, and the absolute maximum size ROM is 6MB, then that obviously wasn't feasible. Instead, the plan is to bake the sprites into a single (or a few) large object at runtime. This way the ROM can maintain its smaller size, and the game maintains its performance, at the cost of a little pause when the room is loaded in.

I am using "sprite" and "object" interchangeably here - they are pretty much the same thing.

This is perhaps the point where the game will start turning from a quick prototype, with some proof of concept systems, into a game system that can actually produce a working game in the end.

I won't lie, I had hoped to push this can down the road a little bit, so I could at least start making a "vertical slice" scene first. On the other hand, it will be good to tidy up some of the code, and get to know the system better.

Edit: After some quick profiling the next day, it turns out that the issue was actually CPU-side, in the room-scrolling code. I did not think this would be particularly expensive as it "just" adds an offset to the objects, but I guess if this done every frame for ~150 objects, it can cause problems. The solution is still the same: batch the objects together into a larger object. Also perhaps not recalculate the objects if the room hasn't moved…

∗ © 1992, 1993 ATARI Corp

I love coding, I love the problem solving associated with that. I do not love mindlessly entering pixel coordinates into a text file. Sure, sometimes manually hard coded setups are necessary, and they definitely help in designing new systems, to have some data before committing to tooling.

But after a certain point, you really need tooling.

As has already been mentioned before, I started writing an editor to handle doing the room layout. But how to define the sprites/objects that the editor could use? How should all of this be packaged into something that the game can actually use?

At the end of the previous post, I described a spritesheet cutter, that took the spritesheet json file and created the relevant assembly files to link in with the game. Additional to this a very small application was written to act as a frontend for the tooling, which would list all of the rooms able to be edited, as buttons, and would load the room editor with that one when clicked. It would also run the spritesheet cutter, and it could run the game directly from it - although in this case, because the data files are compiled into the executable, it actually rebuilt the game.

The next thing would be to actually define the sprites.

A quick tool dev time later (2 streams, ~4 hours total) and I have this quick and dirty editor. It shows the locations of the sprites in the json file, allows you to move, resize, and label the sprites. It even allows for creating animated sprites, although there's no way to view them right now, so it's a bit clunky. Upon saving, not only does it save the json file, but it also calls the cutter application, so that the game is automatically provided with the latest sprite data.

One thing I was considering when starting to develop these tools was: Should I make a mega-tool, or separate small ones. I went for the latter option, even if it might be a bit non-standard (when compared to modern game engines) because it would allow me to work on small functional tools, and develop them relatively quickly, without having to care too much about architecting it so that the mega-tool can be extensible. It doesn't need to be an extensible tool. It needs to do its job, and other tools do their job.

Overall, this means that, to create a room layout, you can now load the editor, open the sprite editor, define some new sprites, save that out, then drop back and select the room I'm working on, place the new sprites, save, drop back out, and hit play to test it in game.

This has dropped my room layout iteration time significantly. The only improvement that could be made would be, being able to define these in the game itself… I'm just not really sure how I could get the data back out of the game…

Right now, the sprite sheet editor only works for backgrounds. As with all the tools, it has some hardcoded values, to reduce the scope, but these can be "easily" changed, so that I should be able to use the spritesheet editor to also handle character spritesheets. Also, adding an animation viewer would probably be a good idea, as would be creating composite sprites, to define single objects out of multiple sprites. After that, a separate tool to set up the states for characters, using this sprite data, is a probably a fairly trivial thing to add.

But first, let's lay out some rooms.

So, let's introduce the crew.

The Player

Formerly of the Argon Navy, and now a civilian merchant captain, the Player commands a Mercury-class freighter out of Argon Prime.

Kade Renner

An Argon Navy veteran like his childhood friend, Kade is the crew's steady hand and often a calming influence when things get heated.

Letaseos Yayasisos Neserosius IX "Leta"

Known to the crew as Leta, Letaseos Yayasisos Neserosius IX joined the crew to broaden her knowledge of the universe. Her seemingly endless optimism solves problems where her skills lack.

Elriya "El" Maclan

El is the ace pilot. Not only can she fly the ship places that nobody else can, in ways nobody else can, sometimes she even means to do it!

Emoro Ti

Emoro Ti joined the crew as a hitchhiker, but stayed on to help the crew when they need her. She is medic, counsellor, and general busy-body around the ship.

Ilona Rael

Cynical and sharp-witted, Ilona's former Terran intelligence work helps the crew get out of, and into, tough situations.

Torr t'Vnk

A former pirate, Torr provides necessary muscle when it is needed and is often considered to be as blunt as a a hammer, but in some conflicts, a hammer is exactly what you need.

Character sprites have been created by Kalengo Phiri on Fiverr.

Setting expectations - there's very little there.

I have a habit of getting distracted by tech, architecture, tooling, and boilerplate code, and not making any actual progress on what I want to. This is still very much the case here, but I am approaching it in a way - with my eyes open as it were.

There are a number of ways I'm addressing this. To begin with, I am trying my best to strike a balance between prototype code, and software architecture. The code itself is not particularly great, it's fairly sloppily written, with the purpose of making visible progress, but the way it's being put together is hopefully sound. The reason behind this is, I intend to rewrite significant chunks of the functionality in assembler. I do not want to do so now, as it will grind actual productivity to a halt. I am trying to get the broad strokes in place though.

Also, I've broken the game itself into several core gameplay styles. I am tackling one of those, and intending to write vertical slice of each of these, without worrying too much about the project combining into a single coherent game. So right now I'm working on the story aspect, a kind of narrative/dialogue heavy adventure game section. Perhaps not the most riveting gameplay, but the part that interests me right now. I have one scene which I will get working, before I move onto the next vertical slice.

This also helps with breaking down the amount of content I need to obtain. I am not building the game chronologically, so I don't need all of the artwork required to get me from one point to the next. When I have the gameplay features all working, then I will do it that way, and stitch gameplay together.

Something that is new to me, is writing down story. I am not a writer, but I love stories. I have come up with many narratives for games and other projects in the past, but this is the first time I've made a conscious effort to document it.

So. I've still been very vague about everything.

This project started off out of the ashes of me trying to make a demake of X4: Foundations. But the intial idea this time around was to create a Metroidvania, set in the X Universe. The scope has shifted a little, and grown a lot. Due to a lack of emphasis on individual combat in the X Universe, and little latitude for expressive attacks, what combat I will be adding will be somewhat more stripped back. Additionally, while I will be doing my best to add in exploration with unlocks, how much of that makes sense within this, I am not sure yet. I do have some ideas.

As I've already stated, I'm also leaning more heavily into narrative and dialogue based gameplay, and some of the gameplay may more closely resemble an adventure game.

Additionally, if I have time, I would love to add some spaceship shmup sections.

I believe that I have a decent development set up for this. I am currently providing all the programming for engine, gameplay, and tooling, and I am in contact with several artists who are providing their assistance with this project.

So. That's all been vague replies and hand waving. What do I actually have? I have one location, a Teladi Peregrine, which I have taken some liberties, and defined several rooms: the bridge, crew quarters, a brig, an engine room, and an airlock. I got some sprites created by an artist I found on Discord, Wolfie. I have started getting some character designs done by an artist from Fiverr, Kalengo Phiri, and I've written a simple platforming system. You can run between the rooms, talk to your Teladi machanic, Letaseos "Leta" Yayasisos Neserosius IX, you can then run back to the bridge to have a chat with your pilot, Elriya "El" Maclan (I swear not all of the characters have nicknames) and she'll start you flying off. Not all that much gameplay, but it demonstrates a good number of systems working in concert.

Additionally, I have been making a point of trying to make some of the things data driven, so that as much as possible can be created with editors, and not require manual code editing. Dialogue trees, character definitions, and story states currently do not have their own editor, but they might do in future.

At this point, I have done very little testing on an actual Atari Jaguar. I did try it once, the performance was low, and there were graphical glitches, which seemed to be worse ones than what I had seen in either VirtualJaguar, or BigPEmu. The performance is something that, as already stated, is known and will be addressed. The graphical gitches are very much on my todo list.

Rather than do that, I decided to spend more time, writing my own editor.

I didn't just jump in and decide to write brand new tooling for everything, of course not. I did take a look at what was available. There are tools like Tiled which provide a lot of functionality out of the box, I would have just had to write a converter to put the data into the header format I was using.

The problem is, Tiled does a lot of things that I don't need, and on top of that, it does a lot of things I don't want. The latter is more problematic. One reason is that it is, as its name implies, a tile editor. My sprites (objects) aren't nicely aligned to a tile grid. I could not find a clean way to use Tiled in such a way that would make this possible. This is what I have found in a number of situations - sometimes when you have a very specific problem, using a generic tool can cause you to spend more time, than just writing a very specific solution yourself.

Is my editor perfect? No of course not. THe user input is awkward and esoteric, just me sticking functions on any free keys at the time (there is… sort of… a reason for this) but it doesn't matter. It is functional.

The code is hideous. It is not something I wish to share with anyone, but that's fine, it needs to do this one task.

It is a modal editor, where you can choose between creating collision objects (green boxes) trigger volumes (the same, but blue) or place objects in the scene.

It loads the spritesheet information from a json file

{
    "source": "data/peregrine_spritesheet.tga",
    "objects": [
        {
            "name": "OBJ_SCREEN",
            "animate" : true,
            "frames" : [
                { "x":  66, "y": 1,  "w": 24, "h": 19, "t": 30 },
                { "x":  99, "y": 1,  "w": 24, "h": 19, "t": 40 },
                { "x":  2,  "y": 35, "w": 24, "h": 19, "t": 50 }
            ]
        },
        { "name": "OBJ_CONTROLPANEL", "x": 297, "y": 34, "w": 48, "h": 27 },
        { "name": "OBJ_CHAIR", "x": 322, "y": 2, "w": 20, "h": 30 },
        { "name": "OBJ_DOORWAY_TOP", "x": 298, "y": 256, "w": 24, "h": 32 },
        { "name": "OBJ_DOORWAY_BOTTOM", "x": 234, "y": 288, "w": 24, "h": 32 },
        { "name": "OBJ_CEILING_1", "x": 231, "y": 241, "w": 20, "h": 15 }
    ]
}

It can use any of these object types to position in the room anywhere. It also uses json for its own save state

{
        "sprites":      [{
                        "type": "OBJ_SCREEN",
                        "x":    89,
                        "y":    122
                }, {
                        "type": "OBJ_SCREEN",
                        "x":    135,
                        "y":    122
                }, {
                        "type": "OBJ_SCREEN",
                        "x":    112,
                        "y":    111
                }, {
                        "type": "OBJ_CHAIR",
                        "x":    208,
                        "y":    162
                }, {
                        "type": "OBJ_CONTROLPANEL",
                        "x":    101,
                        "y":    132
                }, {
                        "type": "OBJ_DOORWAY_TOP",
                        "x":    -5,
                        "y":    132
                }, {
                        "type": "OBJ_DOORWAY_BOTTOM",
                        "x":    -5,
                        "y":    164
                }],
        "collision":    [{
                        "x":    158,
                        "y":    204,
                        "w":    318,
                        "h":    10
                }, {
                        "x":    311,
                        "y":    132,
                        "w":    12,
                        "h":    147
                }],
        "transition":   [{
                        "x":    2,
                        "y":    150,
                        "w":    4,
                        "h":    100,
                        "id":   0
                }]
}

But will output the header file in the format I previously specified alongside the json file

#ifndef __peregrine_bridge_H__
#define __peregrine_bridge_H__
extern phrase peregrine_bridge_gfx asm("peregrine_bridge_gfx");
objectdef peregrine_bridge_objects[] = {
        {OBJ_SCREEN, 101, 143, 8, 0},
        {OBJ_SCREEN, 147, 143, 8, 0},
        {OBJ_SCREEN, 124, 154, 8, 0},
        {OBJ_CHAIR, 218, 92, 8, 0},
        {OBJ_CONTROLPANEL, 125, 125, 8, 0},
        {OBJ_DOORWAY_TOP, 7, 120, 8, 0},
        {OBJ_DOORWAY_BOTTOM, 7, 88, 8, 0},
        {OBJ_INVISIBLE, 158, 75, 8, 591},
        {OBJ_INVISIBLE, 311, 79, 8, 9219},
};
transitiondef peregrine_bridge_transitions[] = {
        {TRANSITION_LEFT, ROOM_PEREGRINE_CREWQUARTERS, 2, 134, 4, 100},
};
roomdef peregrine_bridge = {
        .background_gfx = &peregrine_bridge_gfx,
        .w = 372,
        .h = 288,
        .numobjs = 9,
        .objects = peregrine_bridge_objects,
        .numtransitions = 1,
        .transitions = peregrine_bridge_transitions,
};
#endif/*__peregrine_bridge_H__*/  

At this time, some of the fields are hardcoded for the bridge.

Additional to that, another tool was created, x4ssc, which was just a quick spritesheet cutter. It was a wrapper around tga2cry, but read in the same spritesheet json file as above, and used it to generate the cry formatted images, as well as game headers.

#ifndef __PEREGRINE_SPRITESHEET_H__
#define __PEREGRINE_SPRITESHEET_H__

#define PEREGRINE_SPRITESHEET   \
        OBJECT(SCREEN, 24, 19, screen_1_gfx, 3, anim_screen)    \
        OBJECT(CONTROLPANEL, 48, 27, controlpanel_gfx, 1, 0)    \
        OBJECT(CHAIR, 20, 30, chair_gfx, 1, 0)  \
        OBJECT(DOORWAY_TOP, 24, 32, doorway_top_gfx, 1, 0)      \
        OBJECT(DOORWAY_BOTTOM, 24, 32, doorway_bottom_gfx, 1, 0)        \
        OBJECT(CEILING_1, 20, 15, ceiling_1_gfx, 1, 0)

#ifndef EDITOR
extern phrase screen_1_gfx asm("screen_1");
extern phrase screen_2_gfx asm("screen_2");
extern phrase screen_3_gfx asm("screen_3");
extern phrase controlpanel_gfx asm("controlpanel");
extern phrase chair_gfx asm("chair");
extern phrase doorway_top_gfx asm("doorway_top");
extern phrase doorway_bottom_gfx asm("doorway_bottom");
extern phrase ceiling_1_gfx asm("ceiling_1");


animation_chunk anim_screen[4] = {
        {.data = &screen_1_gfx, .speed = 30},
        {.data = &screen_2_gfx, .speed = 40},
        {.data = &screen_3_gfx, .speed = 50},
        {.data = 0}
};


#endif/*EDITOR*/
#endif/*__PEREGRINE_SPRITESHEET_H__*/

This could have been done several ways, including just manually hardcoding the headers, rather than using json, which isn't period appropriate, but this felt like the easiest way to get the data I wanted.

In game, I could debug the positioning of these, by implementing a 'debug mode' which would render a pink box over each object. This can be enabled while holding down the 3 key on the controller. More functionality needs to be added to the tooling surrounding this game's development, but hopefully this can be added slowly over time. It should be enough to start doing some proper layout now.

So I created a map view. I did more boilerplate stuff than I really should have, I created a localisation system, a way to create different SKUs, to match the game, with its DLCs. I added a basic setup for every ship in the base game, and a number of them in the DLCs.

But it still had no gameplay.

The goal for me, for this project, was never to remake X4 for the Atari Jaguar. That would never work. The game does so many calculations to maintain a live universe that a modern CPU struggles with it, let along a Motorolla 68000 from the mid-90s (and underpowered even then)

The goal was to make a game which, superficially, felt like X4. One that would give the feeling of playing X4, as if it were made in the mid-90s.

For this reason, there would be no live economy, and supply and demand would be pre-set, NPC ships would fly on pre-decided flight paths, The depth of the game would be faked. If it felt like X4 for an hour of gameplay, then that would have been considered a success.

That's where it fell apart however. X4 is a VAST game, not just in terms of the size of the universe, but in terms of scope. There are so many features to the game, and most of them you could not remove without sacrificing something that makes X4 itself. The project got into a spiral, in large part because I couldn't reconcile the fact that it would just end up being a joke (by design) with the amount of effort it was going to take. This, ultimately, was what caused me to drop it for a few months, and come back with the new design.

Before I abandonned this version of the game though, one more burst of inspiration came. It also ended up being the final nail in this iteration's coffin.

One of the X4 community members, Devil_D, posted images of some low-poly versions of X4 spaceships they'd made, using PicoCAD. One of the things I really wanted to do with the Jaguar, was experiment with Tom, one of the Jaguar's custom chips, which for simplicity's sake, we'll just call a programmable GPU (it's not, so nobody hate me for that…) The only problem was, the game up to that point had been writing in JagStudio, a slightly more modern, user-friendlier toolchain to develop for the Jaguar. It provided a lot of features, but it didn't give any access to Tom. The other alternative was to use Jaguar SDK, which I believe is based on the originally released Atari toolchain. This doesn't provide anywhere near as many QoL features, but gives pretty much full access to do whatever you want. So I started working on a 3D prototype.

The 3D work both re-motivated me, but at the same time was the thing that finally put this iteration to rest.

I reused a previous model-converter utility I had written as the basis of one to convert the model into something the Jaguar could understand, and used the Jaguar SDK 3D demo to get it rendering. It was great… and was running at 12fps, rendering 200ish polugons. There are certainly optimisations that could be done to this, so this wasn't me despairing that it wouldn't be possible. I had, however, hoped that I could get something running quickly, throw some UI on it, and be inspired to create something. Instead, I just felt overwhelmed by how much I had to do to get anything working there, and, like I said, was not sure that the work would be worth it.

I have learned a lot from this though, and am taking it forward to the new incarnation. I do definitely still intend to attempt to try some Tom coding, and even sprinkle in a bit of 3D, but I just want to spend time making a game first.

So, the story of the demake ends here. But the Jaguar development continues.

But what is it?

The short version is, a narrative driven Metroidvania.

But what is it?

Honestly, I don't know if I'm going to be able to pull off a Metroidvania, I'm more a story than gameplay kinda guy, but I'll do what I can. I have some ideas for scope creep\,^W\,^W additional gameplay features I would like to add.

But what is it?

A game, set in the X-Universe, written for a retro console. Which console? Well the Atari Jaguar of course.

I've had questions why I chose the Jaguar, and why I didn't just make it in a retro style on a modern PC. There are a couple of reasons for this, but the primary one is, I enjoy the limitations that older systems place on us, and the Jaguar is just on the edge of this I think, where the limitations can make for an enjoyable experience on its own. Plus I like the idea of using more difficult/niche hardware. I like the Jaguar. It ticks a lot of boxes for me. It also has the fact that, if I manage to complete the game, then I will be able to get a physical release, not something that I could really do with PS1.

The game is being developed largely on PC with two different emulators, BigPEmu, and VirtualJaguar. It should run with the standard setup on either emulator. VirtualJaguar RX is published under GPLv3, which means that the game could even be distributed with the emulator bundled together, in a manner similar to how games are bundled with DosBOX.

So, now let's skip back to what I was talking about before. The game itself. I said that I want to make a Metroidvania, and that is certainly true. I enjoy a lot of the features that make up a Metroidvania. I cannot really get the all-action style of a Metroidvania to fit with the X-Universe however. So I guess I might be aiming for a Metroidvania-lite. I want to have sections that you came unlock later with new abilities, and I want secrets, and I do want some combat/action in the Metroidvania style. But I am also a massive fan of adventure games, and specifically ones that are more narrative-heavy, rather than necessarily focusing everything on puzzle solving.

So I guess a description of what I want is a platforming game, with massive, unlockable sections, replayability, story, NPC dialogue, combat… oh, and a shmup… I guess I'll come back to that in a bit.

I have a game design in mind and partially documented, but it is very much subject to change based on whim, limitations, the phase of the moon, or inspiration. How I mainly see this going is a bit of a slower paced 2D platformer. The majority of the minute-to-minute gameplay will be walking around, talking to NPCs, progressing narrative, even some trading. There will be combat sections, which are currently intended to be using the same systems, so should feel integrated with the normal gameplay. They will hopefully also be somewhat open-ended, so if you particularly enjoy that, then you could spend more time doing this.

So, I mentioned a shmup… well, the X-Universe has spaceships. I feel like I kind of have to have some kind of spaceship flight in it. This is currently very much a wish-list feature and, while it is involved in a few story beats, it wouldn't hurt too much if it were dropped. If I can though, you'll be able to fly your Teladi Peregrine around, shooting down Xenon that come flying at you. Like the personal combat, this will also be mostly an optional side thing that you can continue doing if it's something you enjoy.

This is a lot for one dude to make in his free time. While I've never been diagnosed with ADHD or anything similar, I do have a habit of being distracted by other projects, so completing any significant portion of this is a pretty major undertaking. I am tackling this in a few ways, the first is that I'm working on a few features that I'm interested in (notably the dialogue/story systems), and secondly I'm streaming the development on Twitch. This seems to give me more motivation to keep on rolling.

There's a long road ahead, but nothing about the X-Universe is quick and easy.