R-Type level editor (how old games were built)

[MommysBestGames]

I realize there are several methods to lay out levels, such as spawning enemies based on time, or through distance scrolled, and either hard-coding things or editing an xml-like file, and even using a visual editor... but has anyone ever read how older shmups were actually made--what technique was used?

1. I'm very interested in how collision-heavy shmups like R-Type and Gradius II/III and others had their levels built. Were they made with a traditional, visual level editor? Hard-coded? Timed spawns?
2. Does anyone know how Cave spawns enemies and arranges levels in their contemporary games? Do they have an in-house level editor?
I've been reading the translated R-Type interviews here.. been searching the web too... but could not find anything related to actual development of and building levels for classics like R-Type and Gradius.
I appeal to the collective human consciousness on the forums here for help. Thanks!

[hnns]

http://bizzley.com

A book written by a programmer about converting R-Type to the ZX-Spectrum.

[Laurel_McFang]

While I have not actually read the translated interviews ( would love to though) discovering anything about the early years of Irem is a bit difficult outside of that book on the porting of f r-type. You might try just playing and noticing, r-type at the very least appears to spawn enemies based on scrolling and then gives them some basic a.I. So they know to follow you and went to shoot when you're just in range. How it handles occasionally massive object collision (and for that matter cave) is a mystery. My javascript games have a hard time handling over 10 objects with collision and extremely basic hit boxes. Cave is well known for for incredibly small hit boxes which more experienced players know how to exploit to get through bullet hell. Do update if you can.

[railslave]

I often wish someone had filmed some of the progress in those days

[mice]

I really would like to know this as well.

I'm sure that arcade development differed from the home computer ones.
In '87 PCs were quite powerful so they could host quite powerful editors for this kind of job.
People doing spectrum and c64 games would most likely just use that computer as a developing-platform as well (although I read that Graftgold started using PCs while doing Morpheus) which probably led to the just throwing hex numbers in tables and hoping for the best.

Qualified guessing.

[railslave]

Sonic the hedgehog has some kind of built in editor if you enter the right code, dunno if thats a clue

Actually, my friend made speccy/atari st games at the time, and upon seeing n0rtys level editor for Chronoburst, said that that's how they used to do it.

Make their own level editors. To place stuff in

[ciox]

It seems very likely to me that these games had rudimentary level editors, simply because there are many games around that era for old home computers like the Spectrum which packaged the editor with the game for the user to play with.

If you want to find out how say R-Type did things, then you should just start hacking the rom with MAME and try to make a cheat that stops the scrolling, then you'll find out fast enough if the game uses time or scrolling based spawns.

As for CAVE, there's a guy that knows some things from hacking
http://shmups.system11.org/viewtopic.ph ... 68#p795168 - spawns
http://shmups.system11.org/viewtopic.ph ... 04#p648604 - collision

[Dave_K.]

Cave uses in-house level editors to layout enemy paths. Here is a frame grab from one of their annual report/marketing videos circa 2007.

[MommysBestGames]

@hnns
I'm going through the R-Type ZX Spectrum book to see what's relevant to the original development.

@ciox
Oh, those Cave hack threads are great. I'd not seen those.

@Dave_K
Aha! Very interesting then, thanks.

[RegalSin]

Well, take a look at NES or even PCE dev.

A level editor is basically a string of numbers. on a 8X8 tile, or even 16X16. I was doing some PCE programming, until my project was hindered. Usually each section of the tile, would call to the Bitmap, and look something like 1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4 and so forth. If you look at some pictures of Miyamoto, you can see him drafting a blown-up picture of "Super Mario Bros 3". He already designed the level on paper, and just had to map out each section.

The same thing work with sprites, but sprites, have a little math to them, especially when loading big sprites. Unlike computers that have access to RAM, videogames and earlier computers, had to do a bit of map to make the bigger sprites, no problem for a mathamatician programmer, but for everybody else it is a problem. The sprites are generally smaller ones chained linked together moving with others.

