It’s been a little over a year now since I started work on Another Star 2. While I haven’t been working on the game all during that time, it has been dreadfully slow going and I have very little to show for all the work I’ve poured in thus far. Part of the problem can be traced to my tendency to overthink things, but the largest hindrance has been the way the game was being developed. I really wanted a game that was true to the era, but in doing so I broke the project’s own prime directive: Another Star 2 is not actually an 8-bit game.

Granted, there was something enjoyable about the way I was originally going about it. Other than the actual game code, everything was packed together in a “ROM” file. You could even open it up in a ROM editor like YY-CHR to see the raw tile data. But I was trying a little too hard to make a ROM and not enough time making a game. Some graphics were be compressed while others weren’t, depending on whether they needed to be streamed or could be preloaded. The animation system for party members in battle was completely different from the one used for enemies, and both were nothing like the one used for character sprites in the field! Yes, this was how devs fit games on cartridges back in the day, but every time I wanted to add something new I was programming it from scratch simply to pretend I was making a game in the late 1980s.

After coming back to the project recently following a several month absence, I realized that I was holding myself back and decided to do what I should have done from the beginning: work on a game, not on a pretend pseudo-emulator. This meant chunking the entire original code base, and all the nice tools I’d made for the game thus far (although a good chunk of the code is being salvaged, so I’m not starting over entirely from scratch). After a few weeks of work, I’m roughly back to where I was before.

Still, I wanted the game to be able to play around with cool 8-bit era toys like palette swapping, which isn’t really a thing on modern hardware. Thankfully, modern hardware has something else that old systems didn’t have: programmable shaders.

Here is how the display device “sees” Another Star 2:

But the player never sees this. The game continually updates a look-up texture containing a number of unique sixteen color palettes. Each sprite tells the shader which palette it wants to use, and then the shader can check the level of red in the input image and know right away which palette entry to replace it with. It ends up looking more like this:

The old ROM Architect tool I was making has been shelved, but I still needed something for converting images to a palette format and then animating them, so now I have the more boringly named As2Tool.

In this new incarnation of the engine, there’s no way to track or enforce little things like tile limits or streaming bandwidth. But maybe that’s not such a bad thing. I can concentrate on making the characters look good and animate fluidly instead of forcing everything into a box. That doesn’t mean I plan to deviate entirely from my original plan. This is still meant to be an ode to the late 8-bit era, so multi-layer parallax scrolling, partial opacity, and super-fluid animation are still off-limits.

This new approach also opens up the possibility of throwing in a couple of TurboGrafx CD or Sega CD style full-screen animated-pixel-art cut scenes. Yeah, the TurboGrafx 16 is supposed to be my speed limit, but I won’t get pulled over if I just go five miles over the limit… right?

It’s been a long time since I’ve posted a status update on this project. Sorry about that. I’ve been meaning to for quite awhile now, but life has been fickle lately. I’d also been working on another, shorter project that just didn’t pan out, so Another Star 2 has been on the back burner for a little while. Still, there’s quite a bit to cover.

The most recent thing I’d been working on is the battle system. This being an RPG, getting it in working order would be a huge leap forward on the project. You may remember one of the very first mock-up images I ever did of the game.

Here’s the battle background from that image, recreated in the engine:

Each battle background (or “arena”, as the game refers to it internally) is only allotted 54 total 8×8 pixel characters to work with, and they have to be arranged into 32 tiles that are 2×2 characters each, although there is some mirroring allowed. These tiles are then fitted into the final layout. In addition, each arena has a unique 10 color palette to work with (the other six colors are reserved for other things, like the window graphics).

But a battle background is just eye candy for the most part. The two most important things in an RPG battle are the enemies, and the party members, so that’s what I dove into next. Because I’m still trying to stay try to tile limitations for the most part, I decided to begin with the largest party member first to make sure they would fit.

I’ll be using the initial red design for the character, at least for now.

The party member graphics are a bit weird. Instead of being “sprites”, they’re actually made up of background tiles. There are 90 total 8×8 pixel characters in the background character table reserved for the party, and there are three party members at any one given time. Thus each one gets 30 characters, which are all streamed (and each party member is updated on different frames to simulate the fact there wouldn’t be enough CPU power or bandwidth to update all 90 tiles in one frame). They also get an additional four characters each in the form of sprites that can overlay the background, the idea being that weapons would be unique sprites and can be changed out depending on a party member’s equipment. And since the party is located beneath the battle arena and enemies on screen, that means I can do a palette change between scanlines and give each character their own unique half-palette of eight colors.

You’ll notice that this is getting a bit complex. And I’m not sure that’s a good thing…

When awaiting orders at the beginning of each round, the party members face the player. This was important to me, so that you can see their faces often. In the original Another Star, each character tended to be really samey. In this game, I really want each personality to shine and stand out on their own, both in the way they look and act in the story, and in the way they play in the game. Having their backs to the player all the time in battle makes them harder to connect with, I think.

Each party member is updated every six frames. That’s only 10 frames per second, but does emulate the graphics-limited look of the era. On the other hand it’s also a bit sluggish for things like this attack here.

Enemies, on the other hand, work a lot differently, and are actually much simpler. Almost all the sprite character table is free for use by enemies, but the party members would already be hogging all the bandwidth of the console with their streaming which means the enemies need to have all their graphics loaded into memory at all times. Still, bigger enemies can use up more room, and smaller, simpler enemies can use less, so long as all the enemies together in a given battle don’t go over the limit.

I began with the most basic, iconic enemy from the first game: a “weedgora”.

The original Another Star was pretty typical of the 8-bit era. You usually had big, colorful enemy graphics, but they didn’t move or animate to save on cartridge space. Another Star 2, on the other hand, has vibrant enemies that animate and can scurry about. Mr. Weedgora here, for example, shuffles from side to side while he idles.

