Another Star 2 Dev Log #5: Return of the Screen Shader

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.

Screenshot of the original Another Star's CRT filter in action.

Another Star in all its glory.

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.

Screenshot of Another Star 2's in-development screen filter.

It’s a work-in-progress, so I hope it will look even better in the future.

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.

Screenshot of Another Star 2's in-development screen filter.

“Don’t sit so close to the screen!”

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.

Screenshot of Another Star 2's in-development screen filter.

Sometimes all you had to play your Nintendo on was a cheap old monochrome TV nobody else wanted anymore.

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?

Screenshot of Another Star 2's in-development screen filter.

Not pictured: figuring out whether the TV had to be on channel 3 or channel 4.

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!

Screenshot of a text box in Another Star 2.

“Hello everybody!”

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.)

Let’s Play Another Star!

A Let’s Player by the name of MrGazillion has just completed a blind Let’s Play of Another Star! Here’s the first episode, and you should really give it a watch:

I’ve never actually seen someone really sit down and play through my games before, other than roping a few family members to try them when I was much younger, so this is a new experience for me. As a developer, it’s pretty amazing to be able to watch as a new player picks up the game and gives insight into how they approach it and what they’re thinking. It’s one thing when people explain their thoughts on a game afterwards, but it’s quite another to see it firsthand and figure out what game systems players are overlooking, not understanding, or just not enjoying. There’s more than a few things MrGazillion missed that are probably far more my fault than his.

Developing Another Star felt like fumbling around in the dark a lot of the time. A few people did try the game and give they’re thoughts, and for that I will be ever grateful, but with so little total feedback it was really hard to figure out what was working and what was not. In many ways, I think the game suffered from my lack of direction. Thankfully, I have a feeling that Another Star 2 will have no shortage of volunteers to test it out.

MrGazillion has Let’s Plays of quite a few indie and niche RPGs on his channel, so you should totally go check it out if that’s your thing.

Another Star 2 Dev Log #4: First Screenshots

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:

Another Star 2 Screenshot

I’d say it’s almost ready to ship.

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

Another Star 2 Screenshot

A test render of the 8×8 pixels characters used to build a tile set.

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!

Another Star 2 Screenshot

Well, that didn’t work out as planned.

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.

Another Star 2 Screenshot

Not shown: scrolling.

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

Another Star 2 Screenshot

There wasn’t any collision detection at this point, so they could stand on the tables without worry.

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.

Another Star 2 Screenshot

My clones actively follow me around the map as I walk, like in Chrono Trigger or the Mana games.

It’s starting to look like an actual game!

Another Star 2 Screenshot

I added dogs, because why not?

Another Star 2 Dev Log #3: The Tools of Another Star 2 (part 1)

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 editor screenshot.

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.

ROM Architect editor screenshot.

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.

ROM Architect editor screenshot.

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.

ROM Architect editor screenshot.

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.

ROM Architect editor screenshot.

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.

ROM Architect editor screenshot.

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.

ROM Architect editor screenshot.

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.

ROM Architect editor screenshot.

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.

More Mock-Ups

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.

Inventory mock-up for Another Star 2.

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.

Character status screen mock-up for Another Star 2.

Another Star 2 Dev Logs #2: The Rules of Another Star 2

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…

Vision Riders Vision Game System
Vision Game System "Screenshots"

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.

Vision Game System palette

A simulation of the full VGS master palette, scaled to NTSC values.

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:

8-bit Sprite Composure

Four! Four sprites! Ah ah ah!

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.

Another Star 2 Dev Logs #1: The 8-Bit Era

Let’s talk bits.

When throwing around the term “8-bit console”, it’s important to understand what that actually means. “8-bit” has come to refer to a style of art and music, usually that specifically of the NES, but it really doesn’t have that much to with a console’s graphics or audio at all. Instead, 8-bit refers to the console’s CPU, and it denotes that the CPU works with a single 8-bit byte at a time. Today’s machines are almost all 64-bit. They still work with 8-bit bytes, but they work with them in chunks of eight bytes at a time. 8 bits × 8 bytes = 64 bits.

