ChoRenSha68k Development Notes (2001)

1993 - Establish a basic code library for the X68000
1995 - Release ChoRenSha68k v.010, sold as a doujin game at Comiket.
1998 - ChoRenSha68k v1.00 released
2001 - Windows port completed, released publicly as freeware.

Context of the Development

Selling Doujin Games at Comiket

ChoRenSha68k was first sold as doujin software at Comiket. At that time Comiket was held at Harumi Wharf. You saw very little Windows software: instead, it was a hodgepodge of different Japanese computers from previous generations. The X68000 started to take over at Comiket in the late 90s. To distribute our games, we still were using 1MB floppy discs instead of CDs.

Getting Development Feedback from Kusa no Ne BBS users

Back then, the internet was not yet popular among the masses. On the Kusa no Ne BBS system, each board was run by volunteers. You would connect directly to the board manager’s home line by modem to read or post there. It was a very primitive system. There was a very active community there exchanging game development programming info. I was able to receive a lot of feedback for the development of ChoRenSha68k.

The Sharp 68k Series

ChoRenSha68k was first developed for the Sharp X68000 computer series. The Sharp X68000 was a Japanese brand computer first released in 1986. It was basically the Capcom CPS-1 hardware with a keyboard attached, which meant it received a lot of direct arcade ports. It was well-loved by arcade gamers of that era.

As the x68k entered the latter stage of its lifespan, more and more guidebooks were published on its internal specs, which galvanized the x68k doujin and freeware software development scene.

At the Game Centers

As the horizontal STG boom that was first led by games like Gradius and R-Type died down, there was a new influx of vertical STGs that were precursors to what we today call “danmaku STG.”

However, due to the fighting game boom and the fact that STGs themselves were increasingly catering to hardcore and expert players, the STG genre was on the verge of dying out. Leading developer Toaplan went bankrupt, IREM temporarily stopped making STGs, and Konami were distancing themselves from STG and moving decidedly into moe fanservice after the huge success of Tokimeki Memorial.

Game Design Considerations

Influences for ChoRenSha68k

ChoRenSha68k was greatly influenced by the STGs installed at game centers at the time. Batsugun (1993 Toaplan), Tatsujin Ou (1992 Toaplan), and Battle Garegga (1996 Raizing) were especially influential.

Here I will look back on the specific ideas I had (and how to implement them) for ChoRenSha68k, as well as the general design ideas I had at the time.

Balancing the Power of the Player’s Shot

At max strength, the player shot appears four times more powerful than the starting power. However, the actual damage is only 1.375 times greater.

If I quadrupled the actual damage to make it match the appearance of the max power shot, it would completely break the game. Visual flashiness and actual game balance are two different things. This kind of deliberate fine-tuning was something I learned from the older Toaplan games.

The Width of the Player Shot

Many STGs installed at the game centers back then featured a player shot that got wider as you powered up. This kind of system makes the game balance very difficult to adjust. Games with a fixed shot width like Star Force (Tecmo 1984), Valgus (Capcom 1984), and 1942 (Capcom 1984) had a unique game balance that you don’t see in later games with a variable width shot.

For ChoRenSha68k, I took a page from Star Force and made the shot width fixed. But since I wanted a modern, visually appealing shot as well, I gave the shot a cool scattering effect.

Point-Blank Shooting

Older STGs frequently used the point-blank technique, where you get extremely close to an enemy to do more damage. This imparted a certain tempo and pacing to those games that I definitely wanted to recreate in ChoRenSha68k.

In older STGs, the main things that encourage the use point-blank shooting are as follows:

Software Limitations on the Number of Bullets

CPUs at the time were not very powerful, working memory was severely limited, and there was an upper limit to the number of shots that could be displayed onscreen. Because of this, it used to happen in some games that if you fired too many shots too quickly, you’d reach that upper limit, and you wouldn’t be able to fire until one of your previous shots had disappeared off-screen. This common phenomenon was called “dan kire.”1

By firing at an enemy at point blank range, the amount of shots appearing onscreen is reduced and rapid fire could be achieved. The classic example is the early Gradius series, which consistently limited the player to only two shots on screen at any time.

Wide Shot

When the player shot is wide, you can deal tremendous damage if you can concentrate all of the shot on a single enemy. This leads to a gameplay style that necessitates point blanking. The blue shot in Same! Same! Same! is one example, and there are many others.

Short-Range Shot

Having a short-range shot forces you to get closer to enemies to shoot them. Examples would be Tiger Heli, Omega Fighter, Slap Fight’s default shot, and Tatsujin Ou’s napalm shot.