Like party members, enemies also get a unique half-palette, but there can only be two half-palettes at a time so some enemies in a battle will have to share them (all other colors are used by the background and interface). I’m also toying with the idea of enemies having palette swaps that are only cosmetic. For example, our weedgora friend here might have bright green foliage in the bountiful grasslands, but on the dry steppes of the world his leaves might be a more subdued yellow, even though his stats have not changed. This could also make palette sharing between enemies more fluid and easier to work with.

So here we are, with the initial framework of a battle system in place. However, one of the last things I worked on was something I got stuck at, and I even knew I would get stuck at for some time. And that’s how it would look when the player goes to issue their orders for the round. The characters and enemies are already taking up so much of the character tables that there’s really not any room left for any other iconography. Here were two alternate styles I toyed with, using just text.

There’s too many options to fit on the screen at one time, so I need some way to let the player know that there’s more they can do, but both of these seem more messy than anything else. As it is, I’m really straining the limits of the original “rules” that I came up with. It’s looking like something might have to give. Either I need to change how party members and enemies work on-screen, or I need to go back and reconsider the limitations I came up with. Trying to do both will likely result in a much weaker game.

First off, a huge THANK YOU to everyone who has commented on the project thus far. I’m happy that you’re enjoying watching the game’s progress, and I hope that you’re looking forward to when it’s released, even though that’s still so far off.

Anyway, computer Role Playing games have changed a lot over the years, and to this day there still tends to be a rather large chasm between what defines “western” and “eastern” style RPGs. But despite all their differences—whether it be battle systems, character mechanics, or art styles—there’s always been one thing that virtually every RPG ever made has in common:

Text. Lots of text. Loads and loads of it.

For early RPGs, both on consoles and home computers, this was a bit of a problem. Today we can fit entire movies on our phones without a second thought, but just a few decades ago space was so limited that just finding the room for dialog was a major development hurdle in and of itself. The original Another Star emulated this by keeping character interactions short and to the point, often with intentionally stilted lines to recreate the feel of the era, even though the storyline as a whole contained an obscene amount of text compared to an actual 8-bit console game. Another Star’s text files combined together add up to over 400 kilobytes, which is larger than most NES carts. Even with some decent compression, there’s no way a game from that era would have as much text as Another Star.

Another Star 2 will likely have even more text than its predecessor. But I’d actually like to lean away from the original game’s dialog style and have the characters speak a little more naturally. However, I still want to keep the pace up, so don’t expect a visual novel. Persona this is not.

Like an actual 8-bit game, both Another Star and Another Star 2’s fonts require part of the character table. Here’s what Another Star 2’s font currently looks like, as seen in a debug overlay.

Notice that the font alone takes up almost half of the character table for the background, leaving fewer characters for actual map tiles. This was a very real problem that console games often ran in to. It’s part of the reason many games that only needed a little text would just make do with capital letters and not include any lower case ones. This is the solution that the original Another Star used to stick to its own 256 tile limit. 8-bit console RPGs of the era, which were usually made in Japan, couldn’t settle for this though, as they needed more than the English Latin alphabet’s mere 26 characters in order to manage a single set of kana.

Because Another Star 2 is allowed to change between tile sets at will, I don’t forsee this being too big of a problem. As seen in the mockups I’ve done, the area maps are more detailed than the original game, but they aren’t meant to look quite as advanced as, say, the late SNES games that most “classic style” pixel art game prefer to emulate, such as Seiken Densetsu 3, Final Fantasy 6, or Terranigma. If it does become a problem, I suppose I can always steal a “cheat” from some of the later NES games: they had a special chip on the cartridge that would let the game switch between character sets between scanlines. Some lines would display the map graphics, while others could display the text and interface. Granted, this was possible because the NES has no VRAM and thus all the graphics memory was on the carts themselves, but I’m sure I could cook up some excuse if I absolutely have to. (Or just admit that I would be cheating and live with it.)

You’ll notice in all the mockups I’ve done that character graphics tend to be quite prominent, most notably in the form of character portraits for dialog instead of the speaker’s name. I want players to be attached to the characters of this game, and it’s hard to make that attachment in such a visual medium as video games when all you have to go on is a name on a screen and an itty-bitty mash of pixels. Originally I intended the portraits to be static, but I wanted the characters to be very expressive in-game. Here’s what they look like right now in-game.

Having a flapping mouth and blinking eyes was very rare for the time, but a handful of games did use them. Still, note that not only does the mouth flap, but the entire jaw moves. It’s really fairly detailed for a little 32×48 pixel graphic. The room needed to store all the portrait graphics, their layouts, and their animation data is a bit much on its own, not to mention the fact the graphics have to be streamed to VRAM each frame in addition to everything that’s still going on with the map graphics. Not impossible, perhaps, but it borders on the implausible.

However, when deciding on whether to go this route or not, I had to remind myself of the first rule of Another Star 2: “Another Star 2 is not actually an 8-bit game.” I believe having animated portraits makes the game more engaging, and as long as they’re not over-animated I don’t see them clashing with the art style, so I erred on the side of inauthenticity for the sake of making a good game.

Anyway, as a bonus, here’s what the portrait look like when viewed in the current iteration of the screen shader.

It’s meant to look like the console is coming in through a cheap RF adapter, but better settings will be available in the final game. I plan for a high-quality option that emulates a computer CRT instead of a television. There will also probably be a few different screen shapes to let you customize how much of the picture is chopped off by overscan, and how round the display is.