Now, when people think of 8-bit consoles, they generally think of the two titans of the era: the Nintendo Entertainment System (a version the Japanese Nintendo Famicom, with slightly different specs), and the Sega Master System.

Some people think of the Atari 2600, the first real hit home console, and they’re not entirely wrong as the Atari 2600 was an 8-bit system (with the same base CPU as the NES, in fact). However, most people use the term to refer to the third generation of home video game consoles, and that’s what I want to touch on today since that’s clearly the generation Another Star 2 is pulling its inspiration from.

So, without further ado, let’s talk about the consoles that Another Star 2 is drawing on.

Nintendo Entertainment SystemScreenshots from the Nintendo Entertainment System
The NES was the clear winner of the third generation of video game consoles. It dominated the market in Japan and the United States. This is the game console that I grew up with. The NES has a limited palette, and sprites and tiles can only have three unique colors plus the background color or transparency, but these limitations combined with a rather incredible little audio processor gave it a unique look and sound that has remained iconic to this very day.

Sega Master SystemScreenshots from the Sega Master system
The Master System, on the other hand, got its major foothold in Europe, and in Brazil it was so big that it thrived well into the 16-bit era. Meanwhile, most of us Americans didn’t even realize that Sega had a console before the Sega Genesis (this is the name Sega in North America gave to the Mega Drive). The Master System allows for more detailed graphics by allowing sprites and tiles to use far more colors at a time than the NES, but its master color palette is excessively bright and it lacks the NES’s more subdued tones.

The Master System is the console that the original Another Star was most heavily inspired by. In fact, I almost switched to the Master System’s palette about halfway through Another Star’s production.

Atari 7800Screenshots from the Atari 7800
There were a number of other also-rans in the 8-bit era, all of which failed to really leave a mark.

The most recognizable of them in the United States is the Atari 7800, and it’s possibly the most unique of all the 8-bit consoles as far as its hardware goes. But it was doomed from the start by delays, cancellations, and contract disputes as the Atari brand switched hands in the middle of the system’s launch.

Amstrad GX4000Screenshots from the Amstrad GX4000
In Europe, there was the short-lived Amstrad GX4000. Under the hood, it’s basically a console version of Amstrad’s personal computer line. It came out about the same time as the Sega Genesis / Mega Drive. You can guess what happened to it.

Epoch Super Cassette VisionScreenshots from the Epoch Super Cassette Vision
Also of minor note is the Epoch Super Cassette Vision. Releasing around the time as the Japanese Famicom, it never gained a real market share, and just barely squeezes in to the third generation of consoles. However, it does have some interesting specs. Unfortunately, almost every document and article about it is in Japanese, and even Wikipedia just gives it a tiny section in the main Cassette Vision article.

There were a few other consoles that came out in this era, some of which lasted mere weeks before being pulled from store shelves. (Did you know Casio had a video game console? Casio had a video game console!) There’s also the handhelds, such as the original Game Boy and the Sega Game Gear, but Another Star 2 isn’t meant to be a handheld game so I won’t go over those here.

Finally, there’s one last console to talk about, and that’s the TurboGrafx-16 Entertainment SuperSystem, released in Japan and France as the PC Engine.

TurboGrafx-16Screenshots from the TurboGrafx-16
A joint venture between NEC and Hudson Soft, the TurboGrafx-16 had an 8-bit CPU combined with a 16-bit graphics chip. As such, it was a strange marriage of the 8-bit and 16-bit eras, like a console stuck somewhere between them but never fully planted on one side or the other. Though an 8-bit machine by definition, it kicked off the fourth generation of video game consoles, better known as the “16-bit era”.