Finally lets, say you want to load a song, or PCM. PCM ( FM, etc ) all had a certain sound language. Many books in Japanese but not in English. That file would be inserted in the middle of the game code. Note this kinda insert in the middle of code, can exsist, over and over again. Like when loading levels.
A code can look like
//****************************************

include
lnclude

varible // ( meaning we designate a random 123ABC>:: etc, or whatever character as an X, Y, 1, or something else )

Mario = 0
Jump = 1
Bullet = Bl

Song = Soft_Music.C

Song2= Soft_Music.ASM

//Then their is if statements, where they can be loops, and else


//******************************

That is what you are going to be dealing with, non-stop, painstakingly as a programmer, if you mess with code. The only reason why you would want to do this is to tap the power of the micro-controller/game system.


The bottom-line with level editors, all you are doing is making a map,

1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,
1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,
1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,
1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,
1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,
1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,
1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,
1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,
1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,
1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,
1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,
1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,1,1,4,4,4,


That will look something like that.

Your PCM music and volume settings will look like this
Your Computer generated shapes ( see Atari programming ) will look like this
Your Level editors will look like this.

The only thing that will not look like this is the player/enemy data.


..........................................................................................

That is how all games are built, you can walk around it. Games today are made the same way but instead the programmer might be a little lazy and get code from the internet. Back then a programmer would store all the code down in Notebooks. No matter what you will run into math.

[n0rtygames]

Make their own level editors. To place stuff in

Yeah, building your own editors makes sense. Fun too.

Easy to extend functionality when you need it and you can run the editor on a beefier machine then just squirt out the data to whatever format.



Mine basically generates code which I then just copy and paste in to the game itself. Can also parse these straight from text files, so in theory - custom maps etc should be doable.

[mice]

...and I'll show you mine.

[railslave]

Oooo err missus....@that second pic


Also wow you guys!! you never fail to raise the bar.

Admittedly I'm not as hardcore as you guys, but I'm developing an interesting spawning system, not really for score but an experiment in making the the most random thing possible , with no randoms.

I have a invisible spawn point that moves back and forth the top of the screen(at various speeds based on player.posy). It reacts to the players behavior, spawning various things based on player.posx ect..

It basically makes the source of the chaos the player himself you are the random element!!!

I would say it can be cracked, but the barrage basically bullies you out of camping.
Anti camping system

All in the name of originality

http://www.youtube.com/watch?v=DWHsXeEWGFQ best seen here <<<<


Also have my patented "wild card" system; another invisible block at the bottom, moving at various speeds that some enemies aim at; So, though some enemies don't use aimed shots, they are in no way predictable.

[nasty_wolverine]

fuck editors, write it by hand, the old way, the manly way.

[Laurel_McFang]

Judging from the surprisingly wide rows and columns in Cave's matrix coding it by hand might not be that hard. Oh wow it just occurred to me object collision must be greatly simplified using that matrix you just have to have to check is __ in row! column and if it shared that row'column then explosion. Which is not quite how Cave games work (hit boxes) but I am assuming they use the matrix to calculate something in terms collision. Anyways, thanks for the read would love to look at the matrix for r-type I am sure some emulator out there outputs it.

[MintyTheCat]

I wonder if any of you have developed Level-Editors for the NES, Master-System or the Megadrive? The problems involved are a little different but one has to question just how the Developers who were making Games 20+ Years ago for those Platforms actually managed it.

[Herr Schatten]

I wonder if any of you have developed Level-Editors for the NES, Master-System or the Megadrive? The problems involved are a little different but one has to question just how the Developers who were making Games 20+ Years ago for those Platforms actually managed it.

At the moment, I'm looking into development for the Master System myself, and I was wondering the same thing. The straightforwardness of the Master System's video hardware would make it possible (if tedious) to map everything on graph paper. I don't really know if anyone actually did that, though. I think even 20 years ago it was quite common to develop on more powerful machines than the ones targeted. Thus, it's quite likely they made their own custom tools like this one one of the homebrew programmers over at SMSpower.org uses.

[mosey]

http://bizzley.com

A book written by a programmer about converting R-Type to the ZX-Spectrum.