Sometime early in the development of the original Another Star, I happened to think to myself, “I wonder how this would look on an actual tube television set.” So I decided to learn about how GPU shaders work and see how hard it would be to slap a good scanline filter on the game’s output. It was just a spur-of-the-moment thing that I didn’t think would go anywhere, but I was so impressed by the initial results that I ended up seeking out a high-quality CRT filter created for video game emulation and incorporated it into the game.

A lot of other games began implementing CRT filters around the time Another Star first came out in 2014, and many more have done so since, so it’s not quite as unique a feature as I’d hoped. But it did give the game the warm, nostalgic feeling of old-style console pixel art. Simulating old displays has come a long way from the time when developers would simply render every other row of pixels and call it a scanline effect. Today’s filters capture the actual look of actual displays by simulating the scanline’s brightness, making up for the dark areas between lines and preventing the picture from looking too dark or washed-out. The higher resolution of modern screens also help out.

Of course, it goes without saying that Another Star 2 will follow its predecessor’s footsteps and do its best to emulate playing the game on an old tube set early Saturday morning in your underwear before your parents get up. And, like Another Star, it’ll be fully optional for those whose system’s can’t handle it, and those who simply don’t want it. (You kids get off my lawn, now!)

It’s always interesting that the first thing people usually compliment me on when they first see Another Star is the screen shader. Which is always a little embarrassing because the screen shader is one of the few things that I didn’t make in the game. It’s a GPL licensed shader written in part by a trio of coders: cgwg, Themaister, and DOLLS. Yes, I rewrote small chunks to fit it into my own engine, and to tweak some of the effects, but it’s not really my work. This time around, I wanted to roll my own.

So, here it is, the first iteration of Another Star 2’s brand new screen filter. You’ll notice that it does away with the traditional horizontal scanlines more commonly seen on old computer and arcade displays and instead works to emulate the staggered, big-holed shadow masks of consumer television sets. This is more true to the game’s status as a “home console game”. It’s more noticeable when you zoom in for a closer look.

Currently, the shader doesn’t emulate the separate red, green, and blue rectangles that you’d see on a real tube-style television set. My early tests trying to accomplish this programmatically didn’t produce satisfactory results, so it’ll probably take a texture reference to pull off. But to be honest, I’m not even sure it’s completely needed. Zoomed out to the normal viewing distance, you wouldn’t see those anyway. I may decide it’s more processing power to no end and just not implement it.

You’ll also notice that it currently lacks the rounding of the television screen, which makes the vertical lines really noticeable and a bit distracting when resized for most of these screenshots. It looks much better in-game, though, and I think the slight rounding should mostly eliminate the artifacts at lower resolutions. Instead of calculating the screen’s shape in the shader like Another Star’s filter, I’ll probably take a page from J. Kyle Pittman and spread the game’s display across a 3d shape. This should result in much more efficient output than doing it in the shader anyway. I’d really like for the shader to be useable on lower-end laptops, something that’s mostly impossible with Another Star’s computation hog of a shader.

Another Star 2 is also implementing something that I could never quite get to work in the original Another Star, and that’s NTSC artifacts. When it came to color, NTSC was a horrible, horrible display standard that plagued us until the advent of HDTV. Running it through a low-quality connection like an RF cable made it look even worse by causing the colors to carelessly bleed into each other (even more than usual). It should be a real nostalgia trip for those of us old enough to recall it. Remember trying to fiddle with the television’s tint knob so that the colors looked right?

Thankfully, you’ll have some input into the output quality of the shader, so if you want to play with the screen shader enabled but want to minimize the NTSC artifacts and blurring, you’ll be able to do it from the game’s options menu.

And, of course, Another Star 2 is not actually an old game, so I don’t plan to rely on the screen effects as a crutch. They’re there to compliment the game’s style, not to stand in for or take the place of real gameplay. I have a lot of ideas on how to continue to innovate on the old RPG mechanics I first toyed with in Another Star. Hopefully you’ll agree when you get the chance to play through the game yourself.

And speaking of gameplay, I’ve got text boxes up and running!

Although the scripting systems aren’t in place yet, the game can detect when you interact with NPCs and opens this little dialog box for you. The actual scripting isn’t too far off now. I’ll probably discuss text and game localization next time, so stay tuned. (No pun intended.)

In the last dev log, I promised to show screenshots from the actual game engine instead of just mock-ups, and that’s exactly what I have in store for you today. Prepare to be amazed! Behold, the very first screenshot ever from Another Star 2:

Okay, so that’s not very impressive at all. But with some work, it eventually improved to this:

What you see above were the first steps towards getting the game’s graphics up and running by uncompressing the character graphics from the game’s data file and then sticking them in the nametable (tile map) to show up on the screen.

Another Star 2’s display works a lot like an emulator. Most of the work is actually done on the CPU. It renders out the display as a 280×262 pixel texture that contains the 256×224 display, plus the overscan that would be present in an actual signal sent to the television. The CPU is not particularly efficient at drawing things, which is why these days we have blazingly-fast parallel processor GPUs that can draw millions upon millions of polygons a second to enormous displays.

However, the visual effects I want to do in Another Star 2 harken back to older, tile-based display processors of the past. They worked quite differently than modern display processors, and because the game can change a lot of display parameters (including the palette and scrolling values) from row to row of pixels, it didn’t seem like it was worth the trouble to format and send a bunch of row information to the GPU every frame and then write a specialized shader to interpret it all. Moreso because it all needs to work on somewhat more limited OpenGL 2.1 hardware, to meet the game’s planned minimum specs. But since the game’s resolution is minuscule, the CPU can handle it fairly easily and relatively quickly anyway. Even in debug mode, on my system the game rarely reaches too far above using 30% of a dual core CPU, spread across two threads. In release mode, that number usually falls to less than 10%.

But enough technobabble, let’s put those characters together into tiles, and then build a map out of them! Yeah! This is going to be great!

