Gauntlet Classic

So, I'm putting in initial map/object/tile/etc collision (finally) and ZoriaRPG expressed some worry about performance. Since maps can be huge (for example, an overworld map 64 times larger than FF1 is already doable) this can be a legitimate concern, especially if you are used to stuff like rpg or game maker which is likely to crush your frame rate unless you have a gaming rig. So I thought it would be fun to share a little programming puzzle that you guys can try your hand at. :)

The throwback game which we want to reverse engineer here is Gauntlet:

http://static3.gamespot.com/uploads/...070126_001.jpg

This game ran on 1985 hardware and had ports to the NES and similar systems. Pretty amazing stuff if you think about it. Certainly you couldn't just collide every enemy with every other object every frame?! So.. how'd they do it?


PS:
http://s30.postimg.org/v45ikeiul/screenshot.jpg

Green Elf needs health! *shot*

Also, that pic is from your FF Classic work? (Perhaps to show what it can do in comparison so far to this current predicament?) So many Warriors in there...

As for the Gauntlet question...Not a clue. I can't remember the last time I played that game (its was back on the NES so like almost 25+ years ago) and I know that it has to be some sorta crazy trick or something...

:shrug:

Quote:

---

Originally Posted by Gleeok

This game ran on 1985 hardware and had ports to the NES and similar systems. Pretty amazing stuff if you think about it. Certainly you couldn't just collide every enemy with every other object every frame?! So.. how'd they do it?

---

Gauntlet II had a 68K family CPU running at a decent speed. I'm sure they tried to be efficient about it but it's not a miracle. And on a modern PC I don't see why anyone would be concerned with performance by having a number of NPCs doing things. I think you are right that these concerns come from people with experience with those "DoEverything" game maker programs that try to do everything but don't really do anything very well.

On older systems if cpu time per frame becomes an issue you can try to reduce the processing load by not doing everything every frame but only every other frame or when some key event happens. It all depends on what you're doing but on a modern PC I don't see game logic in a game such as this ever being a serious performance problem. Maybe if you have a whole ton of objects doing complicated things but this just doesn't seem likely.

It's nice to see there is apparently an active project here. I've been trying to motivate myself to work on a project lately but the usual concerns tend to be artistic support.

True. On a modern PC you could just brute force everything and it would still run fine as long it was cache friendly I suppose. 1000 NPCs is still only like 499,500 + n * direction checks or whatever. Nowadays the mentality seems to be about running more threads. I just like how some of the older *classic* games went about solving problems differently than we do today. I think it's easy to take this stuff for granted when you have a gaming PC or PS4 hardware. I don't know, I just find it neat I guess. :)

Gauntlet 1 specs:
Main CPU : Motorola 68010 (@ 7.15909 Mhz), MOS Technology 6502 (@ 1.789772 Mhz)
Sound Chips : Yamaha YM2151 (@ 3.579545 Mhz), POKEY (Pot Keyboard Integrated Circuit) (@ 1.789772 Mhz), Texas Instruments TMS5220 (@ 650.826 Khz)

I'm running a Commodore 64, can I play this? :nerd:

You just need to keep in mind what they accomplished in older games on far less advanced hardware. These days you'd have to be very inefficient or be doing an awful lot to end up with performance issues in a non 3D or modern style game.

Now if you want to keep in mind performance you could consider what I am looking to do. I'm looking to try to put something together that runs on the original Playstation hardware. You get plenty of storage with CD-ROM but you have only 2 megabytes of system RAM and 1 megabyte of video RAM. So you can't just go crazy, you have to manage your memory usage and can't program things in a horribly inefficient way. Unlike your PC where you'd have to be really wasteful to begin to see a problem. I see developing on an old console as both a challenge and something fun to do, not that PC development isn't fun too. Really developing any worthwhile game to completion is a big task.

@MottZilla gets where I'm coming from.

Even in the old days you could do a lot, Remember how shockingly beautiful MYST was? The only problem they had was rendering the damn thing. They couldn't do it in real time.

Gauntlet used a detection grid that held the coordinates of all the player and enemy values, as well as linked lists to handle so many possible enemies at one time. When they overlapped, sharing values, it triggered a collision. I think this would allow for as many simultaneous collisions as actuallly took place.

This is interesting extra material on Gauntlet, but sadly it doesn't have all the information needed to R-E the grid.

http://twvideo01.ubm-us.net/o1/vault...Postmortem.pdf

Page 33-34 briefly covers this.

Gauntlet probably made heavy use of the VBRs. I suspect the 010 was chosen for this reason in particular, to utilise its more dynamic jump tables? I'll see if I can find some more conclusive docs, but I'm unsure if the Gauntlet source is floating around for analysis. It may be though, as a lot of Atari source code was found in bins, and made available, some years back.