While it never quite caught on internationally, it was the first home console with a CD-ROM attachment. Japanese developers did some really amazing things with that 8-bit system thanks to the incredible storage capacity of the compact disc. It’s a shame those of us in the west didn’t see more stuff like this on consoles in the 90’s:

The reason I bring all these systems up is because I don’t want Another Star 2 to be completely shackled to the limitations of an actual 8-bit console. If I wanted to make an real 8-bit game, the thing to do would be to learn 6502 or Z80 assembly and actually code an NES or Master System game. Both systems are well documented and have a thriving homebrew scene—especially the NES.

Instead, like many so many others, I want to evoke the feel of the era. Some, like Shovel Knight, do this by working fast and loose with the limitations of the era, which I think betrays the parts of the aesthetic that I like the most.

What I want to do as a developer is take the most recognizable and most interesting limitations of the 8-bit era and use those to build the game’s art style and gameplay. To do that, I need a sort of framework, a mishmash of multiple consoles that plays to the strengths of the era without getting too bogged down in its drawbacks.

In this quest, the TurboGrafx represents a sort of speed limit for the 8-bit era. As you can see from my earlier mock-ups, my vision for the game surpasses anything the NES was capable of thanks to the limited number of colors on that system, and it just beats out the Master System because it has larger sprites and a more vibrant 256 color master palette instead of the Master System’s limited 64 colors. However, it doesn’t quite reach the fidelity of the TurboGrafx. If it catches up too close, then I know I’ve gone too far and I’m getting too close to the style of the 16-bit era.

In my next entry, I’ll start to detail the “rules” of Another Star 2’s limitations by taking a look at the specs of all the consoles I just talked about. I’ll be spelling out exactly what Another Star 2’s limitations are, why I think they’re interesting, how they’ll impact the game and its production, and I’ll go over a little bit about how I plan to implement them.

It’s Official

A couple months ago I wrote about a bunch of screen mockups I made for a theoretical sequel to Another Star. I haven’t done any more mockups since then, but I have been working on other stuff. Specifically, stuff like this:

Another Star 2 design document (page 1 of 113).

Yes, I know you can make out the obscured text. It’s probably not going to be the game’s subtitle anyway.

Over the course of about a month I put together a very thorough design document that explains the world and story of a possible Another Star 2, along with an overview of the game’s mechanics that goes into detail about various changes that would be made compared to the first game. It topped out at a whopping 113 pages because I’m crazy, and also because I was greedy and didn’t want to leave out any possible ideas that seemed good at the time. As a result, I’m guessing half of what’s in this thing won’t see the light of day. To compare, Another Star‘s design overview was a mere six pages long.

So yes, just to be clear, as you’ve probably already guessed Another Star 2 is in production. Just keep in mind, it may not be Another Star 2 by the time it’s done. Also keep in mind that, unlike the first game, I will probably not be able to work on Another Star 2 full time like I did the original. My career and financial situation are nowhere near as stable as they were just two or three years ago, and that’s probably going to take a larger and larger toll as time goes on. Don’t expect to get your hands on this thing before mid 2017, if not later.

Anyway, one of the huge mistakes I made while doing Another Star was failing to share it. I wanted to keep everything under wraps until it was all done, in large part because I didn’t want to spoil the “twist” near the beginning where the story switches from a somewhat generic RPG world to a mix of fantasy and sci-fi. If you look at almost all of the early screenshots and promotional work for the game, Soel is never even mentioned. In the end, though, nobody really cared that much about the direction the narrative took. It’s a really simple game with a simple story, and trying to keep a lid on it backfired because I ended up having to release the game to absolutely no fanfare, all because I was afraid to show anything past the first half of the first dungeon. I never managed to build an audience for the game. This, it turns out, is absolute death for an indie title.