Like a lot of the game’s graphics, the game’s maps are all compressed. In my first attempts, things didn’t go so well, as you can see. But with a little more work, I managed to actually work out all the kinks.

So, now we have working maps. That’s like half the battle right there. Just needed some NPCs to liven things up.

In this screenshot, I’ve included the entire game window to show the little tables on each side of the main screen. They show me what graphics are loaded at any given time, so they’re helpful for debugging. I’ll probably leave a way to pull them up somehow in the final version of the game for those who are interesting in seeing what the game is doing behind the scenes.

At this point in the screenshot collection we’ve caught up to about where I am now, where I have a playable character that can move around the map at will. Unlike the first game, movement is not completely limited to the grid. Pretty unusual for an 8-bit era RPG that wasn’t action-oriented, true, but I think it still stays true enough to the genre, and it makes getting around a little easier because you can move diagonally like a real person.

It’s starting to look like an actual game!

Virtually everything in Another Star but the map layouts and base graphics were hard coded directly into the game. For some things, like item stats, this wasn’t too bad so long as I kept the code organized. For others, like which graphics were used to build individual map tiles, it was an absolute pain whenever something small had to be changed, and usually required me to physically count offsets and coordinates to figure out what belonged where.

Since Another Star 2 is planned to do fun and weird things with palettes and tile layouts, I thought it best to spend some time up front getting a good selection of tools programmed that would help create the game more easily. Most of these tools take the form of a program called ROM Architect.

ROM Architect is programmed in C# and makes extension use of WinForms. This makes it pretty easy to throw things together and make them work without the rigid hassles of hooking them all up using C/C++ headers.

Let’s take a quick look at ROM Architect’s various components.

The palette editor is pretty straightforward. It lets you build and preview sixteen color palettes built from the game’s 8-bit BBGGGRRR color scheme. The palette at the bottom is a recreation of the original Another Star’s sole sixteen color palette.

The character library and character editor are used to build and manage the 8×8 pixel graphics that are used to build pretty much everything in Another Star. If I was using modern sprite sheets, this would not be necessary, but I thought it’d be more interesting to try and build everything faithfully to the system limitations of the time.

Of course, it’s pretty hard to build larger graphics while only able to focus on a single 8×8 pixel block at a time, which is why I implemented a copy & paste feature.

I can build everything in Photoshop, then select what I want to bring over using CTRL+C (well, CTRL+SHIFT+C, since I’m usually copying multiple layers). All I have to do then is recreate the palette in the editor, then paste to the character library. No exporting or importing of files required. ROM Architect will handle breaking everything up into 8×8 pixel chunks and do its best to match color values to fit the current palette. You can see the results above.

The character library even has an automated tool that I can select to then go through everything I just put in it to remove all the duplicates (including those that are flipped/mirrored, if I so choose). From there, I can make further reductions manually as needed.

Character layouts can be tested on the Workbench, which exists solely to let me mess around with graphics and see how they fit together without disturbing anything else.

In Another Star 2, all tile sets are 128 tiles in size. This was actually a pretty common tile set size up through the 16-bit era (it let you use the other 128 values of a byte as controllers to do map compression). The Tile Set Editor not only lets me lay the tile’s graphics out by placing characters from the library, but I can also change each tile’s properties.

Here’s the RLE Room Editor, which I use to build maps using the tiles created in the Tile Set Editor. RLE stands for run-length encoding, which is how free form RPG maps were typically stored back in the day. An alternative scheme, more popular in platformers, is to create larger “meta-tiles” from the smaller tiles, and then build the level from those to save space.

You’ll notice that the Room Editor lets me select the palette. Palettes are independent of tile sets so that I can get a little more mileage out of them by simply changing the color scheme.

Here’s how much space I can save on this map using Another Star 2’s own RLE compression scheme. Whoo hoo! I saved almost 400 bytes!

You’re probably tired of mock-ups and tools at this point, though, so I’ll end this here. Next week I’ll finally start showing actual stuff from the engine in its early state.

Don’t have a full dev log entry today, but I did do a couple additional mock-ups this week. Menu screens tend to be difficult to figure out, so I figured it best to go ahead and do some test layouts to figure out what all needs to be displayed, and how best to present it.

First up is the inventory screen. I wanted to actually show what items look like this time, instead of making do with simply displaying the items’ names.

Next is the character status screen. As you can see, I really wanted to make the character themselves stand out instead of just stuffing the screen with text. You might also notice that it toys with the idea of characters having innate elemental weaknesses and strengths just like enemies traditionally do, perhaps forcing the player to take that into account when composing their party for a dungeon. Unfortunately I couldn’t fit the character’s equipment and magic growth on the status screen like in the first game because of this, but I suppose that’s what the equipment screen et al are for.

In my last entry, I talked a little bit about the various 8-bit systems that made up the third generation of video game consoles. I also mentioned that I didn’t really want to recreate the experience of any one historical console, and instead wanted to capture a little bit of the feel and wonder of the 8-bit era as a whole. I wanted the ability to pick and choose what I thought were the best and most interesting attributes, and to use that to build a framework of “rules” that Another Star 2’s development would exist within. But how best to do that?

Presenting the Vision Game System…

First released in North America in 1986, the Vision Game System (VGS) initially retailed for $249.99 USD. It was powered by a custom 3.58 MHz VR-2 processor and packed 8KiB of system RAM, plus 20KiB of VRAM. The console was well-known for its bright graphics, expressive sprites, warm FM synth tones, and high-capacity game cards. While it never matched the behemoth of Nintendo in sales, it managed to maintain a comfortable, if distant, second place in most regions.

It also, of course, didn’t exist.

