Jump to content
  • Advertisement
Sign in to follow this  
Salsa

Helping out Salsa & Matt

This topic is 5198 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

My friend and I are finally buckling down to work on a game. It will be a locked-perspective 3D shooter (think GTA2), only in a Doom3-esque setting. Basically, traversing dark corridors in a futuristic setting, killing lots and lots of baddies. It will be coded in OpenGL. He's the programmer, I'm everything else (art, level design, characters, interface, etc). I know he can handle it, but I'd like to get as much preliminary information for him as possible before he starts, so things go smoother. So I'm asking for your guys input. :) First, here's an extremely rough "look" at how the perspective would look: As you can see, the sphere represents the character, standing in a very plain "room" with some boxes in the corner to give you an idea. I'm going to be using trusty Worldcraft to create and texture the levels, then we'll just parse its .MAP files later. However, I'd like to know what would be the best way to handle such a game? There will be portions where rooms will open up quite a bit, some rooms will be very high (think: walking along a bridge seeing a void below you, or perhaps a lower bridge you walked across earlier), etc. But what final level format should we end up with, and how should we render everything? Should we just keep a camera floating above our character model looking down always? Should we setup any certain drawing modes? What about Octtrees, BSP's, and all of that jazz? What would you recommend we use in order to keep the game speedy and quick? There won't be a roof on any room, and all rooms will either be connected via a door or hallway. Anyway, I'm probably being vague, but based on my descriptions, can you guys give me all the pointers and tips to consider before my buddy dives into the actual code yet? Things he'll have to consider and implement at some point or another. Thanks a lot. [Edited by - Salsa on August 23, 2004 5:26:49 PM]

Share this post


Link to post
Share on other sites
Advertisement
Why not just making it isometric?
I think that fixed cameras perspective, especially at high angles, look ugly. That's why Eternal Lands it's isometric. For some reason , a 70 degrees isometric view looks much better than an 80 perspective view. Of course, this is my preference.

Share this post


Link to post
Share on other sites
Because this view hides more. The camera isn't very high (but it will move up and down based on the situation), so your field of vision isn't that large. That will be part of the gameplay; not being able to see fully around you, making surprise attacks easier to setup.

Also, while I am going to be creating some extensive textures, less is more. I don't want you to see everything clearly. Anyway, I generally liked the GTA2 perspective.

Share this post


Link to post
Share on other sites
Yes, GTA 1 & 2 were excellent games (even more than GTA3 IMHO, but I disgress).

I suggest you store your maps as a list of objects on that map, and a 2D array containing lists of pointers to the objects. That way, you can easily determine which "tiles" in the array are visible, and draw the objects on these tiles (this doesn't mean your design should be tile-based: if an object exists on more than one tile, make it belong to more than one tile, and make sure your only render it once).

As far as the camera goes, simply keep the camera a fixed distance above the player (you can change the distance if you wish, based on player speed or zoom options).

Share this post


Link to post
Share on other sites
Quote:
Original post by Salsa
However, I'd like to know what would be the best way to handle such a game? There will be portions where rooms will open up quite a bit, some rooms will be very high (think: walking along a bridge seeing a void below you, or perhaps a lower bridge you walked across earlier), etc. But what final level format should we end up with, and how should we render everything?

Should we just keep a camera floating above our character model looking down always? Should we setup any certain drawing modes? What about Octtrees, BSP's, and all of that jazz? What would you recommend we use in order to keep the game speedy and quick? There won't be a roof on any room, and all rooms will either be connected via a door or hallway.

I did something similar ages ago - basically a top-down game with shooty-ness. :) I would suggest that you use a portals to separate rooms into sectors instead of an octtree or bsp. Then you can design each individual room as an entire sector and string them together with the portals. If you're using worldcraft then you can probably define a set of portal textures to indicate the various exits. Note that when rendering you don't just see the individual room, but the portals let you see though them into adjacent rooms as well.

Oh, and probably best to keep individual rooms as 2d (or 2d with height values, like a heightmap) 'cos that'll save you oodles of pain. And you can 'fake' a lot of the depth you need with the portals.

