Dead Station

[InfernalKeith]

Okay, I'm probably gonna regret even mentioning it, but I went off on a designing tangent tonight, and I've sketched out the bare bones of what will be a new Extended BASIC game called DEAD STATION.

 

It's inspired by Adamandtyr's Dark Maze game, as well as the Dungeon Key game I mentioned a few days ago. In it, two players (two humans or one vs. computer) each control two robot units. Your robots have been teleported into a "dead station," a space station complex that has suffered a total system failure. Due to the intense radiation, your robots' visual sensors won't work, and even a scan of the station reveals nothing. Each of the bots has been transported into one corner of the station, but you don't even know which robot is in which corner -- only which direction it's facing.

 

To make matters worse, the robots have a finite amount of power, which is being compromised by the high radlevels. Every time your robot moves, or even turns 90 degrees, it uses power. Running into objects drains its strength still faster, and your opponent's robots can leave exploding traps for you, shoot at you, or even start a nuclear chain reaction, all to drain your power. When your robot's power reaches zero, it shuts off and cannot be used or recovered.

 

However, your robots are equipped with crude sonar. You can send a ping in front of your robot, and you'll get an audio cue back depending on if there's a wall, an object, or clear space in front of you.

 

Your object -- to find important artifacts in the ruins of the station, activate the self-destruct, and get your robots to the transporter pods to beam out before your opponent does.

 

The game will feature multiple space station maps, which will load from disk, and the ability to save a game in progress. The computer AI can be set to aggressive (focuses more on attacking your bots) or defensive (avoids your bots, focuses on finding artifacts and completing the mission).

 

Here's a screenshot of one station map, completely revealed. (There are still some game elements missing.)

 

 

But what you'll see when the game actually begins is this:

 

 

You have to stumble around in the dark, using the sonar, for a bit, though encountering the yellow triangles will illuminate portions of the station. I'm envisioning it revealing itself in patches, so you could be in a clear zone, sending sonar down a hallway and listening for audio cues to see if your opponent's robot, or an object you need, is down that path.

 

I literally just started on this tonight, so a lot of the game elements could change as I progress. I'm gonna make a real effort to stay on this and have at least a rough working version of it done sooner than later.

 

Keith

[sometimes99er]

Looks good !

[Opry99er]

 

Looking nice, my man. Look forward to watching it progress.

[+adamantyr]

Sweet! Can't wait to see more.

 

So you're loading static maps from disk? Have you considered doing procedural generation? If you use a random seed value system, you could actually get a static set of maps that way.

 

Adamantyr

[+adamantyr]

Sorry, double-post... got an error while trying to post.

Edited November 2, 2010 by adamantyr

[InfernalKeith]

Sorry, double-post... got an error while trying to post.

 

 

Adam,

 

If you could point me in the direction of where that's been discussed before (because I feel like I've seen it), or break it down quickly for me, I'd appreciate it. My plan for loading game maps in was to allow a map editor and user-customizable maps, and also to retain a "space station" feel. The game could just as easily be played on a totally random board, at least if I include some of the features I'm considering (a laser to blast out wall pieces, for example, which would eliminate the need for clear paths). But a totally jumbled, random map wouldn't look very "space-stationy."

[+adamantyr]

If you could point me in the direction of where that's been discussed before (because I feel like I've seen it), or break it down quickly for me, I'd appreciate it. My plan for loading game maps in was to allow a map editor and user-customizable maps, and also to retain a "space station" feel. The game could just as easily be played on a totally random board, at least if I include some of the features I'm considering (a laser to blast out wall pieces, for example, which would eliminate the need for clear paths). But a totally jumbled, random map wouldn't look very "space-stationy."

 

I think it was in the Beryl thread that I laid it out... I'll do it again here:

 

* Start with a blank map of nothing but walls

* Plot random chambers on the map

o You can either make them fixed sizes or slightly random in height/width

o Overlapping is okay if you don't mind that, but it can make oddball shaped chambers

 

* From each chamber, plot a corridor from the center

o Plot anywhere from 1-4 cardinal directions from the center

o Don't start plotting until you hit the edge

o If a border is reached, change direction

o You'll need some logic for direction random changes, otherwise you may just backtrack on your path and end early

o If another empty chamber or corridor is struck, end the plotting for that direction

 

* Populate items, monsters, etc. in the maze, either totally random or use the center coordinates of chambers as guides

 

