Print

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

[Max White]

Ok, another one of my 'I can think of several ways to do something, and don't know what one to use' questions! This one should be fun for you guys, because I haven't seen this in many games at all, let alone ones like I want to make.

So, I want to make a roguelike. Cool! However, I do not want a single flat, stagnate environment. I want the plane you walk on to exist in a way that emulates three dimensions, without working in three dimensions, and without using z levels. This is sort of tricky to explain because I can not think of any games to reference to here. So, lets say for example, you follow a hallway east, then turn north, walk a bit, turn west, walk a bit, then follow the hall south. Normally, in many RL games, you would have to cross over the eastbound path to continue south. But I want a game where it is like you were going down in a spiral, so without going down clunky stairs, you have moved downward. Or at least it seems like you have moved downward.

I also want this system to extend to 'rooms' so to speak, in the way of making it seem like you are moving inside elevators and trains. You walk into an elevator, press the button to go up, the doors close. Then ninjas drop from the ceiling, you kill them all, and the doors open again to a brand new floor.

Now there are two ways I could do this. The first is between frames, clone the visible tiles and make a brand new level, so although the player has been 'teleported' to an entirely level, it looks the same until they start wandering around, such as leaving the elevator. The other way is to build the level in chunks, so while the player is inside the elevator chunk, and the closed door stops them from seeing outside, I can switch out the chunks for a new floor.

Did that make sense? I hope so. What seat should I take?

[MaximumZero]

Sounds like the second option would probably be the easiest to go with and the most effective for what you want. Another thing to think of would be to make stairs and slopes auto-activate, so that you don't have to button press them.

[Starver]

If I understand you correvctly, the way I would do it[1] is to have an 'invisible' Z-height.  It all comes out flat, but when a tile connects to a different-Z you could apply a subtle shading effect across the tile.  You'd only see one tile on a given x/y location, and use some simple LOS-rule to work out which one, in the case of (say) a spiral-ramp, with apparent borders between tiles actually disconnected on different Z-levels (not by wall, but by transitioning to different 'underlapping' neighbours) being indicated where the up-a-bit ramp-like tile is lighter but the down-a-bit ramp-like is darker.

I really need to construct a picture to describe that.  Maybe later when I've got time to mess with a paint package.

[1] Did something similar with something which was a bit more esoteric, and (shall we say) non-euclidean...

[Virex]

I would use an analog of a doubly linked list for the tiles. Each tile has a link to all it's neighbors (usually 4, but you van use any number, for example 5 for conventional staircases). This essentially works similar to your second idea of chunking the level but taken to the extreme.Walking down a spiral staircase or up a conventional staircase would cause the player to enter the cell which to the player looks like it's on another Z-level, but to the code it's exactly the same as moving left or right. This does mean you'll have to hand-code LoS code because most if not all libraries assume you're using arrays. Pathfinding libraries for grids should exist though because it's similar to a link-state routing problem. Besides, pathfinding across Z-levels and through portals should even become simpler with this system, because they're handled in the same way as normal movement.

[Siquo]

Oh, I know a roguelike that does that! It's very irritating! 

*looks it up* Ah, it was called "Vicious Orcs".

[Virex]

Hell, you could even make a completely non-euclidean roguelike to mess with the players even more

[Nadaka]

Hell, you could even make a completely non-euclidean roguelike to mess with the players even more

You need to be very careful when you throw the lever that changes the local direction of gravity.

[olemars]

Okay, I turned x and y into floats, now the code looks like this:

Code: [Select]

snipt
The wave looks funny at the start, then I get a normal sawtooth-ish shape, and then at some point the frequency increases. Decreasing x's increment seems to make that happen faster.

Spoiler: The wave (click to show/hide)

You could plot each contribution individually to see how they behave.

[Virex]

Okay, I turned x and y into floats, now the code looks like this:

Code: [Select]

...

int main (int argc, char **argv)
{
     float x, y;
     FILE *f = fopen("./bitmap.dib", "w");
     canvas c =  make_canvas(1024, 128, WHITE);

     for (x = 0; x < 1024; x++) { /* x axis */
      y = 64;
      draw_pixel(x, y, c, (RGB){128, 128, 128} );
     }

     for (x = 0; x < 1024; x += 0.1) {
      /*
         y = A * sin( wx + p )
         w = 2 * pi * f           */
      y = 32 * sin(2 * M_PI * 110 * x) +
           16 * sin(2 * M_PI * 220 * x) +
           8  * sin(2 * M_PI * 330 * x) +
           4  * sin(2 * M_PI * 440 * x) + 64;
      draw_pixel((int)x, (int)y, c, BLACK);
     }
     write_bitmap(c, f);
     return 0;
}
The wave looks funny at the start, then I get a normal sawtooth-ish shape, and then at some point the frequency increases. Decreasing x's increment seems to make that happen faster.

Spoiler: The wave (click to show/hide)

The higher your sampling rate, the closer the plotted function should mimic the behavior of the real function. As a mater of fact, unless I am misunderstanding your code, you shouldn't be able to sample the formula with a frequency of 10 Hz because the wave has a frequency of at least 440 hz (so your sampling frequency has to be at least 1/880 and likely more because that's going to give you a sawtooth no matter what). Also you're casting the x to an integer, meaning there's no way you should be able to even see a waveform, because the distance between the waves should be less then a tenth and as a result you should get a band instead of a sawtooth. The waveform you see, with it's changing behavior is most likely because you're seriously under-sampling your formula.


Edit: just tested it with matlab. This is what you get with a sampling frequency of 2000. As you see, it's a pretty nice sawtooth. this is the same figure, but now with a sampling frequency of 200. You can clearly see the effects of undersampling.