However, this was the system that I slowly began to piece together in my head during the development of the original Another Star to explain its own self-imposed limitations. Even after the completion of that game, I continued to chip away at the system’s design. I even have a whole page dedicated to its specifications that goes into its design in some detail.

Using this imaginary game console as a template, I can imply a set of limitations or “rules” to guide Another Star 2’s production. Some of these rules are more important than others. Some can be considered “just for fun”, while others are key to achieving the look and feel I want. Thus, going forward, it’s not just important to decide how best to work within these self-imposed limitations, it’s also important to know when to give in and decide to chunk them out the window for the greater good of the game.

RULE #1: Another Star 2 is not actually an 8-bit game.

The “Prime Directive” of Another Star 2. This may seem like an obvious observation, but it’s actually an easy trap to fall into.

Take this simple example: if the VGS were real and Another Star 2 was released on it, the game would have 16KiB of RAM at most to work with. That’s 8KiB of system RAM, plus another 8KiB of RAM on the game card, minus whatever of the game card’s RAM is taken up by persistent save game data. A traditional 256×256 tile world map alone would need at least 65,536 bytes just to store the tile data. That’s way more than 16KiB, and it’s also way too much ROM to take up uncompressed on the tiny cartridge of an 8-bit system. What you had to do back in the day was to compress the maps on the ROM and then have the game decompress only a portion of them into RAM at a time as the player moved around. This is what games like Final Fantasy and Dragon Quest did, and the purist in me wants to replicate this behavior.

But there is no absolutely no need to bother doing this on a modern system! We measure memory in gigabytes these days. Even the most meager Raspberry Pi has a good 256 megabytes of RAM. The entire finished game will probably fit into far less than that! Just decompress the entire map and keep it around as long as it’s needed.

I do want to be a little more authentic than the original Another Star was by avoiding things like straight-up floating point decimal math and such, but there’s no need to get carried away, especially with the things that nobody is ever going to see.

Which leads us right into the second rule…

RULE #2: Don’t do things just because old games did things that way.

Not so much a rule as a mantra, and one that was shared by the original Another Star.

A lot of games way back made frustrating and tedious design decisions. Some were side effects of system limitations, such as a bunch of enemies spawning just as you go to jump over a pit of instant-death spikes, causing the game to slow down and throw off your timing. (Yeah, Mega Man, I’m looking at you.) Others were carryovers from the arcade mentality of needing to eat up player’s quarters, such as sending you back multiple levels if you died at inopportune points, or placing save points hours apart.

It’s not just instances of “fake difficulty”, even. Interfaces could be frustrating to navigate, and often lacked vital information. Early console RPGs often came with big fold-out charts for equipment stats because that was the only way for players to figure out how strong something was and who could equip it.

It’s 2016 now. There have been decades of game design lessons learned by tedious trial and error over the course of tens of thousands of titles since the 8-bit era came to a close. There’s absolutely no reason to ignore all that knowledge. Making a game purposefully bad just so that it’s “authentic” still results in a bad game.

RULE #3: The game’s data can take up as much room as needed to make the game fun.

One of the things that made 8-bit games the way they were was not the graphics or the audio, but the fact that memory was so expensive! Even the largest NES games were less than a single megabyte in size. Atari 2600 games were almost all 4,096 bytes or smaller. That’s insane! This post alone almost certainly takes up more room on a server somewhere than a single Atari 2600 game! That steep cost of space made every byte precious. Programmers found ways to creatively compress graphics and text, and they reused as much as they could whenever possible. But this made it very easy to create a short, repetitive game, and development teams often found they had to cut out lots of cool stuff they’d already completed simply because there wasn’t any more room on the cartridge.

I’ve already had my fill of keeping things tiny in Another Star. With Another Star 2, I’d like more freedom to play around. I still plan to compress graphics, text, and map data for fun, but I’m not going to handicap the game simply because I’ve created something bigger than a real cartridge would have been able to handle. If I need to cut content for time or for to improve the game as a whole, so be it! But I’m not going to do so just to feel like I’m living in the past.

RULE #4: The display resolution is 256×224, padded to fit the “overscan”, and stretched to a 1.143 pixel aspect ratio.

Traditionally, consoles have been all over the place when it comes to resolution, and the third generation of consoles was no exception.

The original Another Star’s main display runs at 224 vertical pixels, but I don’t remember why exactly I went with that number. I may up Another Star 2’s vertical resolution to 240 like the NES, or I could just leave it at 224 like the SNES and Genesis / Mega Drive. Dropping down to the Master System’s 192 seems too low and wasteful (it leaves a lot of wasted horizontal space in PAL games), although it may be the number I meant to have gone with for the original Another Star considering it’s so heavily based on the Master System.

Horizontal resolution is a different beast. The beam that drew the old tube set displays moved left-to-right, so pixel width wasn’t so rigidly set in stone like the horizontal resolution. The Atari 2600 was a mere 160 pixels wide, which is why it has such ridiculously wide pixels. The NES and Master System were 256 pixels wide, since that was a nice power-of-two number and made the pixels’ width match their height pretty closely at an aspect ratio of 1.143. The Atari 7800 and Amstrad GX4000 had video modes that supported 320 horizontal pixels, which in NTSC results in virtually perfect square pixels, but this came at the cost of reduced color counts. I happen to like the 256 pixel look and its ever-so-slightly-non-square pixels, so that’s what I went with for the first game.

RULE #5: The frame rate will be 60 frames per second.

Before everything moved to high definition, NTSC and PAL were the major broadcasting standards. (There’s also the less prolific SECAM, which is sort of like PAL, but I’m going to ignore it for brevity’s sake.) NTSC runs at 59.94 frames per second (fps), while PAL runs at 50. Note that these values are approximate because of the fact they’re analog standards, so there’s all sorts of tolerances and other technical considerations to take into account. In fact some consoles run ever so slightly faster or slower than these figures. TASVideos even has a useful table giving the exact values to several decimal places for dozens of systems.