However, the above three mechanics all went against what I had in mind for ChoRenSha68k. In the first place, I didn’t want to replicate the “dan kire” effect. I also wanted a game balance like Star Force, with a narrowly focused player shot. And there was always the chance that, from a player’s perspective, shortening the range of your weapons would appear totally absurd.

Instead, to encourage players to make point-blank attacks in ChoRenSha68k, I decided to reduce the size of the enemy collision hit boxes. As a result I was constantly making adjustments and corrections to the hitboxes. The stage 4 warship enemies (that ones that only fire in 8 directions) in particular took many adjustments, and I had to redraw the pixel art four times.

Pros and Cons of Autofire

The concept of autofire did not exist in older STGs, and you could only fire as rapidly as your fingers could tap. Games with manual firing had a special tactile feel that doesn’t exist in autofire games. Manually firing was one of the chief pleasures of STG games, in fact. However, at some point game centers started installing autofire circuits on their cabinets (partly as a strategy to attract more customers), and in response game developers started taking autofire circuits into account when they balanced their games.2 Eventually autofire became a standard feature in the game itself.

Manual firing is a distinct skill from pattern memorization and dynamic vision. It is one of the more difficult skills to build, and I was concerned as a developer that if I made certain enemies too resilient, it would put up an impossible hurdle for players who couldn’t tap fast enough. That’s another plus for autofire, from a game balance perspective.

Manual fire mechanics were on the verge of dying out, so I wanted to use it for ChoRenSha68k. After much consideration, I decided to implement a semi-auto feature. I imagined the slowest possible speed for autofire would feel as if you were popping bubble-wrap with your thumb, and I set it to require about 4 presses per second. Tapping faster than that wouldn’t increase the shot speed.

Sound FX execution priority

Due to hardware limitations, the x68k can not play multiple sound effects simultaneously.

In my design concept for ChoRenSha68k, my number one goal was to make the sense of destruction fun. Second was to make the shooting exciting. The boss attack patterns also depended on certain sound fx, so for strategy those were very important and needed to be heard above the damage sound fx. Accordingly, I prioritized the fx as such:

Explosions > Boss Pattern FX > Damage Sound FX > Player Shot

Accuracy of Enemy Shots

If you program everything correctly, you can make the enemies aim their shots with 100% accuracy. While this is technically correct in a programming sense, when you think about it from a gameplay perspective, a higher accuracy of enemy shots isn’t necessarily better.

Below I call your attention to several games that made use of low-accuracy enemy aiming:

Hishouzame (Toaplan 1987) – Beginning with Hishouzame, Toaplan’s games of this era used a system where the enemy shot angles were calculated based off an arc tangent table with a unique random variability (probably a fractional rounding off), so that true 45 degree angled shots do not occur often. As a result, a gameplay strategy evolved where you have to weave through bullet curtains of slightly-off 45 degree angle spaces. (I’ve heard that the Raiden development team followed Hishouzame and deliberately adopted the same system).

Parodious Da! (Konami 1990) – In this game the enemy aiming is limited to 16 directions. This allowed for several techniques based on lining up at the right point, giving it a unique gameplay.

V.V (Toaplan 1993) – After the second loop, the screen gets smothered with a large number of slightly delayed suicide bullets. Because their angle of fire is very low (nearly straight), some pretty dense bullet clusters occur, and it can be suprisingly difficult to dodge. There’s a lot of chances to use cutback dodging techniques.

Studying these examples, I decided for ChoRensha68k to manually adjust the firing accuracy depending on the circumstances. The later stages, for example, have a lot of deliberate adjustments.

The Item System

I had spent many years thinking about how to structure an item system where the player can freely select the item he wants. In Kyuukyoku Tiger and Raiden, where the items change color on a set timer, it’s stressful when you collect the power-up you didn’t want. In games like 1943 and Twinbee, you have to stop shooting to collect the power-up, which is also a source of stress.

After mulling over a way to conquer these deficiencies, I came up with the system you presently see in ChoRenSha68k.

Unfortunately, once I added the mechanic where you can obtain all three items simultaneously by centering yourself between them, it became a fundamental part of the game mechanics. It became an integral part of the scoring system; I couldn’t remove it, and it remained throughout the development. It negated my original concept of selecting one of three items and I regretted adding it, but I knew players wouldn’t assent if I removed it in a later version, so I just left it in as-is.

On the Necessity of a Scoring System