I do not aim to repeat that mistake with Another Star 2. Over the coming weeks and months, I’ll be showing off some of the tools I’m developing to make Another Star 2 a reality, and as time goes on I’ll be sharing a lot about the world and characters of the game. Sure, I’m going to keep lots of stuff up my sleeve for later, but I’m making it a point to publicly document the game’s progress.

I hope you’re looking forward to it.

RPG Concept Pixel Art

In my mind, I always tend to group Another Star with two other titles: Freedom Planet and Shovel Knight. All three came out around the same time, and all three take heavy inspiration from a past system; Freedom Planet from the Genesis/MegaDrive, Shovel Knight from the NES, and Another Star from the Master System. Freedom Planet and Shovel Knight are far more polished—and exceedingly more popular—than Another Star, so the comparison may seem a bit silly, but I just can’t help but consider them “sibling” games.

This past Christmas day, GalaxyTrail made a surprise announcement with a rather amazing trailer for Freedom Planet 2. For whatever reason, the exhilaration of the trailer mixed with seeing Another Star‘s sibling series make such a splash again made me feel more than a little nostalgic, and I couldn’t help but think about Another Star.

I’ve noted many times before when asked that there’s really no plans for a sequel to Another Star, and that much is still true for the most part. I’d like to come back to the game eventually and give it a spiritual successor to build on the battle system, if not necessarily a direct sequel. But I didn’t really want my next game to just be more of the same thing, and I didn’t want to get pigeon-holed as a retro-pixel-art RPG developer and nothing more. Yet in the nearly two years now following Another Star‘s 2014 release, I still don’t have much progress on a second game other than the few prototypes I’ve posted here.

Thinking about what little plans I’ve had floating around in my head for a direct follow-up to Another Star, my internal creativity insisted on expressing itself somehow and so I wasted my time cobbling together a mock-up of what I imagined the battle system of a theoretical Another Star 2 might look like. This is the result of that initial spark of imagination, which I originally posted on Twitter on the 27th of last month:

Battle Scene

Enemies approach with non-square pixels!

Again, keep in mind that this and everything else in this post are merely mockups and conjecture. No game and no gameplay exist. Right now they’re just concepts and ideas and nothing more, and they may well never be anything more than that.

Still, right off the bat it’s apparent that this looks a little more advanced than a Master System title. It’s quite a bit closer to the TurboGrafx-16 (aka the PC Engine), honestly. Ignoring the palette, which is based directly off the 8-bit master palette used to derive Another Star‘s mere 16 colors, the enemies are sprites instead of background tiles like most NES games have for RPGs. (The three player party members depicted against the black background would be tiles instead.)

The NES and Master System were both limited to, at most, eight sprites per scanline, and each sprite was exactly eight pixels wide. This is why so many 8-bit games have a huge problem with their sprites flickering. They’d end up on the same horizontal line of pixels and some of them would get ignored. However, the battle screen above has four enemies, and each enemy would be constructed of multiple 8×8 sprites. At their size (about 32 pixels wide), each enemy would need four sprites worth of width. Since the enemies are arranged horizontally, four enemies times four sprites wide means that you end up with sixteen sprites on a scanline. That’s twice the allowance for most 8-bit systems. It does adhere to the imaginary specifications of the imaginary 8-bit Vision Game System which supposedly ran the original Another Star, but I worry it could be a turn-off to those who were drawn to the original game because of the strong graphical resemblance to the NES Dragon Quest games.

Regardless, I ended up really liking how that mock-up turned out, especially the forest background which really exceeded what I thought I could accomplish. So I decided I’d do just one more concept mock-up.

In a Classroom

I never could decide how I wanted that door to look, or which tile the player would have to step on to actually exit the room.

This time I did an area map, to see how the characters might look moving about the world. Notice that they’re taller than the normal 16×16 pixel sprites of most NES overhead games. However, a couple of the later NES RPGs did use them (Crystalis and Lagrange Point, et al.), as well as the Master System’s own magnum opus Phantasy Star. On an 8-bit system, you’re using up more VRAM because larger sprites obviously take up more space, but since they’re not any wider they wouldn’t cause any extra flicker. And those extra pixels are surprisingly useful for making the characters really pop out and feel unique.