For a space station, you may want a more rigid system that makes logical sense. A space station would likely have single narrow corridors connecting larger rooms, and not a lot of overlap. Or, you may also want the rooms to have a more logical order. A main "central" room that is connected to all other rooms. The secondary rooms aren't necessarily connected to one another.

 

Also, why not have pressure locks on each room exit that have to be hacked open? If you have a "room" generation system, you can do some interesting things as well. You have "rad levels" per room so some rooms have high radioactivity.

 

Adamantyr

[Opry99er]

I wrote some code for this back when I was messing with the Roguelike concept, but never got it efficient. I look forward to seeing it in action. Hopefully you go this route, Keith. It'll be VERY cool. I can't think of very many XB programs that do quite this thing. Dark maze and the Helm of Reichardt from the SSGC did it... Quite successfully, I might add.

[sometimes99er]

And so did Chronicle of Sniffing Zombie from the SSGC. I had the routine draw some random mazes, and then noted the seed (starting values for the random generator) when something looked fine. The mazes were then arranged ranging from easy to more difficult. All levels/seeds were then stored in one DATA statement.

Edited November 2, 2010 by sometimes99er

[Opry99er]

Very cool man. I wasn't aware of that. That was one of my favorites from that contest. Fast, friendly, and fun.

[InfernalKeith]

That's a great idea. I hadn't thought to approach it that way, largely because I have this thing for level editors... but given the relatively small size of the playfield, a level editor really doesn't make a lot of sense for this game. I will give this some thought. Thanks!

 

I'm gonna try to get some form of the sonar working tonight -- getting the robot to turn, move and send pings to determine where walls and items are. I haven't done a lot with sound effects in recent times, so just getting a few distinctive tones for the different pings might take me longer than it oughta. If all goes well, at least one bot will be "drive-able" in a blind space station tonight.

[Opry99er]

Hey Keith, are you coding this game on iron? I know you're a traditionalist...

[Opry99er]

Will this be a turn-based strategy type game or a realtime setting? Additionally--- how would two player human play work, given the "blind" element of the game?

 

Just curious. Can't wait to play this game. It might be cool to do two player mode through a BBS... Kind of like computer chess... Make a move, sign out... Let your opponent have a chance to sign in and move, etc. Would be pretty easy to implement the proper data storage for the game...

[InfernalKeith]

The two-player element is essential. Each player sends pings out, tries to get a fix on where they are and what's ahead of them in the station, and makes decisions on whether to use up limited power in moving toward objects (which could be opponents) or artifacts, or even battery packs or light switches. Power is also used up in firing lasers. Getting hit with a laser can damage a bot -- if you notice the status lights at the top, they indicate condition of the robot. Yellow and red condition indicates levels of damage to the bot, and a damaged bot will consume much more power per move. Eventually, if the bot gets down to zero power, it shuts off, and is basically a wall for the duration of that level.

 

It's a turn-based game. My plan is to attempt to build in AI where the computer player can either focus solely on the mission, ignoring you altogether... go after you single-mindedly in attack mode... or a mix of the two. That's all still very nebulous right now, of course.

 

Also thinking about a few special moves, like a one-time "power surge" that can effectively cripple one of your bots, but also reveal a large chunk of the map all at once. Jotting those ideas down to implement later, to see if they screw up gameplay too much.

[Opry99er]

I guess I meant "if you're sitting with someone at a console, how does two player work?". Would one have to avert his eyes so as not to see the other fella's location?

[InfernalKeith]

I guess I meant "if you're sitting with someone at a console, how does two player work?". Would one have to avert his eyes so as not to see the other fella's location?

 

No. Both players have the same info at the same time. I envision someone maybe making notes on paper as they use the pings, to try to deduce a rough map of where they are. Like, for instance, you start out with each bot in one random corner. But you don't know which one. So if you face south, do a ping, and hear four beeps and then the cue for a wall, you know you're in one of the two top corners, and can travel south.

 

Similarly, lit areas of the board could help or hurt both players. If a section gets lit up due to a switch being thrown, it may illuminate your enemy, but not you, and you can move in obscurity to a clear path and blast them. Or it may go the other way. Or it could reveal a battery pack or an artifact right next to your opponent's bot, that they'd have otherwise traveled right past.

[InfernalKeith]

I'm not sure if I'm explaining this all well. The gist of the game, in the beginning of the level, is that you see that empty white blanked-out map above. Neither of you knows where your bots are, only a) that each is in one random corner and b) which way they're facing, as indicated by the status thingie at the top of the screen.

 