There were many STGs installed in game centers at that time where the more you played for score, the less in touch you were with the original style of gameplay found in the genre. Many people were starting to ask the fundamental question of whether scoring was even a meaningful mechanic at all. When I first started developing ChoRenSha68k I was firmly against playing for score, but by the time I released version 1.01 I had included a few scoring elements.

When I decided to add a scoring system, I was stuck between two choices. Should it be an all-or-nothing system, where dying once makes recovering your score impossible? Or should making mistakes be permissible, allowing the player to strategize a recovery? I had wanted to use the latter system in ChoRenSha68k, but if I had to honestly assess the game, I think it ended up being more of an all-or-nothing system.

Battle Garegga was a big influence on me when I was thinking about scoring systems. The way there’s a random aspect to the opening stage, the ability to destroy enemy parts for score, and more… I really cribbed a lot from it.

The x68k Development

Development Language

There was a C compiler for the X68000, and the gcc compiler had also been ported (it was version 1.42 then, I believe). It was still a time when programmers took pride in writing games in assembly, but I coded 90% of ChoRenSha68k in C, and I only used assembler for pinpoint locations where I needed increased execution speed.

Expanding the Sprite Display Limit

The X68000 is equipped with hardware sprite functions, but if you’re using 16×16 sprites it can only simultaneously display 128 sprites. The PCG which displays sprites can only define 256 patterns. I knew I just wouldn’t be able to develop a good game with these limits, so I set out to develop a driver that would expand the upper limit.

I called this sprite driver XSP and released it publicly as a library on the Kusa no Ne BBS. I don’t know if anyone wants it, but its available here.

Collision Checking

Multiple simultaneous collision detection was very taxing for CPUs of that time. In order to speed things up, I developed a specialized collision detection system. I divided the screen into lengthwise sections and detected collisions in each area–today we would call it a virtual VRAM system algorithm.

With these methods I was able to overcome the hardware sprite limits and display more characters on screen in realtime, setting me well on my way to actually completing ChoRenSha68k.

The Windows Port

The year after I completed the X68000 version, I decided I’d try to port ChoRenSha68k to Windows as learning experience for Windows programming.

Windows Port – Early Version

I began developing the Windows port during the DirectX3 generation. To be frank, DirectX at that time was a really janky. Because it was lacking support for hardware sprite functionality, I decided to use CPU software rendering for the graphics. In order to speed up the rendering I used things like occlusion culling and all kinds of tricks, eventually somehow achieving graphics at 60fps.

However, recreating the music was another problem. Recreating FM music requires very specialized knowledge, and I was having a hell of a time with it. Formats like mp3 and ogg vorbis were just starting to appear, but I wanted ChoRenSha68k to fit on the size of a single 1MB floppy disk, so I dismissed the idea of using a sound format where a single song would take around 1MB. In order to keep the song data small, I created a MOD/XM sound driver and tried porting the music to that format, but I can’t say the result was a success.

Luckily for me, someone had released the dlls for a x68k FM music emulator they had created, so I used that and was able to port over the soundtrack.

Differences between the X68000 and Windows versions

Unfortunately, there are some subtle differences between the two versions. First and foremost, because the Windows version lacks an internal bug that was present in the x68k version, the replays don’t work correctly in the Windows version. The frame rate is also different between the two versions, with the original running at 55fps, and the Windows version running at 60fps. The Windows port also has no slowdown, making the game a lot harder.

The Music

Looking back on ChoRenSha68k

When I look back on the breakdown of hours I realize I spent more time developing the tools to make the game than I did actually making the game itself. All that time I spent coding the basic libraries to address the insufficient parts of the X68000, the work I did to tame the early Direct X, and the time I spent updating the sound architechture…

Things like the slow CPU speed, lack of memory, and slow networking infrastructure (for the speed needed to download the game by end-users) were all problems that would resolve themselves naturally within a couple years, and there I was writing code to address them ahead of the fact. From a long-term perspective, I sure wasted a lot of time. When developing a game, you always have to think hard about how much time you’re going to devote to clearing away technical obstacles like that. Nowadays I think of the ChoRenSha68k as a good example of how to fail in finding that balance.

As I write this today in 2009, it feels to me like programming environment issues are a thing of the past for game developers. Now that one doesn’t have to be dependent on any special architechture or OS, I think I’d like to try writing a game again, this time in a leisurely fashion (“I’ll start as soon as I get a break from work”… how many years have I been saying this now?)

If you've enjoyed reading this interview and would like to be able to vote each month on what I translate, please consider supporting me on Patreon! I can't do it without your help!