Some good points about this:
- Dead fast to render, no complicated visibility stuff at all really. And no expensive map compiling bits.
- If you want you can make a random map generator that strings rooms together.
- You can define floor and ceiling portals to make one room look down on another
- You can define portals to link to skyboxes/areas to get different skys at different points, or big spooky voids.
- You can tinker with portals to get easy reflection (of the floor or walls).
- You can set the portals up to make tardis-like environments - spaces where the inside is bigger than the outside. Or where you loop around rooms rather than get further away, and other tricks.

Good luck!

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
I suggest you store your maps as a list of objects on that map, and a 2D array containing lists of pointers to the objects. ... if an object exists on more than one tile, make it belong to more than one tile, and make sure your only render it once).

Have you actually tried that? It sounds like a good idea in theory, but in reality it gets painful fast. To maintain it you've got to search though lots of lists to first remove your old references and then add references to lots of other lists. Equally rendering and checking becomes painful as you have to be really careful to only do things once, you can easily get lots of redundant identical checking if you're not really careful.

Oh, and if you generalise it to avoid these problems, you end up with a quadtree. :)

Share this post


Link to post
Share on other sites
Tang is absolutely right. Portals are the way to go with a game like this.

Because you already have it split into rooms, it's the perfect enviroment for PVS. When culling, just check to see which cell/sector/room the player is currently in. Then do a check on all the portals in the room. If a portal is in the current view, render the cell/sector/room on the other side.

Simple, fast, effective.

Share this post


Link to post
Share on other sites
Quote:
Have you actually tried that? It sounds like a good idea in theory, but in reality it gets painful fast. To maintain it you've got to search though lots of lists to first remove your old references and then add references to lots of other lists. Equally rendering and checking becomes painful as you have to be really careful to only do things once, you can easily get lots of redundant identical checking if you're not really careful.

Actually, a lot of those problems can be eliminated fairly easily. I'm using a system where I divide my world into a static grid of cells, where an object can belong to one or more cells (multiple parents). I spent about 3 months developing and concept testing it. Now that it's finalised, I'm so glad I took the time to do it. It allows me to eliminate all visibility determination when drawing a frame. My scene graph knows where everything is. I cast 4 rays from the camera to my grid for each layer, and I can determine which slice of each layer is visible, and ignore the rest. The great thing is because my camera is fixed along an axis usually, like it will be in this case, 90% of the formula for casting a ray cancels out. It ends up being just a handful of operations. It works for a camera facing at any angle though of course.

I only need to do any calculations on objects when they move to maintain the structure, and then it's a single, simplified bounding volume test. Since around 95% of the objects in my game will be static, thst means I can totally ignore 95% of my objects. Collision gets major bonuses, since I only need to test against objects that are also in the parent cells of the object I'm testing with, and my grid is quite tight, so I eliminate pretty much everything except what it probably is colliding with, again doing no calculations at all.

It's still only a concept, I haven't implemented it yet. When I do, if it works out to be as good as it looks on paper, I'll write up an article on it. The only criteria for this system to be effective is for either your camera or your playing field to be approximately bound along the surface of a plane. Height is of course allowed, but it's preferable for it to be reasonably flat. The more random it gets, the less effective the system. It would be ineffective for your average FPS for example, but it's made for games like this one.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nemesis2k2
Actually, a lot of those problems can be eliminated fairly easily.

Yeah, and the result just happens to look a lot like a quadtree. [razz]

Feel free to try it, its definatly a workable system, its just not nearly as efficiant nor as elegant as a quadtree (which in turn isn't as efficiant as some really clever stuff).

Share this post


Link to post
Share on other sites
The camera position should be OK so long as it is far enough up for players to be able to see enemies soon enough. It would be very frustrating to continually be attacked by enemies you couldn't see. Anyway, that system worked well in other overhead shooters. Anyone remember Chaos Engine or Alien Breed?

I also like the idea of the camera being able to zoom in and out, like GTA, so that when fighting/running you could pull back and give the player a better view.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!