Just a general bump for this book, now a free .mobi for Kindle BTW!

[ED-057]

I wonder if any of you have developed Level-Editors for the NES, Master-System or the Megadrive?

I have an editor that I used for PCE, MSX, and GBA dev. It was originally a 16-bit DOS program but since I'm still using it for stuff I got it to compile to a Win32 program. I once had a really basic level editor that I had started to use for NES dev but I can't find it at the moment.

[MintyTheCat]

I wonder if any of you have developed Level-Editors for the NES, Master-System or the Megadrive?

I have an editor that I used for PCE, MSX, and GBA dev. It was originally a 16-bit DOS program but since I'm still using it for stuff I got it to compile to a Win32 program. I once had a really basic level editor that I had started to use for NES dev but I can't find it at the moment.

Is the source code available? It would be interesting to hear how the program handles tile priorites. And such.

The Mega drive/Master-System's Tile-Map has the form:

Priority, palette, v-flip, h-flip, tile-generator.

What is the Pce like?
A
Also, how do you assign the address in VRAM for the tile-map table or is it fixed in the Pce's case?

[ED-057]

Is the source code available? It would be interesting to hear how the program handles tile priorites. And such.

The Mega drive/Master-System's Tile-Map has the form:

Priority, palette, v-flip, h-flip, tile-generator.

What is the Pce like?
A
Also, how do you assign the address in VRAM for the tile-map table or is it fixed in the Pce's case?

I posted source with documentation on my site years ago (in the Enshoku archive), but I don't know if anyone did anything with it and I haven't kept it updated.

PCE has 4 bits for palette assignment and 12 for character address (only 11 bits are actually used, except on PC-FX where there is 128KB RAM per VDC). Priority is handled by putting individual sprites behind the BG or by using sprites as masks to give an opaque area of the BG a higher priority. So my program has a mode for editing a separate attributes map which uses 16x16 meta-tiles and allows placing mask sprites and flagging "walkable" areas and stuff like that.

The map is always at the beginning of VRAM, but the size is definable as 32,64,128 wide and 32 or 64 high.

[MintyTheCat]

Is the source code available? It would be interesting to hear how the program handles tile priorites. And such.

The Mega drive/Master-System's Tile-Map has the form:

Priority, palette, v-flip, h-flip, tile-generator.

What is the Pce like?
A
Also, how do you assign the address in VRAM for the tile-map table or is it fixed in the Pce's case?

I posted source with documentation on my site years ago (in the Enshoku archive), but I don't know if anyone did anything with it and I haven't kept it updated.

PCE has 4 bits for palette assignment and 12 for character address (only 11 bits are actually used, except on PC-FX where there is 128KB RAM per VDC). Priority is handled by putting individual sprites behind the BG or by using sprites as masks to give an opaque area of the BG a higher priority. So my program has a mode for editing a separate attributes map which uses 16x16 meta-tiles and allows placing mask sprites and flagging "walkable" areas and stuff like that.

The map is always at the beginning of VRAM, but the size is definable as 32,64,128 wide and 32 or 64 high.

Sorry, I cannot find your Source on your Website - could you post an URL please?

I see, I have not done anything with the PCE but I'd be interested in dabbling with it if only to compare it to the Megadrive in terms of ease/difficulty as a platform.

[BryanM]

The straightforwardness of the Master System's video hardware would make it possible (if tedious) to map everything on graph paper. I don't really know if anyone actually did that, though.

It was a different era, before DirectX. These days you have a plethora of IDE's (VB, C#, whatever) to toss something together in a few hours, and have it feature complete within a week. But man, even an ASCii editor beats graph paper.

I read that stuff about SMB where Miyamoto would make... alterations... to levels and hand the graph paper to some poor SOB who had to spend all day typing it back in as hex or whatever. Good lord. And when you think about it, that game is brutally tiny, only ~32 levels long.

[mosey]

http://bizzley.com

A book written by a programmer about converting R-Type to the ZX-Spectrum.

Hee hee, Bob Pape replied to me, saying among other things he prefers a grassroots distribution of his book. Cool guy.