When you send out a ping, the tones will tell you how many empty squares are in front of you before something blocks the path. For example, if you're facing south, and there are four empty squares ahead of you, then a battery pack, a ping sent southward would sound like: "beep beep beep beep bonk." You'll get a different tone for a solid wall... but the tone for all objects (including useless junk and enemy bots) is the same "bonk."

 

From that ping, you'll at least know you have four clear squares ahead of you, and can move. Just blindly moving will cost you -- running into walls will burn up more power and potentially damage your bot.

 

Did that help? I'm still in the "thinking out loud" stage on a lot of elements here.

[Opry99er]

That actually cleared it right up man, thanks. Very cool.

 

I'm actually sad that this game doesn't have any hardcore animal cruelty in it. You're lettin me down, Keith.

[InfernalKeith]

That actually cleared it right up man, thanks. Very cool.

 

I'm actually sad that this game doesn't have any hardcore animal cruelty in it. You're lettin me down, Keith.

 

Oh, did I not mention the Nuclear Wombat in level four?

[Opry99er]

Nuclear Wombat.... That a future name for a band?? Cuz that's an album I would buy!!!

 

Okay... A nuclear wombat. My faith is restored.

[InfernalKeith]

Nuclear Wombat.... That a future name for a band?? Cuz that's an album I would buy!!!

 

Okay... A nuclear wombat. My faith is restored.

 

Actually, given the radlevels on the stations, there are no living things on the station. (Otherwise, the name "Dead Station" would be melodramatic.) But among the "artifacts" you find will be bodies of dead crew members.... so you COULD say I've moved on from animal cruelty to actual murder in my game designs.

 

Although, if the stars of Herding Cats are still on retainer while they wait for me to finish that damn game, they're living pretty well. The little bastards.

[InfernalKeith]

Back to actual programming questions, I have something to ask the panel's opinion of.

 

Unless there's some amazing method above my skill set, I've been working on the assumption that the two ways to store the game map would in in an array, or as text strings. I've assumed that text strings would be less memory intensive, and easier to save to disk (for saved games). But I also wondered if the act of manipulating said text strings to effect changes in the map, or to read a few spaces at a time through the use of SEG$ to determine a sonar ping or the path of a laser strike, would be slow as hell.

 

Right now, in its barely-begun form, the map is a two-dimensional array. Each variable is a number corresponding to a map feature: 1 = empty passageway, 2=battery pack, 3=transporter pad, etc. To make the map blanked out, I set all the variables to themselves as a negative number, then draw the display so that IF MAP (x,y)<1 then display a blank white square. Once a section of map is revealed it's a simple MAP(x,y)=ABS(MAP(x,y)) to "turn it on," so to speak.

 

Any thoughts on whether I should stop now and go to a text-string-based system for storing that information, or forge ahead with my DIM'd array?

[sometimes99er]

How about having the map on screen.

 

Let's say you have 16 different objects (including wall). Reserve 16 characters (let's say 96 thru 111) and make them all white on white (call color(9,16,16,10,16,16)). Now you can have a detailed map on screen, but the players will only see all white. This also makes it easy to reveal the maze or certain objects at any given time. Just use call color. Careful planning with character codes and colors though. In Sniffing Zombie, when you hit a wall, the entire hidden maze is shown instantly with just one call color.

 

Edited November 4, 2010 by sometimes99er

[InfernalKeith]

How about having the map on screen.

 

Let's say you have 16 different objects (including wall). Reserve 16 characters (let's say 96 thru 111) and make them all white on white (call color(9,16,16,10,16,16)). Now you can have a detailed map on screen, but the players will only see all white. This also makes it easy to reveal the maze or certain objects at any given time. Just use call color. Careful planning with character codes and colors though. In Sniffing Zombie, when you hit a wall, the entire hidden maze is shown instantly with just one call color.

 

 

I thought of that, but there may be too many objects of one color to be able to reveal them all at once. If I want to "turn on" a 3x3 or 4x4 section of map, and there's a green battery pack there, another green pack may be in a still-hidden part of the map, and I don't want it turned on. If the array approach doesn't eat up all the memory and isn't too slow, I think it's going to work -- I did some more work on it last night and I like how it's coming together, I just don't know how much it's gonna eat up.

[Opry99er]

This would be pretty easy to store in low memory and use a CALL LINK for speedy access to the map. In this way, you could store a giant space station (100x100 or something) in memory and have split second access to it for draws and checks... Or store 8 "screen" levels there if you're not going to randomly generate.