If you look closely, you’ll notice that the way the heads of the two students talking are done in the mock-up closely match the way I drew Tachi’s head in Another Star. I referenced the original game’s graphics quite a bit while doing these.

For some reason, I decided to do just one more area map.

Keeping Lookout

It’s supposed to be 8-bit, so there’s no fancy parallax scrolling for you here!

When I was nearing the end of production on Another Star, I decided that whatever the sequel or eventual spiritual follow-up to it may be, it would begin with a character in a forest, keeping watch in a look-out post. I didn’t decide why, or even what exactly they were watching for, I just knew that this was the scene I wanted to use to introduce the new hero or heroine of the game. This is a mock-up of that scene, which I decided would be more interesting in a platformer-style perspective than trying to top-down sprite an outpost tower, although I never did decide what they’re watching for, despite the character’s statement here that whoever it is, “they’re not coming back.”

(You may also notice that in this screen and most of the others there’s an extra line of spacing between the sentences, unlike the classroom. It’s something a lot of Japanese RPGs did on 8-bit systems, and I almost did this for Another Star. The extra line of tiles is for diacritical marks, which are unused in normal English but needed in Japanese and many European languages. When localized to English, some games removed those lines so they could fit more text on the screen.)

However, shortly after finishing and posting this mock-up, I realized that it would make more sense for this scene to happen at or near sunrise, because the light-skinned character still has to go home and get ready for the class she attends in the first area screen I did. So I tweaked the palette a bit.

Keeping Lookout

Can I just say that I really like this palette.

If you’re wondering what the green thing is that the light-skinned character is holding, it’s supposed to be binoculars, which would be more apparent in an actual game where the sprite could change so that she actual holds them up to her eyes from time to time.

Finally, here’s what it looks like without the dialog box cutting off a chunk of the screen:

Keeping Lookout

Honestly, it probably looked better with the dialog box in the way…

Anyway, while working on the two area maps I just went over, I started to think about the overworld map. When your sprites are 16×16 squares, they’re already sort of “symbolic” and don’t look that out-of-place when you zoom out to the world map with even more wacky scaling issues. But the taller sprites can look a bit jarring on an overworld map because they tend to appear more in-scale to the normal area maps.

Final Fantasy VI got around this by dazzling us with its fancy SNES mode 7 graphics, but I decided to play around with the Chrono Trigger route of actually making different, smaller character sprites for the overworld.

The Overworld Map

Whether it works or not is left up to the viewer.

I do like how it came out, even though it has some issues with how it tries to skirt 8-bit limitations. First off, as nice as the mountains look at that size, there’s a reason NES games tend to make a single mountain tile and just stamp it all over the place. The VRAM those mountains would eat up would be costly, and would mean less graphics for other things.

I really wanted actual sandy beaches for the coastline, but I couldn’t get it to look right while still being at least conceivably able to fit within the VRAM limitations of an 8-bit system. Still, the roundness of the coast is actually a pretty nice throw-back to the original Another Star. Really love how the bridge and little village turned out, too. The forest looks pretty good as well, although it’s a bit over-rendered in my opinion.

The river I have mixed feelings about, but I do like how there’s a shallow ford crossing near the top of the screen. That was a map feature that I originally had in Another Star that got cut fairly early on because of the tile limit. It was supposed to be used in areas that didn’t really have enough traffic to justify having a bridge built there.

After finishing this, I had three of the four main screens of a classic console-style RPG: a battle screen, an area map screen, and a world map screen. I just needed one more to complete the set: a menu screen.

Menu Screen

That thing on Dewey’s head is supposed to be a bandanna.

Here we finally find out the character’s names, even though they’re liable to change supposing I actually made this into a full-fledged game.