Since 59.94 fps is practically 60 fps, and since most modern computer displays have a refresh rate of 60Hz, we might as well round it up so that we’re not dropping a frame for no reason every now and then.

RULE #6: Color is provided by two palettes of sixteen colors each. Each color is 8-bit RGB in the form of BBGGGRRR with eight levels each for red and green, and four levels for blue.

Color was a pretty defining aspect of early 8-bit consoles. Or, I guess it would be more correct to say, the lack of color was a pretty defining aspect of early 8-bit consoles.

The NES probably had it the worst. Its graphics were limited to two bits per pixel, which meant that each pixel could only be one of four colors, and one of the colors had to either be the background color or transparency depending on whether it was a tile or a sprite. It had a really unique choice of colors, though. There were barely over fifty to choose from, but those colors have become a memorable part of the system’s legacy.

The Master System was more expressive, using four bits per pixel, and thus sixteen colors for a single sprite or tile. It had two palettes, one for the background tiles and one for sprites, although the background tiles could use the sprite palette if they wanted to (but not vice versa). The colors were 6-bit RGB with four levels each of red, green, and blue. This gave you 64 colors total to choose from, but the lack of precision meant they tended to be really saturated and it could be hard to make interesting color ramps.

The Amstrad GX4000 had a whopping 4,096 colors available since it had 12-bit RGB color. This was more than even the TurboGrafx-16 or the Sega Genesis (both 9-bit with 512 total colors). However, it also had only two palettes for a mere 32 colors available at any given time, so it rarely had much of a chance to leverage that range.

As for Another Star 2’s own number of simultaneous colors, I don’t want too many. Again, I’m not trying to make a 16-bit game. Another Star had a single 16 color palette, but I find the two palette limit of the Master System and GX4000 more interesting, and it lets the background have different colors and palette changes than the sprites.

For the original Another Star, when it came to deciding on the game’s sixteen colors I decided to draw on a completely different source than the consoles I’ve talked about so far. The modern-retro Uzebox console uses a somewhat rare 8-bit color scheme that I find interesting, where red and green are chosen using three bits, but blue is chosen using just two bits, giving 256 total color possibilities. This means that red and green have higher precision, giving the palette an interesting look since you can’t just take everything up or down one step together. As such, it results in some interesting color ramps at the cost of more precise grays. Overall it gives a nice choice of colors and fits the whole 8-bit motif pretty well, so naturally it’s carrying over to Another Star 2. I’ll probably let the background and sprites decide which palette they want to use without restriction, to allow for more flexibility.

Furthermore, I came up with the unique concept of “palette shifting”. This is an imaginary hardware function unique to the VGS that lets the game treat each 16 color palette sort of like two 8 color palettes by changing what pixel value picks what color in a palette, but with a shifted palette all 16 colors can still be used because the values would wrap. This would effectively give graphics using the palette shifting technique use of eight colors plus transparency instead of just seven, as they can stuff one extra color in the other half-palette’s unused transparency value.

RULE #7: Absolutely no transparency!

In the 8-bit era, either a pixel was opaque or it wasn’t. There was no inbetween. At most you could dither and hope that the blurry NTSC signal would make it look see-through, or depend on the “persistence of vision” optical illusion by switching a sprite on and off each frame.

RULE #8: All graphics are built from 8×8 pixel characters. There are two character tables, one for the background and one for sprites. Each table contains 256 of these characters.

This is straight out of the NES, except that the NES could choose which table was used by the background and which was used by the sprites, or just assign one to both. It could also change them mid-frame for additional effects that Another Star 2 won’t quite be capable of. A few later, more advanced NES cartridges even let games even use a third character table, usually for the font and GUI elements.

Another Star 2 can, however, stream new graphics to the tables each frame to make up for the limited number of characters, but only within reason. My rule of thumb is no more than 64 characters per frame if there’s not much else going on, or 32 per frame if there is. (I have a pretty spiffy estimation of how many CPU cycles it would take to do various types of VRAM streaming on the VGS specs page here). Like the Master System, the main characters will probably be streamed, while less important characters and objects will have to keep all their animation stored in the tables.

One trick the Master System did to stream more graphics at once was to animate different things on different frames. I’d like to do this as well, but if it’s too jarring to look at I may allow myself to break this particular limitation in the interest of the game not looking like total crap when in motion.

RULE #9: There may only be one background layer. However, the game can change display properties between lines to create mid-frame palette changes or simple parallax scrolling effects.

This is a major rule in my opinion. Most of the graphics that appear on screen on the NES and Master System are part of a grid called a tile map or “nametable”. Each entry in the nametable is a single 8×8 pixel character from the character table. One of the big advantages of 8-bit consoles over the early personal computers of the era was that the nametable could be scrolled. When scrolled “out-of-bounds” the nametable would wrap around on itself, letting you create seamless and seemingly endless levels by updating the area just outside the screen’s reach and then scrolling it into view.

One thing that really bugs me personally in modern 8-bit “retro” games (that you probably don’t care about, granted) is multi-layer parallax scrolling. For me, it betrays the aesthetic far too much. One of the defining characteristics of 8-bit consoles was that there was only ever one background layer, so everything had to move together. The TurboGrafx sometimes got around this because it had big sprites and could use them sort of like an extra layer (the Genesis liked to do this too), but Another Star 2 can’t pull this off within its own limitations (for reasons I’ll get into in a few rules down).

