Jump to content
Sign in to follow this  
  • entries
    53
  • comments
    225
  • views
    69736

A mansion in the slums

Sign in to follow this  
Milkshake

437 views

Despite journal evidence to the contrary, I've been super busy working on Milkshake over the last few months. Before I get into what I'm currently working on, I thought I'd take some time to write up the portal based rendering stuff I put in while back. (Quick aside for rendering boffins: I call it Portal rendering because the internal class that allows me to create spatial connections between the areas the gameworld is called Portal - not because this is tied exclusively to the rendering concept of portal rendering)

As you might recall from older screenshots, my engine was only ever putting a single "room" on the screen - and consequently, only ever updating a single room of the game at a time. And while there are some (to my mind) compelling gameplay advantages to doing this, I'd always planned to make the engine able to handle large continuous worlds that allowed the character to travel smoothly from sprawling cities down into winding dungeons (besides, I've always fancied the idea of writing a pulp dungeon exploration game at some point).

Anyway, long story short (or at least shorter) I stumbled across a random D&D dungeon generator on the web and it got me thinking about how I could extend the engine to handle this.

Here's a simple example showing single room rendering:

x

Versus multi-room view of the same area:

x


The first thing I ruled off straight away was having a single continuous world space. The bigger a floating point number gets, the bigger its absolute error becomes. Depending on how sensitive your engine is to numerical precision, this will always place some kind of upper bound on how large across your levels/game can be. Given I use a lot of physics and (where possible) like to use numeric approximations for performance, my engine likes its numerical precision the same way I like my VISA bill: small. So a single worldspace is out.

The next option I was keen to explore was the one presented by Scott Bilas at GDC a few years back (and while I think of it - if you're technically minded and ever get the chance to go listen to this guy, I think he's brilliant). In this solution, each cell defines it's own local coordinate system, but at update/render time, the engine picks a "root" cell, and flood fills a temporary world space out to all the connected active cells. This creates a free-floating world space that only needs to handle precision issues out to the visible/active threshold, allowing the actually world to be (theoretically) limitless (and Dungeon Siege's continuous world is certainly a testament to this). To maintain precision, you either have to be very clever about the offsets between cells, or maintain two coordinates for each element (the high precision local transform, and the lower precision world one). Anyway, I was a fair way down this path (including a really cool scheme for allowing multiple free roaming observers to traverse the world merging and separating world spaces) when I realised there was something I wanted that this solution could never support. The problem with even a "local" worldspace is that, with a single coordinate system, every object exists in exactly one place. This means I could never do cool "impossible" things like connect the north door lead back into the east door, or build a mobius strip, or an infinite corridor, or flip gravity around and have a door open onto the floor in another room.

The option I finally went with was a generic "portal" system. In this system, every cell exists, updates and renders in it's own local coordinate system, and it defines the coordinate transforms for each connected cell. This allows me to create entirely impossible networks of rooms (I believe Valve's Portal does a similar thing). After much messing about, I finally got the whole visible scene rendering in a single render pass (e.g. allowing material sorting across cells, a single continuous shadow pass that allows one cell to cast a shadow through a portal into another cell, etc), and (while it's not always the best gameplay thing to do) you can now hook up infinite networks or rooms and run endlessly and smoothly in one direction, while the coordinate system flips and turns beneath you to change the orientation of the rooms you encounter.

Here's an infinite grid made up of 3 rooms (allowing our less than observant cow to shoot himself in the back):

x

Here are two doors that open back into the same room in different places (notice the changes in orientation, and hence projectile velocity, as you pass through the doors):

x

And zooming out, you can witness the awesome power of this fully operational ... umm, here's a zoom out shot:

x

You obviously wouldn't use these pathalogical circus tricks extensively in a real game, but they're certainly fun to experiment with and will hopefully open up some intriguing gameplay scenarios when used a little more subtly.

All of this is keyed off the camera. You can tell one camera to just look at a single room, while another has a bird's eye view of the whole network of rooms. There's also a mode for "real" portal rendering (where you can only see what's visible through the portals) but at this I've only got the culling working and still need to add support for pixel-perfect clipping. You might also notice I've cunningly avoiding creating any walls on the rooms in these screenshots - the other big todo is to add obscuring wall removal (so you can tunnel through the foreground objects and see into the room the character is in).

It worked out pretty well in the end: the object editor I wrote ages ago payed off yet again give me a really nice way to setup even complicated relationships between rooms and portals in the editor, and it feels really smooth storming through a network of rooms. As usual, comments are most welcome!

[small edit: I just realised all the screenshots here are offset out of the frame; looks like OSX windowing code has changed a little with the move to Intel - sorry about that!]

Cheers!
Sign in to follow this  


6 Comments


Recommended Comments

Hmmm, Intel, you say? You got a new Mac? [grin]

It's looking good, although the "many of rooms" screenshot makes my head hurt.

Also, Dungeon Siege handled its precision issues by making all coordinates (room, x, y) where "room" was the current "chunk" of the world you were in, and (x,y) were relative from the absolute centre of the room.

Requires a bit of adaptation, but it seemed to work out very well for them.

Share this comment


Link to comment
I'd been putting off upgrading my old powerbook for ages, so I ordered a new Intel one the day they announced them.

I've tracked the screenshot offset down to a whole bunch'o pixel locking methods that got deprecated at 10.4. I'd been ignoring the warnings because everything seemed to be working ok ... sigh. I wish the Xcode docs would be a little more helpful in telling you how to replace this with supported code.

And indeed, Dungeon Siege added a room to the position of things - but I'm pretty sure it also calculated a world space matrix using that (the slide deck is called the Continuous World of Dungeon Siege" I think - very interesting read, you can pull it off that dudes web site. Interestingly, a "cell" in Dungeon Siege is a single tile! So every time your character walks one tile it rebuilds the origin - yoiks! Still, it obviously works ok.

And I think the headaches you get looking at the room screenshot are nothing compared to the headaches I had trying to get the engine to render them without accumulating so much matrix inversion error that things blew up at the edges =)

Share this comment


Link to comment
Looks cool, and interesting technique. I stared at that last shot for a good while and couldn't see any hidden 3D image. I feel gypped.

Share this comment


Link to comment
This looks great - the videos are especially cool.

For those of us just tuning in, is there someplace we can find out more about the project? Is it just a personal project that you're working on? Who's doing the art and animation?

Anyway, nice work :)

Share this comment


Link to comment
Heya jyk,

Thanks for the positive feedback! And yup - it's just a personal project. At least until I get something playable, it's just me doing everything (or more accurately, with our second son due any day now, doing very little =)

When I have something worth playing, it'd be awesome to team up with an artist or two to really give the game some character ... but given I'm doing this as a bit of fun, I'm really waiting to find the right people to work with - and until they show up, I've got plenty to keep me busy.

There's really nothing other than this journal right now (well, my laptop is full of design docs, but they don't really count) - but if there's anything you're curious about, I'm more than happy to answer any questions.

Cheers!
G

Share this comment


Link to comment
Quote:
Original post by Milkshake
At least until I get something playable, it's just me doing everything...
Well, then that's some pretty good programmer art/animation...

Just be sure to let us know when we can download a playable demo :)

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!