Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Harlander]

I've been playing Urban Dead and watching zombie films a lot lately, and I've been not so much struck as lightly prodded by the urge to create a zombie-survival type game. So I'm here to ask for any tips or ideas.

I'm thinking of using Python for the game. I'd been working on a vague idea of a multiplayer Roguelike version of Neverwinter Nights implemented in Python, but I ran out of steam on  that, so I've decided to go for something a little less impossibly ambitious.

Here's a few topics I'm grasping with my cold, unliving hands for info on:

• Line of Sight code. I made a valiant effort at converting a nice looking recursive shadowcasting algorithm to Python, but in the end it defeated me with a quick nested function call to the jaw, and that was that.
  
• Map generation - I'm thinking of setting the game in a town, maybe with a small wilderness area about it, possibly with a view of expanding it to multiple towns and cities. I'm thinking a grid layout, as used in some US cities, as well as UK cities like Middlesbrough, would make things easier to begin with (as well as providing the nice ironic.. uh.. ironicness of humanity's attempt to impose order collapsing into chaos)
  
• Anything else you can think of
  

So, yeah, if you've got any ideas, hints or tips, feel free to send 'em my way.

[Toady One]

Have you checked out the roguelike development newsgroup?  They often bounce around line of sight ideas.  Shadow casting can be fast and fancy (and therefore easy to screw up), but is there any reason not to just draw all of the lines explicitly these days?  On a standard 80x25 layout (or is your town going to be one huge map?), that would only be 2000 lines, and that's with the player having unlimited vision.  I think the algorithm to draw a line between two points was perfected a long time ago, and I have some C code laying around for that (you can find better already written in python no doubt).  I've done it before on some dead curses projects to handle lighting, and the speed wasn't an issue.  It is clumsy though, from an oooo-my-code-is-so-pretty perspective.

I think a grid is fine -- you can always mess around with it after the basics have been completed.

Do you turn into a zombie after you die?  Maybe you can get a pre-zombie and a post-zombie score.

Were you still sticking with the multiplayer bit?  There's often an annoying human on your team that you eventually kill and nobody cares.

[Harlander]

I'm dropping the multiplayer conciet for now. The multiplayitude was the reason I was trying to get a super-fast shadowdrawing algorithm, also I had ambitious plans involving multiple dynamic light-sources, as well as monsters using the LoS algorithm to see if they can see the players and blah blah blah. I figured I'd need to do a lot of casts, so, yeah.

I've got a pythonised Bresenham line-drawer lying about on my hard drive somewhere.. (Wikipedia has a nice space-optimised algorithm for it)

I don't think I'll go for multiplayer on this project, as I said above, but I might do something like a NPC party, with people who freak out, get turned into zombies, etc. etc.

[Toady One]

The monsters seeing the players at least is really cheap -- each one just needs to draw one line through the map on occasion (or every turn).  Zombies probably only look like once every 5 turns or something...  to give them that retarded-yet-dangerous feel, or something.  Unless you are using the fast-zombie idea that's floated around recently.

[Ancient_Sleeping_Dude_Rei]

Do the common thing of nowadays. Plagarize!

Them zombies from HL2 works pretty nice, one that is slow but hits hard, another that is like, uberfast, and climbs on walls and jumps between buildings, and hit kinda weak, and one that is just uberslow but flings nasty stuff at ya.

[Aquillion]

How odd.  I was just thinking what a good idea a game like would be a few days ago...

For the map layout, if possible I think that a 'continuous loading zone'-type map with no borders would be best, at least within a city.  Every wide-area roguelike that I've played so far that divided the area up into screens hit problems with players escaping from monsters on the edges, and that would really kill suspense in a survival-horror game.  Even hacks to allow monsters to chase players between screens wouldn't really help; a 'continous' map would really be best.  It would probably be important have outdoors and indoors locations be in the same map, too--that allows zombies to smoothly chase players into buildings, etc.  In fact, I think it would be best if there were no map transitions, or at least as few as possible...

Even when dealing with players ascending/descending (like with sewers, basements, or two-story buildings), the game could just keep all nearby areas loaded at all times, so zombies could chase the player through the approprate places.  Messages could also be sent if the player sees something above or below.  This could also allow players on the second story of a building to see things out the window or from the roof, and even shoot at zombies on the ground--important if the player tries to stake out a house and defend it.

Have you considered the layout of the town--what players will find there, etc?  Of course, looting is a big part of this kind of post-apocolyptic setting, so there needs to be shopping malls, and gun stores that the can loot for supplies.

Oh, you've played X-Com, right?  Even though you're fighting aliens in that, not zombies, somehow some of the showdowns I had on Terror missions when I staked out a house and held it to the bitter end are what comes to mind when I imagine a survival-horror roguelike.  It also did a very good job with line of sight, deformable terrain, and so forth.

I think allowing the player to damage/change the environment is important.  The player could shoot apart wooden stairs to keep zombies from following, blockade streets with rubble, or blast through walls to enter shuttered shops.  Of course, the zombies could break things, too...  what survival-horror game would be complete without zombies smashing through the windows?

I don't think there's a need for a huge variety of zombies, although there could be zombie animals (zombie dogs, for instance) as well as humans, and maybe some big shambling horror type things.  The main thing I think of when thinking of a zombie flick, though, are the sheer number of zombies; I think a player in a zombie game should be more worried about being brought down by sheer numbers than about encountering some sort of uber-zombie.

Of course, the player is terribly outnumbered in most roguelikes.  Here, though, is another place a 'continuous' world that keeps everything near enough to be important loaded could be useful--if the player makes a loud noise or does something else to attract the living dead, then every zombie in hearing range would descend on them from all directions.  That would probably handle the feeling just about right.

[Harlander]

I'd been musing on how to deal with going into buildings and such.. I was thinking of splitting the street map and the building map into two maps of seperate scale, then just abstracting zombies forcing their way in based on the number in the area when they entered the building, whether or not they knew you were there, and how long you'd spent in the building..

Doing the interior of buildings in the same map at the same scale would lead to a very big map I think. It does make things easier when it comes to entering/leaving the building (whether the player or Zs).. *ponders*

[ October 28, 2005: Message edited by: Harlander ]

[Aquillion]

If you're worried about technical problems, the key would be to find a way to only load nearby areas, but to do it smoothly, so from the player's perspective it looks like everything everywhere is loaded all the time, with no clear-cut transitions and the world extending smoothly over a very wide area.  Divide the game world into sections of a certain size, then decide how many nearby sections you'll keep loaded at once...  For instance, you could just keep the section the player is in and a few adjacent sections loaded.  As the player moves between sections, new ones are loaded or generated as necessary and old ones moved out to disk. This would give the appearance of a world where everything is connected and moving at all times.

If you're worried about it stylistically, I personally think that a realistic outdoors/indoors scale would be a good thing.  First, it's the only way you can allow the players or zombies to significently damage buildings--breaking through a wall, for instance, or setting the building on fire and burning it down.  Second, it will result in a city map with lots of long alleyways with dark corners, entranceways on either side, windows into buildings, and so forth.  This is classic zombie-movie settings...  making the buildings reduced-scale on the outside would ruin it.

Mainly, I suppose my idea of the way a survival-horror roguelike would handle buildings is very much caught up in X-Com's realistic way of handling it...  In X-Com, for instance, stray shots could easily break large holes in a building's external walls.  (Stray rockets, of course, could eliminate entire sides of the building.)  A player who wants to break into a locked shopping mall or escape from a zombie-infested building would want to be able to do things like that.

Of course, a player would also want to be able to look in/out windows and see what's going on on the street outside, as well as firing the occasional shot out; that kind of ongoing combat between people inside and outside of a building is pretty important for the "last stand" feeling. That can't really be done if you make the inside/outside into seperate maps.

(Oh, on an unrelated note:  In addition to zombies, I suppose other humans could be enemies, too.  Crazed looters, soldiers for fascist reconstruction movements, and so forth are other stables of this kind of flick, and let the player have some fights against armed opponents.  Of course, zombies would attack all warm bodies equally...)

[Harlander]

The more I think of it, the more your 'loading nearby areas' appeals to me. It'd help with putting in a fixed scale, too, and with having multiple layers. It's a good idea.

My first idea, and I hope you'll pardon me for using this webboard as a scratchpad, gives a loaded play area that's larger than the displayed area as shown below:

code:

+--------------+ < loaded area
|              |
|  +--------+<--- display area
|  |        |  |
|  |  @     |  |
|  |        |  |
|  +--------+  |
|              |
+--------------+

The display and loaded area would be orthogonal, and I'm thinking the display area would be the size of one map grid.

When you move to the edge of it, the three (or six if you're near a corner) areas that are needed are loaded, while the unneeded ones are cached to disque.

OK, now onto generating the map itself.

A grid, I think, is the way to go. The city's divided into a grid of squares. Kinda like the city in Urban Dead, actually. Possibly roads along the grid lines, with more random roads inside the grid squares. The grids can have different types, like residential or whatever, and that determines what's likely to be in them.

Now I just have to work up the impetus to touch code on this again.

[ October 28, 2005: Message edited by: Harlander ]

[Toady One]

This is how Armok works, and there's one thing to be careful about (you might have already taken this into consideration).  When you load the new areas, your display area shouldn't be the new map grid you stepped into -- rather, it should be halfway between the old one and the new one.  The problem is that if the edge of your new display area is adjacent to your player's position, they can move back and forth in certain locations and get hit by the lag time and other problems associated with the load on every single step.  If instead the new display area centers on the player after the load (though the player is not necessarily in the center of it on the screen itself), it will be a long time before another load no matter which way they walk.  You probably also want to do the load before the player gets exactly to the edge, or else they might get mobbed by zombies immediately or stuck in a dead end they didn't know about without any warning at all.  Dead ends are going to be very scary in this game!

Edit:  What I did specifically --
in the beginning, load all the nearby map squares.  There is no separate "display area"  -- what the player can see is any place that is both loaded and contains the player, at their or your discretion.  Whenever you cross a mapsquare edge, it offloads the far away areas.  When you cross the edge of the dual lattice (the NSEW lines connecting the centers of the map squares), it loads the new nearby map squares.  So loading and offloading occur at different times, and in this way, there is never a back-and-forth place where anything would happen more than once.  It also dillutes the time taken to load/unload into two different steps, so there is less chance of a huge lag.

[ October 28, 2005: Message edited by: Toady One ]

[Harlander]

Huzzah for extremely slow progress! After a while of not doing any work on the game for various reasons (not least the devnull Nethack tournament and extreme laziness) I hacked together a basic city map-square generator.

Here are some free samples! (Shadowcasting is turned off for these screenshots, so you can see the building's stylish modern carpeting)

   
 

As you can see, all the buildings are oblong and fairly uninteresting at the moment, and also don't have anything akin to doors, windows or rooms. But it's a start and didn't take as horrendously a long time (if you don't count the time I spent not working on it) to do as I'd feared.

[ November 02, 2005: Message edited by: Harlander ]

[Toady One]

Well on its way!

One popular way I've seen to create internal structure within a building is to use progressively smaller partitions.  This is what I do in LCS for example.

So you have a rectangle, and then place either a vertical or horizontal wall inside, and put a door in it somewhere.  Then call the algorithm recursively on each of the smaller rectangles, until there's no room left, or until it randomly decides to terminate (never block an old door with a wall).  Then you just need to place an outside door anywhere that doesn't open on to a wall.  The resulting structure is guaranteed to be connected up, since connectivity doesn't break at any step of the algorithm.  You can play with it a lot if the buildings start to look too cookie-cuttery.

Or you can do any of a billion other things.

[ November 02, 2005: Message edited by: Toady One ]

[Aquillion]

A few other questions I've been meaning to ask...

Will you have buildings with multiple floors?  Will players be able to (say) stand on the roof and shoot down at zombies below?  I've never seen a roguelike attempt that kind of solid Z-axis thing in ascii before, but I think it could be done if you darkened lower areas or did something similar; it would certainly add another strategic level.

Additionally, are you going to keep track of the player's facing?  That might seem like a bit of a bother, but it could be important if you want to have a real "horror" feel--players who can see 360 degrees in the traditional roguelike fashion just aren't going to be as frightened.

One way to handle it is to use Gearhead's system.  Basically, you keep track of the direction the player is facing. It takes a small amount of time to turn, but it is normally handled automatically; there are specific turn keys (say, [ and ]) if the player wants to turn manually.  There's also a 'step forward' key, which the player can use in combination with those if they want to move very carefully.

For normal movement, as noted, the player is automatically turned in the direction they want to walk before each step, so they can use arrow keys and such to navigate in a traditional roguelike fashion most of the time without having to worry about facing; normally, they'd just be looking in whatever direction they moved last.

Also, choosing to fire in a specific direction would have the player turn first automatically if necessary, so they wouldn't have to fiddle with turn keys when they don't want to.

Of course, there would need to be a compass of some sort somewhere on the screen to let the player know which way they're facing.  There could also be a height indicator if you have the Z-axis thing.

Anyway, it's just a thought.  I'm worried that the "normal" roguelike way of handling vision might not work for a zombie game.

As mentioned, Gearhead uses something like this if you want to see an example, although not being a horror game it doesn't use it for directional line-of-sight code.

[Harlander]

There's a rough skeleton for going up and down (basically I brutally hacked in an extra dimension on the map array) but it isn't generated, populated or accessible yet. I've yet to work out how exactly I'll handle the visibility.. a simplish way of doing it would be to only do the raycasting on the level the player's on, and any squares beneath the visible squares on the player's level are also visible.

That'd be unrealistic in a few cases, for example, you'd expect a wall far away from the player (at a lower elevation) to hide whatever was behind it, whereas with the simple version, they'd be able to see anything behind it.

I do like the idea of a directional field of view, and it probably wouldn't be too hard to do. I'm familiar with Gearhead's implementation, and it might just work here too.

I just had the idea of giving the zombies directional FOV too.. so if you're quiet, you can sneak around the back of a group of them. How to display this seems a difficult conundrum, though.

Furthermore....

 

[ November 03, 2005: Message edited by: Harlander ]

[ November 03, 2005: Message edited by: Harlander ]

[Toady One]

Is your display real-time or turn-based?  You can handle a lot of the difficult display issues (like zombie FOV) by making things flash periodically.  I put across a lot more info in dwarves in this manner.