The only legitimate ways around this limitation was to either cleverly update tile patterns between frames (which only works if you have a small number of very simple patterns), or by scrolling different scanlines at slightly different speeds by changing the scrolling values mid-frame as the console draws to the television. When they were used, these techniques tend to create a very specific look, and I want to capture that look.

Another Star 2’s background layer will likely be 56 tiles wide and 32 tiles high, since at two bytes per tile this would let the tile map take up the remaining 20KiB of VRAM in the imaginary VGS that isn’t used by the character tables or the sprite attribute table (SAT).

RULE #10: The entire visible nametable cannot be changed between frames.

8-bit consoles were just fast enough to change the area outside the visible screen to support scrolling. To change everything on screen, you had to turn the display off for a few frames while the CPU changed all the nametable values.

The original Another Star played really loose with this, blanking the screen when moving between maps, but pulling up the status screen instantly. Like its predecessor, Another Star 2 will probably be pretty forgiving when it comes to this rule, but I will try to play it more straight.

RULE #11: Background tiles in Another Star 2 may appear above or below sprites. Sprites have a two-bit value that allows them to individually override this behavior by always appearing above or always appearing below the background.

The Master System allowed tiles to appear above or below sprites with a single bit flag. This is great until your sprite based HUD disappears behind tiles, giving away secret passages and obscuring your life counter. The NES was the other way around, letting you set sprites above or below the nametable using a single bit value for each sprite. I wanted the best of both worlds, so I cheated and melted the two together.

RULE #12: There may be up to 128 sprites on screen at once. These sprites may be either 8×8 or 8×16 pixels in size, but all of them must be the same size at any given time.

The NES and Master System were both limited to 64 sprites. Sprites could either be 8×8 pixels in size using a single character, or 8×16 pixels in size by stacking one character directly below the other and treating it as a single entity. This was set globally, mind you. You couldn’t mix 8×8 and 8×16 sprites on a screen. It was one way or the other. You couldn’t have your pixel cake and eat it too.

Of course, that’s not very many pixels to work with, and clearly those old systems had bigger characters on screen than that. Tachi will illustrate how they did it back in the day:

As you can see, Tachi is not actually a single sprite in the way we think of them, but rather a combination of multiple sprites that move together as one. Mind you, now that 64 sprite max is looking noticeably less roomy. In 8×8 mode, you can only have sixteen Tachis on screen at once. 8×16 allows for even more graphics on screen, of course, as Tachi could be then drawn with just two sprites instead of one, giving you far more possible Tachis. The biggest drawback then is that small things like bullets end up wasting a lot of space in the character tables with empty pixels.

RULE #13: Sprites and background tiles can be flipped horizontally or vertically, but they cannot be rotated.

Rotation didn’t really become a thing until the late 16-bit era. SNES games like Yoshi’s Island had an extra chip on the cartridge to help pull it off, and when Sonic does a loop-de-loop on the Genesis, his rotated sprites are in fact redraws instead of being able to utilize any hardware feature.

Flipping (also called mirroring), on the other hand, was very much a thing. It can come in really handy, too. See Tachi’s sprite above? The two halves of his head are the same 8×8 pixel character, just mirrored. Even the graphics used for his body are just swapped and flipped back and forth to make it look like he’s walking. 8-bit games did this all the time, and they got quite a lot of mileage out of it.

The NES could flip sprites but not background tiles, and the Master System could flip background tiles but not sprites. The VGS doesn’t take sides and can do both.

RULE #14: There can only be 16 sprites meant to be on one scanline at a time. But if there are more than 16, they do not have to flicker.

Above all else, The NES and Master System both had one crippling limitation when it came to sprites: there could only be eight sprites on a single row at once. Any more than that, and the extra ones just disappear. This is one of the primary causes of the flickering that was so endemic for 8-bit consoles. Early games on the NES and Master System were so simple this rarely was a major problem, but as the 8-bit era went on and games became more complex and sophisticated, it began to really rear its ugly head. You could alleviate the problem somewhat by changing the internal sprite order, so that which sprites disappear changes each frame (thus, flickering), but you couldn’t get rid of it altogether except by severely limiting the player and gameplay. By the end of the NES’s lifetime, you’ll notice that most developers basically just threw their hands up and began to ignore it.

I’ll admit I have more than a little nostalgia for sprite flickering. It was a pretty defining aspect of the era, after all. However, it’s not exactly appealing or desirable, and it really limits what you can do because you can’t line very many things up in a row.

While eight was the magic number for Sega and Nintendo, the Atari 7800 and Super Cassette Vision both let you have up to 30 sprites on a line depending on various conditions. Granted, the Super Cassette Vision’s sprites were only a single color, and the 7800 was more scanline-oriented than whole-frame-oriented (not to mention its MARIA graphics chip had a crippling processor load), but kicking the scanline limit up a bit doesn’t seem like too much of a pipe dream, even if it would have likely made the imaginary VGS’s display chip more expensive to produce. It is supposed to have come out after the NES and Master System, after all, so I say we can pretend technology advanced enough to make it a thing.

A higher sprite-per-line count is also necessary in order to make the battle setups in Another Star 2’s mock-ups work as shown. You can’t line up as many sprites as I’ve shown without increasing the limit somehow, or by making the enemies part of the background like in the majority of 8-bit RPGs. While the latter would be truer to the era, I do not wish to do it because I want Another Star 2’s enemies to be able to move around and animate freely. As such, even if really stretches the 8-bit aesthetic, I think in this case upping the limit might be for the better.

A sixteen sprite-per-line limit is also still low enough to keep the game from pushing too close to the Turbografx-16, which, as I said in my last dev log, is the game’s “speed limit”. Remember that I noted how the Turbografx-16 could use sprites as a second layer? A sixteen sprite-per-line limit would reasonably prevent Another Star 2 from doing that because then you can only get at most 128 pixels on a single scanline instead of the 256+ you’d need to fill up the entire row.

