Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

Advanced search

1401010 Posts in 67843 Topics- by 61374 Members - Latest Member: blakeadam

May 23, 2022, 12:29:16 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsAnother Star 2 - a console style RPG with pretty pixel art
Pages: [1] 2 3 ... 7
Author Topic: Another Star 2 - a console style RPG with pretty pixel art  (Read 22559 times)
Level 1

View Profile WWW
« on: March 12, 2016, 09:19:18 AM »

An 8-bit Console Style RPG


Another Star 2 is the planned sequel to my 2014 game Another Star, although by the time it's complete it may only be a spiritual successor and not an actual sequel. I learned a lot making the original game, and I really want to put that knowledge to use here.

Like Another Star before it, Another Star 2 is planned to be an homage to RPGs of the past that includes innovations and improvements introduced in later eras. While ultimately light-hearted in nature, the story is not a comedy, and I don't want to hide behind jokes to excuse poor gameplay mechanics. I also want to reuse and refine the fast-paced battle system I created for Another Star, building on it and introducing new mechanics to give a little more strategy to battles. The optional encounter system from the first game will also make a return, letting you ignore random battles at will while exploring.

Dev Log Entries

1:   The 8-Bit Era
2:   The Rules of Another Star 2
3:   The Tools of Another Star 2 (part 1)
4:   First Screenshots
5:   Return of the Screen Shader
6:   Words on a Screen
7:   Enemies Approach
8:   A Different Path
9:   The Battle Interface
10: The Battle Menu
11: Getting Around
12: FM Synthesis
13: The Unfinished Overworld
14: A Scripting Language
15: Points of Interest
16: "Welcome To Our Town!"
17: The World of Byo
18: The Path Forward
19: Taking Inventory
20: Setbacks
21: Adventures With Friends
22: The Shape of Music
23: Issuing Orders
24: Speak Your Mind
25: The Perils of Indecision
26: Path of Least Resistance
27: The Full Arsenal
28: Toying With the Enemy
29: The Fishing Hole
Art Style

Here are some mock-ups of the direction I'd like to go. Keep in mind that these are not screen shots. Coding has begun on the game, but it does not yet exist in anything near a playable state. All of these were put together in Photoshop. The display area is 256×224, stretched to a 1.143 pixel aspect ratio, the same as the Nintendo Entertainment System and the Sega Master System. All colors are simulated 8-bit BBGGGRRR.

I threw this battle screen together one day, and that's what started everything.

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.

Can I just say that I really love this sunrise palette?

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

I'm thinking about making the player character tiny on the overworld to emphasize the scale.

The final product may not look exactly like these; for example, I'm not sure I'm going to use that exact set up for battles. But the mock-ups do show off the sort of style and level of quality that I'm looking to achieve. You can see a few more mock-ups and a lot more explanatory commentary in this enormous post elsewhere.


While I'm proud of the work I did on Another Star, I was never 100% happy with the way it turned out. The game started out as a little mini-RPG for Ludum Dare, in the vein of the old QBasic RPGs I loved in my youth. Since the Ludum Dare theme was "minimalism", the game began with a self-imposed arbitrary limit of 256 8×8 pixel tiles to build all its graphics from (including the font). But even as the game grew in scope well beyond my initial vision, I clung to that limitation. Some limits can make a game better, but I think this one held me back. Even though later versions of the game eliminated the tile limit to completely revamp the enemy graphics, I feel like the game could have been so much better on all fronts, and I've been itching at a chance to really let my creativity loose. Another Star 2 will still have limitations for sure, but I want to make sure they enhance the game's style and atmosphere, not exist solely to get in the way.

Another Star 2 is currently being developed in C++, while C# is being used to make the various tools. I'll be showing off those tools in coming posts.
« Last Edit: September 23, 2021, 08:30:39 AM by TheGrandHero » Logged

Level 1

View Profile
« Reply #1 on: March 13, 2016, 11:55:03 AM »

I love the look of this title, way more than the original. It only makes sense, considering you would have learned a lot making the first one.

The world map on itself it's just way more fun to look at than Another Star's. It just feels way more alive. I think one of my main problems with Another Star is that the game gets pretty repetitive for a 20 hour long game -- I'm only about 10 hours in but I feel I've seen everything it has to offer.

Looking at what you're showing here, I'm seeing: better world map, story cut scenes, and portraits within the dialog! Those things alone makes it a day one purchase for me  Hand Money Left Addicted

One thing that's missing is the interior of villages. Different villages can give a lot of personality to all of them. In Another Star I don't know if the chief is a male or female, if they're old or young, if they live in huts or stone houses. I know it would be a lot more work but I think it would pay off (or I hope so anyway).

Anyway, I'm totally subscribed to the thread.

Superb Joe
Level 10

View Profile
« Reply #2 on: March 13, 2016, 02:02:35 PM »

seems like a brave move to make a sequel to a stevie wonder song, a great one at that, as an rpg. good luck to you
Level 1

View Profile WWW
« Reply #3 on: March 13, 2016, 05:16:15 PM »

seems like a brave move to make a sequel to a stevie wonder song, a great one at that, as an rpg. good luck to you

