Sign in to follow this  

Helping out Salsa & Matt

This topic is 4859 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
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
As you get further into development, you will find other things eat up your time (not specifying the map format, which likely your coder will do his own way, completely disregarding this conversation anyway :P)

On my projects, the main sinks of time tend to be (order may vary):

1) Designing the game as you go.
What do characters look like? What items are in the game? How many baddies are there? (Not simply the game story, which most people come up with well in advance)

No matter how much I work on this ahead of time, there is still alot of figuring it out as I go.

2) Interface... How do you want the user to interact with the game?
Gamepads? Bindable keys?
Will there be menus?

3) Multiplayer?

4) Art! .. stupid details like what is the ground texture going to look like? What kind of lighting will I use?
How should I make weapon/item models (or sprites)?

Anyway, just trying to tease out some real delay-causing obstacles, or project killers.

- Jacob

Share this post


Link to post
Share on other sites
Oh, as far as the game content goes, I am moving in full-gear. The creative portion of the game is no worries; I have my storyline, characters, weapons, enemies, and all of that jazz down. I have concept sketches of all the stations, rooms and corridors, I drew up floor plans, etc.

I'm working on an interface for communicating with terminals scattered about (think Doom 3, only a dialog screen will appear like the old days).

Basically, everything on my end I'm confident about, I just want to gather up as much useful information for my buddy as I can before he dives into this.

Thanks for the helpful information thus far, guys.

Share this post


Link to post
Share on other sites
Quote:
Yeah, and the result just happens to look a lot like a quadtree.

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).

My first iteration definately ended up being pretty much like a quadtree. That's when I scrapped the whole thing and started again. The final design looks nothing like it, and it will be a lot more efficient. I've got over 300 peices of paper and a set of proof-of-concept test programs that say so.

Share this post


Link to post
Share on other sites
Haha, that or I'll incorporate your names into the game in some way. Anyone up for being a lowly scientist killed off by an infestation? =O

Share this post


Link to post
Share on other sites
As for a tip:
Design the game nicely into classes and perhaps even dll's.
Make a small engine.
This way you can expand very easily and adjust to future technology.
This kind of thing isnt too difficult to learn. But only if you do it in the beginning. If you want to add the design half way through then your busted.
-CProgrammer

Share this post


Link to post
Share on other sites
Yeah, my account has secret powers granted behind it.

Anyway, I've collected as much information as I can on the required portions of the game for Matt (programmer) that he isn't familiar with. I've created a handsome list of reading material covering:

1. Portal systems
2. Reading and converting Worldcraft .MAP formats
3. Loading and rendering MD2 models

I have no doubt that he can tackle it; Matt's now a 2nd year student at MIT, and him and I have created quite a few games prior to this (mostly 2D, but also a raycasting game). I'm just trying to gather as much useful reading as I can so he can familarize himself with these concepts.

What else am I missing? A texture system won't be a big deal, as that will be covered in the Worldcraft documents I've found. I'm not familiar with lighting in OpenGL (dynamic lighting, that is), so I'll try and find some information on such.



Take that image, minimalize the amount of geometry (there won't be rigorous amounts of piping and 'useless' artifacts, etc), and change the camera to an overhead position with a dynamic field of view. This is what we're hoping to achieve. As far as the graphics and models go, that's not an issue, I'm working on it now. I'm just concerned with what's required to get it to render.

Can you guys think of anything I haven't thought of yet? Assume the programmer is capable of learning what you need him to.

Share this post


Link to post
Share on other sites
One thing I think your buddy will have to be familiar with is shaders. Knowing how to use vertex and pixel shaders (or at least what can be done with them) is a must IMO. It's not too hard to learn actually. I'd suggest learning GLSL, as it seems to be the best of the high level shading languages right now overall. There's a good introduction video on GLSL at the ATI website from GDC 2004 at http://www.ati.com/developer/gdc_video.html

Share this post


Link to post
Share on other sites
Quote:
Original post by Nemesis2k2
One thing I think your buddy will have to be familiar with is shaders.

Nonsense. If more people focused on gameplay rather than the latest bleeding-edge whizz-bang effect, we might actually get some games with new and interesting gameplay, rather than the same re-hashed stuff. Thats even more true for small indie/hobby stuff, where you don't have nearly as many resources and man power.

One method I used when I started my current game was to just keep the graphics as simple-yet-functional until I actually had some gameplay. Then you can actually find out if your game idea is fun. Only when you've got something worth playing you can start adding graphics.

Share this post


Link to post
Share on other sites
I'm completely spearheading the gameplay dude, and I have no worries about that. Matt's not on the creative end at all, just the engine-crunching. Well, he has his input too, but I can assure you that creating fun factor won't be a problem with me. Anyway, I appreciate the input, but the point of this thread is more about the technical resources I can gather for the engine.

Share this post


Link to post
Share on other sites

This topic is 4859 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.

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

Sign in to follow this