The layout is obviously taken directly from the original Another Star, but there’s a few things changed up. At the bottom is a “reserve” of extra party members. Another Star stuck you with three characters and set you off, but I want the player to have more power to customize their set up in any sort sequel. Combining multiple party possibilities with Another Star‘s omni-attack mechanics is an idea I’ve wanted to see realized for a long time.

I figured I’d stick the extra characters on the main screen instead of hide them, so that they don’t feel left out when they’re not in the party. And maybe the characters in the “reserve” could have some other sort of contribution somehow when they’re not in the main party?

It was at this point that I had planned to finally stopped, but there was one more thing I kind of wanted to work out, and that was how the player input their battle commands.

Battle Scene


The idea I had was that, at the end of each phase of battle, the screen would quickly scroll down to give the player their battle menu. The characters would also turn around to face the player, because I really like it when I can see who I’m playing as.

I forgot how much room Another Star‘s battle screen took up until I did this. You’ll notice the enemies are nearly pushed off the top of the screen. You’d lose even more to the overscan of a traditional television (or Another Star‘s CRT filter), and it’d even be more noticeable for big enemies like bosses.

Well, okay then, what if the screen didn’t scroll, and the menu was at the top?

Battle Scene

Okay, never mind then.

Yeah, that’s probably not going to work. Even if I set the menu tiles with a higher priority to appear above the sprites, that trooper’s head is going to be clipped and it would look just as tacky as being above it. We want to be able to see who we’re fighting, after all. What’s the point of having big, fancy enemy graphics if you can’t see them?

Well, since the game can probably only have four enemies at a time anyway if we stick with the pretend Vision Game System’s specs, maybe we could just have four lines and push the “flee” command off the bottom of the menu to make the box smaller?

Battle Scene

That’s better. Not perfect, but better.

It’s not ideal, but at least the trooper isn’t being squashed. Hopefully players would realize there’s more options, though. Ideally, the down arrow tile would be animated to go up and down a pixel so that it’d stand out more.

The trooper would probably not be the biggest enemy, though. What if we were fighting, say, some huge dragon? We’d be back at square one. Let’s try scrolling down again.

Battle Scene

Now’s as good a time as any to mention I like the forest background way more.

Okay, that’s not too bad. Especially tall or big enemies would still be lost to the overscan, perhaps, but it seems to give a lot of breathing room. I’d also really like to be able to display the player’s character’s names, but there’s hardly any room left as is.

I like this option the best, personally, but maybe you feel differently?

In any case, this is where I should have stopped, but I decided to make just one more in preparation to make this big, long blog post.

Non-Battle Encounter

The grass could use a bit of variation.

In Another Star I had a lot of self-imposed limitations when it came to the graphics, but not so much with text. Early on, one of my thoughts was that maybe not all encounters would be battles. Every now and then, when you accepted an encounter maybe you’d get some text describing how you’d just come across a wandering merchant instead. Or you’d chance across some other adventurers with news and the beginning of a side quest. Maybe it’d be a short scene describing how you came across extra loot, items, or some free EXP.

The idea was scrapped before I ever attempted to implement it, but it seems the idea has stuck with me. This concept mock-up illustrates the party chancing across a random merchant. The screen is the same as a battle, except that the party isn’t drawing their weapons. In another scenario, this setup could easily transition into a battle, though. Say you choose to help somebody, and they turn out to be bandits? It was just an interesting thought, and I wanted to see how it might actually look in-game.

In an actual game, I’m not sure how annoying these non-battle encounters could be while trying to grind, though. Then again, getting free items and EXP every now and then without having to fight could always make up for the occasional ones you have to stop and make a choice for, perhaps.

Well, that’s finally the last of the concepts I did. What are your thoughts? Is this something you’d be interested in seeing? Do you feel it strays too far from what Another Star was? How important are the 8-bit limitations of the original game to you?

Let me know in the comments!