Thread: Updated space game

I've been working a lot recently on the space game I've been wanting to create.

Here is a screenshot of one of the models in flyby camera mode. The cubic environment map for this sector is not done thus the black space. The model has been unwrapped for texture artists but I'm a bit short on um..texture artists.

Right now I'm focusing on getting assets into the game and making sure my new resource system works.

It's come a long way from a year ago. The screenie does not do justice to the rework under the hood.

If you know of any good texture artists that have spare time (hehe right) let me know.

I'd like more information on the rework since a year ago. Also, is unwrapping the model for texturing something done by Blender, or something you did mathematically?

>>Also, is unwrapping the model for texturing something done by Blender

Blender does this. It used to be bad at it but I understand recent versions have improved support.

Originally Posted by Bubba

If you know of any good texture artists that have spare time (hehe right) let me know.

Heh. My 3D Artist hates doing textures too.

Maybe its different in motion, but that screenshot looks like you're moving backwards? The stars seem to be stretching in the other direction. Am I on The Pot? And whats the genre of this game, Bubba? Is it one of those fast action, endless enemies, constant forward motion types?

The genre is the same for that as games like X3, Freelancer, etc. The game is much more along the lines of Freelancer but hopefully with a bit more 'life' to the universe. Gameplay will be pretty much mission based where different mission types will be available from the various stations. Each mission will increase/decrease your relationship rating with different factions and also get you some cold hard cash. Also I plan to have pirates and pirate bases. I really don't want the pirates to jump you nearly as much as in other games b/c it becomes annoying fast.

The main goals for now:

• Add trade lanes to the sector (2 to 5 days depending on how this is done)
• Add freighters that follow the trade lanes and dock at various stations (2 weeks - models take some time)
• Add AI for space combat. I want it fast, furious, and fun. Control of the ship is my number one priority because if it's done wrong the entire game will suck. Also I don't want each encounter to last twenty minutes because that gets tiresome as well. Two evenly matched ships could possibly chip away at each other for about a couple of minutes before one is destroyed. (30 days - this is not a simple task)
• Add modules/weapons/items to upgrade your ships with. (1 week - models and upgrade system)
• Create a basic editor that allows placement of hardpoints on models. Prob use MFC or C# for this. Nothing too fancy. (2 weeks)
• Add static objects to the sector via editor mode (30 days - editor mode is done, all the models are not)
• Implement dynamic object system that will spawn spacecraft correctly

I have design docs but they are too extensive to go through here. The ultimate goal here is to create one complete sector that works 100%. After that I can add more sectors later. But once I know one works the rest 'should be' rather straightforward.

Blender does this. It used to be bad at it but I understand recent versions have improved support.

As long as you place the seams in the right place the model usually unwraps quite nice. I've found that selecting the edge loop in the middle of the object (Y midpoint - Z on Blender) and making it a seam and then doing unwrap usually works very well. I often cut out the engine, cockpit, and other items so that they can be worked on separately from the hull of the craft. Blender gets a bad rep for it's GUI which does suck. As long as you treat Blender as a non-GUI app and just use key shortcuts it actually does quite well.

The stars seem to be stretching in the other direction.

You are looking at the front of the ship. I had another person today tell me it was hard to tell what direction the ship was facing. Perhaps I did not make the cockpit noticeable enough. It is up on the top wing layer and juts out towards the camera. The stars are being rendered correctly in 'this' screenie because this is the flyby camera. I hit the screen capture just before the object flew by.

Originally Posted by Bubba

You are looking at the front of the ship. I had another person today tell me it was hard to tell what direction the ship was facing. Perhaps I did not make the cockpit noticeable enough. It is up on the top wing layer and juts out towards the camera. The stars are being rendered correctly in 'this' screenie because this is the flyby camera. I hit the screen capture just before the object flew by.

Ah, I see. It makes sense now. I'm sure that when textured, or even when moving, the ship will appear just fine.

I'm actually working on a very simular project. Not that I've been able to get at it since basically september when I hit school for my Carpentery Red Seal, but I'll be back at it soon. I'm actually also at a very simular stage. And like yours, I'm sure, screen shots just don't do justice to the amount of work involved in simply reaching this stage in a stable state.

Originally Posted by Bubba

As long as you place the seams in the right place the model usually unwraps quite nice.

I actually don't do my own modelling, thank the gods, as I'm quite horrific at it. But my brother is quite skilled and he churns out what I need at a simular crawl to the pace I'm able to advance the code at.

Keep us updated on your progress. It's making me inspired and eager to return to my own project in a couple weeks when my course is over.

Hehe Perspective picked up on a fundamental flaw. He is right yet I left the effect in during flyby because for now it's the only indication you have that space is well - space.

EDIT:

Problem solved.

When not moving or in a free-float or flyby camera I use a point list on the first half of the vertex buffer.
When moving or in object camera or cockpit camera I use a line list and render the entire buffer with numstars/2 primitives.

The second half of the vertex buffer is computed as I update the first half. This means I only have to iterate half of the buffer to alter the entire buffer.

wouldn't that obfuscate the normals, forcing you to apply the inverse of that skew matrix to each normal during rendering?

Well somebody certainly hasn't eaten their wheaties, out of all of the stuff you've managed to implement I'm surprised you are having troubles with the frustum culling.

For what types of shapes are you attempting to cull, and why do you think it is not working (object is never culled, culled at inappropriate times?)

Once you have the frustum planes built correctly actually culling the objects ought to be trivial, so I'm guessing the math for getting those planes may be the issue (i'd like to see the code). As per how I do it (I got this from tutorials), you multiply the modelview matrix by the projection matrix and extract the plane normals and distances and then you must normalize each plane (which includes 'normalizing' the plane distances!)

I've got the planes for the frustum. However I had another problem that was causing all AABB's to stay in model space which meant an all or nothing cull. Now that I've fixed this issue (a simple C++ temp object error) the other problem is that most algos are for AABBs and I'm actually using OBBs.

What I'm going to do is start with an AABB, transform to get an OBB, and use the OBB to create a new AABB. The culling then will be done using the new AABB. If I take the min and max extents of the OBB I can derive a new AABB without re-iterating the vertices. So far I have not had to actually compute the AABBs from vertex data except once during loading.

And yes to get the frustum planes I get a view-projection matrix and extract from the resulting matrix.

Here is an example with culling off. With culling on it would cull out nearly everything on screen. I'm researching to find out why. I'm trying to get away with only testing 2 vertices in the AABB to determine if it is in or out.