Purchasing the rights to the song was incredibly hard, let me tell you. Gentleman

One thing that's missing is the interior of villages. Different villages can give a lot of personality to all of them. In Another Star I don't know if the chief is a male or female, if they're old or young, if they live in huts or stone houses. I know it would be a lot more work but I think it would pay off (or I hope so anyway).

Another Star 2 will most likely keep the same menu-based town system as the original. It kept the pace of the game up to match the battle system because locations tended to be an in-and-out affair instead of having to hunt down the dozen or so meandering NPCs and then walk around to find what shops there are. It also allowed for a larger world with more towns and villages, since each one didn't need its own maps and a bunch of NPC dialog. In Another Star, cities could be described as having thousands of inhabitants instead of pretending they're big even though there's only six people outside to talk to. Also, it played well to... your guessed it... the tile limit.

^ This is basically all of Another Star right here, pre-version 3. (Plus the parts that weren't complete yet in that image, of course. The final boss is missing, for example.) I stretched this over twenty hours, somehow. I packed that thing absurdly tight. No tile went unused.

But you're absolutely right about the lack of personality, and the blame lies solely on my stubborn adherence to the tile limit. Another Star really should have been a five to ten hour game with maybe four or five dungeons. It would have been an incredible mini RPG, and I would have had it out the door in the original two or three month time span I had planned. (Or closer to it, at least.) Yes, it's cool that I accomplished so much with just a single 128×128 texture, but I'm not sure it was worth the sterility it gave the game for stretching resources so thin.

The screenshot above demonstrates how minuscule the enemies had to be in the original release of the game. Thankfully, in version 3 of Another Star, I completely redid all the enemy graphics. A part of me does miss the old enemy graphics just because of how much I accomplished, and a sense of nostalgia, I suppose, but the new ones really are just so much better.

One of the other things I wanted to do in the big version 3 overhaul of Another Star was add graphics for all the towns and villages, sort of like when you went into a town in the original Pirates! back in the day. Sure some little locations would probably share their graphics, but it would give a better feel for what a location is like, how rich or poor their economy is, how powerful they are, and so on. I also really, really wanted to give each clan its own symbol and banners (it's always been implied in the text that each clan has its own style of face paint to denote their own warriors), and have the clan chiefs appear on screen when you talk to them a la StarTropics. Unfortunately, it was just taking too long. The enemy graphics were taking forever because the new graphics settings were breaking things, plus I just didn't have the time or money to keep pouring into a project that was already complete, and it was holding up the Steam release. There's still a chance I might go back and do it for a version 4, but I don't know if I really want to spend the rest of my life trying to perfect a single old game instead of moving on.

In any case, what I'm getting at is that the way I'm planning Another Star 2's towns is that you will get what Another Star should have had. When you enter a town, you'll get a decent-sized graphic showing what the place looks like. When you go to the item shop, you'll actually see the clerk. Maybe they'll even get mouth flaps. When you visit important people, they'll come up on screen to have the conversation with you. While the basic system may remain, it won't just be a text adventure game anymore whenever you go someplace populated.

Looking at what you're showing here, I'm seeing: better world map, story cut scenes, and portraits within the dialog! Those things alone makes it a day one purchase for me  Hand Money Left Addicted

Why wait? You should pre-order now and get some multiplayer map packs that you know you'll never use.

Level 5


View Profile WWW
« Reply #4 on: March 14, 2016, 05:59:45 AM »

Man, those mock-ups are beautiful! Been watching a play-through of the first Another Star (curious), and I'm excited to see all of the new and improved additions in action!

Will you also have the soundtrack re-done as well? The mock-ups make me think of a Shining Force revamp of the soundtrack!

Level 1

View Profile WWW
« Reply #5 on: March 14, 2016, 06:10:01 AM »

Will you also have the soundtrack re-done as well? The mock-ups make me think of a Shining Force revamp of the soundtrack!

I'll be talking a little bit about the soundtrack style for Another Star 2 in the first dev log entry here pretty soon. Like the graphics, I want the audio to be an evolution of what was in the first game, but I don't quite want it to sound like something too far into the 16-bit era.

It is interesting that you bring up Shining Force, though. I didn't really grow up with that series on the Genesis / Mega Drive and I've only played bits and pieces of them, but I've used this particular track for inspiration for some time now:

While I think the SNES's S-SMP was the better sound chip, the YM2612 is a pretty sweet little FM chip and it's sad that hardly anyone other than Sega really seemed to know what to do with it. You get outside the games directly produced by Sega, and the instruments tend to screech. :/
« Last Edit: March 14, 2016, 09:22:26 AM by TheGrandHero » Logged

Level 1

View Profile
« Reply #6 on: March 14, 2016, 07:56:10 AM »

In any case, what I'm getting at is that the way I'm planning Another Star 2's towns is that you will get what Another Star should have had. When you enter a town, you'll get a decent-sized graphic showing what the place looks like. When you go to the item shop, you'll actually see the clerk. Maybe they'll even get mouth flaps. When you visit important people, they'll come up on screen to have the conversation with you. While the basic system may remain, it won't just be a text adventure game anymore whenever you go someplace populated.

Wanting the inside of the villages was mostly for the diversity it would give to the world. I think your solution does the trick as well, an image would go a long way.

How long would you like this game to last (gameplay wise?)

Why wait? You should pre-order now and get some multiplayer map packs that you know you'll never use.

I'm only preordering if there's a Hello Kitty costume for Tachi.

Level 1

View Profile WWW
« Reply #7 on: March 14, 2016, 09:10:21 AM »

Wanting the inside of the villages was mostly for the diversity it would give to the world. I think your solution does the trick as well, an image would go a long way.

There will be town areas that you can "explore", but they'll be fairly uncommon and limited mainly to important story areas. The original game had a couple of these as well, the Minas Village clan hall being the notable example.

How long would you like this game to last (gameplay wise?)

Shooting for roughly the same length as the first game: an average of twenty hours for the main quest + most major side quests. Your mileage may vary, as usual. I've had people blow through Another Star in less than ten hours their first playthrough. I assume most of them just hold the cancel button to auto-scroll through the story. Smiley

I'm only preordering if there's a Hello Kitty costume for Tachi.

That's an exclusive pre-order bonus at GameStop only. If you want to make sure you get the pre-order bonus you want, please consult this chart...

Level 1

View Profile WWW
« Reply #8 on: March 16, 2016, 12:19:12 PM »

Dev Blog #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.

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.

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.

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.

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.

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.

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.

Superb Joe
Level 10

View Profile
« Reply #9 on: March 16, 2016, 12:42:37 PM »

the master system was cool <--- you can take that to the bank. they won't let you put it in your account or anything but if you load this post on your phone or tablet it's possible to do so in a bank
Level 1

View Profile WWW
« Reply #10 on: March 29, 2016, 07:47:48 AM »

Dev Log #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...

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.

Here's simulation of the 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).

(Continued in next post; sorry about the wall of text.)

Level 1

View Profile WWW
« Reply #11 on: March 29, 2016, 07:48:39 AM »

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?

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

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.

Level 1

View Profile WWW
« Reply #12 on: April 01, 2016, 05:39:40 AM »

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.


Level 1

View Profile WWW
« Reply #13 on: April 05, 2016, 07:09:20 AM »

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

Level 4

making gams

View Profile WWW
« Reply #14 on: April 05, 2016, 07:24:42 AM »

Really enjoying your mockups, graphically it all looks rather pleasant, I'm appreciating that you're going with a slightly different flavour of 'retro' than 99% of 'retro' games go for, that is to say, NES/SNES-inspired. Oh, and the font you're using in those mockups is really nice too.

Level 1

View Profile WWW
« Reply #15 on: April 10, 2016, 06:17:59 AM »

For those who may be curious, here's how pure color ramps tend to turn out in 8-bit BBGGGRRR:

Notice how the colors can't transition completely linearly. It's especially noticeable with the blues, since the blue value itself is limited to two bits instead of three. As noted earlier, the grays have it the worst, as demonstrated by the second palette from the top. You only get two pure grays between black and white, so to add more gray tones you have to either bias towards blue (cool grays) or away from blue (warm grays). You can get some slightly better ramps than what I've shown here with a little more tweaking, but it's not going to get too much better than this. Dithering will net you a few more shades, but I tend to dislike dithering sprites other than to give them texture.

That said, it's not really too much of a problem when you've only got 32 colors total to with at a time anyway, and it's far more versatile than anything else in that era other than the Game Gear (which had 12-bit BBBBGGGGRRRR color; better even than the Genesis). I have a certain fondness for BBGGGRRR, to be honest, since I find its limitations to be somewhat endearing.

Really enjoying your mockups, graphically it all looks rather pleasant, I'm appreciating that you're going with a slightly different flavour of 'retro' than 99% of 'retro' games go for, that is to say, NES/SNES-inspired. Oh, and the font you're using in those mockups is really nice too.

Thanks! The font in the mockups is simply the one I made for the first game, but with the added lowercase letters I never used in that game. I wanted something that would be readable when blurred on an old-style television set, but with a little more character than just straight-up rehashing your standard VGA era DOS font.

Level 1

View Profile WWW
« Reply #16 on: April 23, 2016, 06:19:05 AM »

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:

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:

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!

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.

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.

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.

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!

I added dogs, because why not?

Level 0

View Profile
« Reply #17 on: April 23, 2016, 08:13:46 AM »

Incredible work! I like your pixel style a lot and can't wait to see more stuff!  Hand Money Left Grin Hand Money Right

By the way, your technobubble is my favorit part of the devlogs!
Level 4

View Profile
« Reply #18 on: April 23, 2016, 12:16:13 PM »

How have I not noticed this devlog before? Everything looks great!

Living and dying by Hanlon's Razor
Level 1

View Profile WWW
« Reply #19 on: April 30, 2016, 06:27:18 AM »

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.

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.

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.

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

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?

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!

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

Pages: [1] 2 3 ... 7
Jump to:  

Theme orange-lt created by panic