[alfie275]

Max, you need to think with portals!

[ILikePie]

snip

So it does work, nice. draw_pixel plots a pixel on a bitmap, so I can't really pass fractions as coordinates (and I really don't want to rewrite libDib to support vectors, rasterisation or whatever). I'll try writing the wave (properly sampled this time) to a wave file and opening it with Audacity.

[Virex]

You could go the other way though. Say you want to plot pixels in the range 0 to 0.01 and you have an x-resolution of 1024. You then compute 1024 values of your function between 0 and 0.01, then plot them on the screen using not their x-value but their place in the sequence. Some pseudocode:

Code: [Select]

Plot_function(function, minX, maxX, resolution, color, canvas)
for i from 0 upto resolution with step size = 1
   with x from miniX upto maxX with steps size =   (maxX - minX)/resolution 
   do draw_pixel(i, function(x), canvas, color)
return canvas

[Max White]

I would use an analog of a doubly linked list for the tiles. Each tile has a link to all it's neighbors (usually 4, but you van use any number, for example 5 for conventional staircases). This essentially works similar to your second idea of chunking the level but taken to the extreme.Walking down a spiral staircase or up a conventional staircase would cause the player to enter the cell which to the player looks like it's on another Z-level, but to the code it's exactly the same as moving left or right. This does mean you'll have to hand-code LoS code because most if not all libraries assume you're using arrays. Pathfinding libraries for grids should exist though because it's similar to a link-state routing problem. Besides, pathfinding across Z-levels and through portals should even become simpler with this system, because they're handled in the same way as normal movement.

Sounds very sexy! I think I could do that.

Oh, I know a roguelike that does that! It's very irritating! 

*looks it up* Ah, it was called "Vicious Orcs".

Now was it annoying because if the lack of z levels? I will need to get that game and play it a little.

Max, you need to think with portals!

No, you see portals have a more definitive local where you cross them. I want people to not know they have genned a new part of the map. Unless that was a witty reference to the first proposed method. 

[qwertyuiopas]

Valve made completely unnoticable arbitrarily shaped world portals. You couldn't see them, because it used portal technology to just about perfectly join two planes together. They used it mainly for testing map order without having to move everything around, but there is exactly one pair left in game, and a commentary node challenges you to try to find it.

Someone made a TARDIS with it.

[Starver]

I really need to construct a picture to describe that.  Maybe later when I've got time to mess with a paint package.

Right.  I had a little mess with Google's Sketchup[1], then I reverted to GIMP to actually put together the 'game-views' I wanted

...darnit TinyPic, why are your CAPTCHA challenges so hard..?  and why are you complaining about some of the .pngs, when they're all edited with the same application?  Well, maybe it's for the best that I don't post every single image I made...

Spoiler: Images (five of 'em) and a bit of explanation. (click to show/hide)

So, there's the following 'world'

It shows just the tiles (no walls, save that there is no connected tile), and the sloped tiles have the slopes left on the edges to make them obvious (while, apart from under the 'figure of 8' part, I've removed all other inter-level connecting lines).

Seen as a plan view, some points share tiles, and paths loop around so much more than the simple plan might indicate.


But if "current height" is given neutral grey, higher heights go whiter, lower heights go darker...  This is an analogue to something else applied to textured tiles (could be saturation of the tile graphics, could be (pre-full3D) GTA-ish resizing of flat-tiles to emulate a top-down-with-perspective).  Starting at point 'A', you see.

(Notice the 'fudge' where two equidistant tiles (purely by path distance) are shown by giving each a triangular-slice (whereas the tile directly above 'A' is not shown because it would over-write a known square).  Perhaps a "higher tile bias" might be better.  Or worse.  And I'm not making any LOS-type calculations at all in the presentations of these images.)

Moving to point 'B', you can see the neutral shade moves with the 'B' point.


And if we go up to point 'C', the deeper levels fade into the black background.

(Conversely, the other images I have for points G and H have the upper reaches bleach-white and I put in a shine-effect... In reality, however, it'd probably be considered beyond the 'fog of war' rendering point.  Or the 'greyness' (or equivalent effect) could have been normalised to allow all actually visible elements to scale their 'off-Z' responsiveness.)

As to arbitrarily shaped portals, not sure about what Valve did, but I had a mess with a similar engine of my own (a long, long, time ago) that was intended to implement... shall we say "cartoon physics".  Tunnels that are only painted on for some agents (AI or human) within the game.  Run through an initially large pipe that on the outside becomes visibly smaller, and you exit at a smaller scale from the other end.  Or the "movable knothole" thing that short cartoon cowboys used to pull down to shoot through.  I reckon that's trivial to deal with, these days.  Indeed, I remember designing Doom levels, back in the day, with maze-tunnels that technically occupied the same space (including in the vertical axis), but because of the way the game engine dealt with LOS you never noticed anything strange going on.  However, it meant I could also arrange (around a central column to fudge away the disconnect point) a game-space with a rotational symmetry of 1/2, 1/3 or whatever...   That was fun to unleash upon my fellow Doomers, especially when the entrance to the space was via a split-doorway where each half led to a different part of the cycle, and if you were chasing someone and happened to take the other part of the doorway, they looked like they'd disappeared...

[1] Been meaning to give it a go, so downloaded it just before I left work.  Ok, so for the first hour or two at home I remodelled my workplace plans that I've been fiddling with...  and then got used to some of the peculiarities of the package (should have stuck with my regular CAD program, but no point repeating the exercise, now), but eventually I got around to dealing with this particular problem.