Jump to content
Sign in to follow this  
  • entries
    28
  • comments
    110
  • views
    40247

Interior Design for Spaceships

Sign in to follow this  
Poo Bear

1195 views

-------------------------
Poo Bear - Programming
-------------------------

I've spent a lot of time playing old spectrum games, drawing isometric pictures on graph paper and building things out of lego! :)

That sounds bad but it's a necessary part of game design, you have to fully immerse yourself in the genre you are developing and find ways to easily experiment with as many new ideas as possible.

Mr Robot: Lego Prototypes!
Lego is a great way to protype ideas for a game like Mr. Robot
(You can be tempted to start building vast lego castles though [wink])


The editor is really coming on now and i've already mocked up about 25% of the environment. Visualising the internal structure and layout of a huge space station is a lot of fun. Quite tricky at the minute though because lighting isn't finished so everything appears a bit dull and flat, hopefully it wont be long though. It's a bit daunting considering how much there is still to do. You have to put that out of your mind, slow down and just keep making sure you aren't repeating yourself and that what you're doing is fun. No point cranking out game content just for the sake of it, if ideas don't come I don't force it, I just do something else for a while.

I'm also starting to put the games front end together (the menu system), hopefuly it wont take too long as it seems fairly simple compared to Starscape.

Mr Robot: Early Editor Shot
Editor In use (*Note, there's no lighting at this point, the game will look much better than this!!).

-------------------------
Fost - Art
-------------------------
Research
Read Isaac Asimov's 'The Complete Robot' as research. It's actually the first Asimov book I've ever read; even though I seem to have accumulated piles of them over the years, I always put off reading them. I got it into my head that Asimov was quite 'clinical' in his writing, a bit like Philip KA. Dick, but I was pleasantly surprised. The complete Robot collects 99% of Asimov's positronic robot stories and is a highly recommended read. The recent movie 'I Robot' is set in the same world as the stories, although it isn't based on one of them and was an original work.

Production
Mr. Robot artwork so far has been completely dominated by scenery requirements. Poo Bear has been trying to get one zone of the ship completed, and I've been concentrating my efforts on that zone (Storage).
Right now most of the basic building blocks for making a room are complete, and there's just a few gameplay specific objects left to do. A few more wall and floor variants would help too, just to break things up a bit, but I can work on them at a later date.

Mr Robot: Boxes and Crates
A selection of crates and boxes.


Mr Robot: Storage Zone Wall Sections
Basic Wall sections for the ship's storage area.


Mr Robot: Floors and Objects
Floors and Objects

Thoughts & Notes

Model Performance
Model Performance in our engine (although this should apply to most, modern 3d engines using Hardware T&L) relies on the following factors:
  • Keeping the lowest Vertex count possible.

  • Using as few materials/textures within one model as possible.

It's perhaps not so clear cut, but you have to try and work out some rough rules to give your models that performance edge, so I try to aim for low vertex count, single texture, singles material objects - Especially when something is going to be used a lot in a scene (Floors in Mr. Robot).

In some cases we've also found that you can split the edges of a mesh to improve the lighting, yet still maintain the same speed. In the following picture, box 2 has had the edges smoothed off so that you don't get aliased edges where the lighting abruptly changes. Since the mesh would be split anyway to create the extra vertex normals, the final vertex count in both models would be the same.
Model Performance - splitting edges
Of course, nothing is ever that easy, and the model would also have to be 100% seamlessly UV mapped - which is pretty much impossible on a box with a detailed texture map. The principle does work though in many cases, with only a small overhead in memory for the extra face data.

UV Mapping)
As ever, UV Mapping is the bottleneck in my model production pipeline.
My Current UV Mapping workflow goes a little like this:
  • Delete any sections from the model that will be mirrored, or will reuse the same mapping - I find it easier to copy the mesh back into place rather than the mapping, and taking out these sections first reduces the apparent complexity of the model for mapping purposes.

  • Identify large chunks of mesh that can be seamlessly mapped. (The more the object can be seamlessly mapped, the less it will be split on export, resulting in lower vertex counts).

  • Map each chunk at a default scale - Even if I'm mapping a small chunk, I use the same scale of mapping as the rest of the mesh. This ensures the average pixel coverage is the same across all parts of the model, and means that if I need to draw a line that crosses UV splits, it should be possible to make them match up easily. If I'm using a lot of lines and geometric shapes in my texture, it's also worth trying to keep the lines aligned vertically or horizontally (lines look much sharper aligned that way especially if a lower texture resolution is selected), and this may require rotating the UV chunks.

  • Apply a checkered texture to the model (wings3da has a handy feature to do this) and then fix any distortion.

  • Pack all the UVs into texture space - again by scaling all chunks at the (same time so average pixel coverage is the same) until they are roughly small enough to fit.

On complex objects I quite enjoy UV mapping, but most of the scenery is 'boxy' with annoying folds that are a pain to map, so it gets tedious very quickly [rolleyes]

Scheduling
One last thing I'd like to mention this month regards scheduling - I've been consistently underestimating (or just not even allowing time for) how long it takes to export things to game ready status: an increasing amount of time is spent on this in game development, and yet no one ever seems to take it into account. If you are undertaking a game project then scheduling can help immensely. It's worth bearing in mind that the time taken between finishing a model in an art package and getting it to the game as a final signed off piece of work can be roughly one quarter of its development.


-------------------------
Goober - Programming
-------------------------
My time has been spent making the editor for Mr Robot. The initial version was pretty quick to hack together, but it's only until other people start using it do you find (a) your idea of user interface design sucks, and (b) there are a whole category of bugs that you never knew about simply because you inherently know how the code works. So you know not to click on button A, then put a block down because you know that'll bomb the app out. These are mostly under control now, and I'm back to adding features rather than patching up what's already there :)

One thing that has become apparent with this game is that lots of draw calls can be expensive (if you're a developer you'll probably have seen some presentations from nVidia and ATI saying just this sort of thing). The initial implementation of Mr Robot just renders the rooms a block at a time, because that's how the basic rendering system works. This was quick to get working and, while the rooms were small, worked pretty well for a time. Unfortunately Poo Bear has been making some large rooms with lots of blocks in, which means a large number of draw calls. While our PCs can cope well enough, we want to target a larger range of systems, including fairly low spec machines. What I'm going to do is to collate objects into fewer, larger vertex buffers, so the app is sending more data to the graphics API in a single draw call. I'll probably only do this for the environment blocks, purely because they are static and won't need updating while the room is active. Anything dynamic (the player, enemy robots, effects etc) will still be a draw call (or calls if it's rendered in multiple passes) of its own, but there are far less of those types of objects than there are environment objects. This should take the number of rendering calls for the environment down from hundreds (I kid you not) to how ever many shaders are required, probably around four or five in a typical room; a huge improvement.

The graphics APIs have a concept of instancing for just this sort of thing, but they require one of the newer graphics cards to be able to support it in hardware. Unfortunately we aren't in a position to require high-end graphics cards only for our games, so it's of no use to us. The method of repeating data and having large vertex buffers containing multiple objects will work on any graphics card that we want to run on.
Sign in to follow this  


2 Comments


Recommended Comments

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!