That said, I may eventually give way on this one and bump the limit up a little higher. We’ll just have to see what direction the game’s battle system goes.

RULE #15: Static images should be favored over fluid full screen animation for special scenes.

Again, this is playing into the game’s speed limit. The TurboGrafx-16’s CD add-on let developers play with fully animated full-screen pixel graphics, as did the Sega-CD that came after it. As much fun as that’d be, I’d be straining the aesthetic a little much. Even when NES and Master System games could afford the memory for lush cutscene art, they usually still had to stick with static scenes containing only minor (if any) animation. I should do the same even if I have an unlimited space budget for graphics storage, since I’m making a pretend cartridge game, not a pretend CD game.

RULE #16: The game’s audio consists of six channels total, with four FM synthesis channels and two noise channels. The tone and envelopes for all four FM synthesis channels can be customized independently.

Every sound chip had its own unique sound to it. The Commodore 64’s SID, the NES’s APU, and the Game Boy’s sound system each sounded a little different from each other, and all three are still prized for their music to this day. In Japan, the Master System had an additional audio chip built in compared with the rest of the world, and that chip was the Yamaha YM2413. Thus, instead of just having simple square and triangle waves like every other console of that generation, the Master System could use FM synthesis to create really neat and complex electronic tones. Being based so heavily on the Master System, the original Another Star used the YM2413 FM audio chip as the basis for its soundtrack instead of going with the traditional NES sound.

Being a child of the 80’s, I really like classic-style FM synthesis, and I think it’s far too underutilized these days compared with more traditional chip tunes. Since the soundtrack of Another Star was such a huge part of that game’s own style, it’s only natural I’d go with it again for the sequel. I’d also really like to have the game’s audio generated in real time instead of playing back .ogg files this time. That’d let me do neat tricks like change or alter instruments based on what’s going on on-screen. And since I’m doing custom pretend display hardware, I thought it’d be interesting to do custom pretend audio hardware too. A custom chip design gives me more leeway in how I choose to “emulate” it, since it doesn’t have to sound exactly like anything that actually exists.

However, while the six channel set up I’ve described would be a nice fit for an 8-bit aesthetic, I’m afraid it might be the one aspect of Another Star 2 to take a step back from the first game. The YM2413 had either nine FM channels, or six FM channels plus percussion sound. Most of Another Star’s soundtrack used the latter. That’s two more channels (and thus, two more musical notes at a time) than what Another Star 2 will be capable of if I stick with this rule, although my chip design allows for custom instruments on every channel instead of only having one custom instrument at a time. The soundtrack for Another Star is my pride and joy, so if Another Star 2 cannot at least match the first game, you can be sure I’ll start looking at alternate specifications for the audio. Maybe add a couple plain square wave channels, or even a 32-bit wavetable channel or two?

In any case, here’s an old concept demo of an FM synth I programmed in C# to give you an idea of what’s possible. I haven’t decided upon the exact specification of Another Star 2’s FM synth channels, but they’re likely going to end up fairly close to the YM2413.

RULE #17: One noise channel may play simple PCM samples instead.

The NES had a built-in channel for playing short sound samples which saw increasing use as the 8-bit era went on. It could even play the samples back at multiple frequencies, letting you output musical notes. Most games that used it had it play drum samples, which gave them a punchier beat. Super Mario Bros. 3 famously used it for a steel drum. Many games produced by Sunsoft actually used it to generate their bass line. It’d be fun to have that same freedom when it comes to composing the soundtrack.

The Master System, among others, could also play back PCM samples by manually toying with the frequency of the square waves of its sound chip to replicate more complex audio forms, but it required the rest of the system to basically stop everything while the CPU does nothing but play back sound. Not nearly as much fun.

RULE #18: Audio playback parameters, such as note changes and instrument settings, can only change in time with the display rate.

While the original Another Star sticks to the limits of the YM2413 chip itself, it breaks a lot of what would have been possible on the console controlling it. In reality, the tempos for old game music tends to be pretty fixed because there’s only one CPU and it has to manually update everything, and the only way to time stuff is to keep track of when the next TV frame needs to start being drawn. Furthermore, just because the YM2413 had nine FM channels, that didn’t necessarily mean that the console always had the time to play them all; more channels means that you need more ROM space to store music data. I didn’t take any of that into account, so Another Star likes to use all the FM channels all the time, and its track tempos are all over the place.

While Another Star 2’s audio will be handled by its own thread so that it doesn’t skip around whenever the game logic slips behind or ahead for whatever reason, it should more closely observe actual 8-bit limitations and pretend like it’s only updating itself in time with the display’s refresh rate.

RULE #19: The FM channels may use simple stereo panning.

This is one I have really mixed feelings about, and will probably backpedal on later. Not one console system in the third generation of video game consoles had stereo sound. That didn’t become a thing for consoles until the 16-bit era. However, stereo sound was present on the 8-bit Game Boy and Game Gear handheld systems when you used head phones. A single audio channel could be output either to the left or the right, or both at the same time.

Since the VGS supposedly came out in 1986, several years after the Famicom and Master System were initially developed, that would place it in the early days of the transition to stereo television. It’s somewhat plausible then that a more expensive console trying to market itself with superior video and audio would try to capitalize on that. The original NES did even have RCA jacks for video and audio, so the VGS could reasonably be expected to do the same for the people with more expensive television sets to use them, and to have two audio jacks instead of one for stereo output.

That said, I can’t decide if this would be too much like the audio equivalent of multi-layer scrolling.

Well, that concludes all the boring technical stuff for now, I think. Next time I’ll start diving into the actual work on the game by showing off the tools I’ve programmed to help create all this stuff.