View Full Version : Multiplexity: Space Commando (working title)

09-02-2007, 09:40 AM
Time to introduce my entry for the competition.

The working title is Space Commando, yes I know it's silly, but it'll have to do for now. :D

The game is a hybrid of space sim (shooter) and first person shooter. The players will fly their ships, fight with the enemy ships and dock on other ships and space stations, at this point the game is transformed into a first person shooter.

The gameplay is based on missions that the players have to accomplish, like destroying enemy ships/installations or finding some military documents inside a space station.

I've been working on the game engine for about a week and this is what I've got so far:
A simple space scene with a rotating cube, a skybox and basic camera controls for moving and rotating the view.

I've been trying to put together a team and that has seriously hurt the design phase, I hope to be able to submit the design document before the deadline. :P

09-02-2007, 09:32 PM
I've just submitted my design document, it's not perfect but it'll have to do for now. Time to get some sleep first and then start working on the damn game! ;)

The document can be seen here (http://www.projectminiverse.com/site?node_id=22).

26-02-2007, 03:39 PM
Haven't updated this for a while so here's some news.

Originally I was gonna use as much of the existing code I had already in the game engine, but I ended up in writing almost everything from scratch. Again. :)

I've been busy writing the base code and tools to create content. Finally got my camera code working and I could get started making on the ship controls, the ship will be controlled the same way as in Freelancer, by holding left mouse button and moving the mouse the ship will turn to the direction the cursor is pointing (left - turn left, top right - up and right etc.). Got the basic GUI system with animated mouse cursors and text output capabilities (thanks to Nitrogen's nice library!).

The tools I've made are a simple object editor for importing DMF/3DS/OBJ objects, setting materials and such, the models are eventually saved in a XML/binary hybrid format. Got the particle editor to add explosions and thruster effects and I've started working on the scene editor which puts it all together and hopefully the end result will vaguely resemble a game. :D

I'll probably get the basic game engine stuff working for the next deadline, but there won't be anything that can be called a game yet, but I think that's ok because the stage 2 mentions only a game engine, which I already have, well sort of. ;)

Here's some screenshots:
Level editor #1 (http://www.projectminiverse.com/images/screenshots/LevelEditor02.jpg)
Level editor #2 (http://www.projectminiverse.com/images/screenshots/LevelEditor03.jpg)

02-03-2007, 04:53 PM
Haven't had much time time work on my entry, but here's a snapshot from the current version. You can download it here (http://www.projectminiverse.com/preview/PGD2007_v004.rar)

Please tell me if it works at all in your system. :)

Oh, and there's a nasty bug in it, if you resize the window all textures are lost. Haven't found a way to prevent that yet. :(

EDIT: The readme.txt states that you can rotate the ship with the right mouse button, this is not the case. I forgot to remove that one from the readme file (I used it for debuggin purposes, but I've now removed it from the ship controls). :)

02-03-2007, 06:12 PM
runs nice and smoothly on my machine... there is not much to tell, because there is not much to do in the demo :) But it already gives a good "space feeling".

Sascha Willems
02-03-2007, 06:38 PM
Also running smooth at over 1000 fps on my machine, didn't found any problems except for the resize thinggy you already mentioned. Usually OpenGL only uses textures when the rendering context is destryoed and I heard that SDL exactly does that on a resize, so maybe that's the problem.

02-03-2007, 07:15 PM
Good to hear that it worked on your rigs. :)

Guess I just have to reload the textures after a resize... Not sure if this is gonna be a problem in fullscreen mode though. But there's no full screen mode yet because I haven't had the time to write a configuration program and my ingame UI stuff is pretty much non-existent at the moment. :)

02-03-2007, 08:02 PM
I'm getting around 70fps. Ship movement seems to work fine.

Edit:- Just read the post above about the right button and middle button being removed from the code, but not the readme, so I'm guessing that the rest of this is now irrelevant.

Right/Middle button issues:-

But, the camera control does nothing (unless I'm misunderstanding its purpose - I was expecting it to impact the display). The cursor changes and according to your debug display the camera values (with the exception of Yaw) are changing, but they have no effect on the display. They only hold values when the mouse is moving... as soon as it stops, they switch back to zero.

With regards to the middle button.... I'm assuming you mean the scroll wheel button... if so... it does nothing (I run Logitechs SetPoint which maps the button to F12, so I'm guessing thats why).

02-03-2007, 08:56 PM
It's great to hear that your system runs the game with acceptable frame rate. :)

About the right/middle/wheel/whatever mouse buttons, yes I removed them but forgot to update the readme.txt, sorry about that. :)

For the version I'm gonna submit I've added controls to change the turning and acceleration speed (ie. mass) of the ship. Big ships are supposed to turn and accelerate slowly and small ships very fast.

02-03-2007, 09:39 PM
Just finished the version that I'm gonna submit as my stage 2 entry.

I've added controls (plus/minus keys) to adjust the mass of the ship, it's sort of reversed now ie. bigger value = faster acceleration and turning.

I've also added two spheres posing as the Sun and Earth with the Sun acting as the only light source in the scene lighting all the other objects. The sun looks a bit too much like a Pac-man, but hopefully that'll change. ;)

This scene simulates the maximum load there will be in the space scenes, if you can run this one with a acceptable frame rate then you will be able to run the full game too. I will add some effects to the scene which will need more processing power, but I think that even this version without them doesn't look that bad and it doesn't use even a single shader program. :)

The game engine itself is still unoptimized and I can probably squeeze out a lot better frame rates.

You can download it here (http://www.projectminiverse.com/preview/PGD2007_v004_final.rar)

02-03-2007, 09:46 PM
450+ FPS...

03-03-2007, 01:54 PM
Looks like I still have time to work on my stage 2 entry.

I added a simple configuration program to configure the display settings. Would be nice to hear from those with widescreen monitors about how it looks in fullscreen mode. :)

I also made the asteroids brighter, the texture was too dark and my beta testers complained that they couldn't see them. I'm testing a simple atmosphere effect too on the planet Earth. ;)

Get the latest version here (http://www.projectminiverse.com/preview/PGD2007_v005.rar)

EDIT: Something's very wrong with the fullscreen display modes, the refresh rate is only 60Hz! I can't find a way to change that! HELP!!!

03-03-2007, 02:37 PM
Works good for me. Around 300fps on my laptop. Widescreen seems to work properly as well (1280x800)

03-03-2007, 02:50 PM
The problem with the display settings is following: if VSync is on and I have desktop resolution set to 1280x1024@85Hz, then I try to set the game's resolution to 1600x1200 and I get 60Hz refresh rate. When I change my desktop to 1600x1200@85Hz then I get the 85Hz in the game too.

It looks like you CANNOT control the refresh rate in SDL!

Here's something (http://osdl.sourceforge.net/OSDL/OSDL-0.3/src/doc/web/main/documentation/rendering/SDL-openGL.html) that I found on the 'net:

Windows XP uses 60 Hz as a default OpenGL refresh rate. Setting it to another value is merely a parameter to Change Display Settings, with no easy way to know whether the video card and the monitor support the requested refresh rate, which makes it hardly impossible to put into SDL.

So, it looks like it's time to say "Bye-bye SDL"...

I don't have the time to get rid off all that SDL crap in my code and replace it with some other hack and still make it for the stage 2 deadline, but on stage 3 I won't have anything SDL related in my game engine.

There goes my dreams for cross-platform domination... :D

03-03-2007, 04:17 PM
If you make all movements in the game time based instead of frame based yuou can still use OpenGL and SDL.

03-03-2007, 04:20 PM
I agree with William vgo.

03-03-2007, 05:01 PM
Everything is already time based, I'm talking about the refresh rate of the MONITOR, not the GAME. There's nothing I can do about the fact that 60Hz refresh rate on a CRT monitor is VERY BAD for your eyes, at least I can't watch that for any longer than 10-30 seconds before my eyes start to hurt.

I've already started working on a pure Win32 framework with a frame limiter (rendering is done at a speed of ~60fps and game logic is updated ~100 times per second).

03-03-2007, 08:29 PM
I use SDL and Opengl and it my game works fine.

The refresh rate should have no effect on your game. You can turn off VSync using wgl_swapcontrolext, that way your game will render at the maximum speed it can.

I wouldn't just abandon SDL, it was good enough for Unreal Tournament :D

04-03-2007, 12:53 AM
If you are using OpenGL via SDL, then SDL is not to blame for your refresh rate woes.

And like Dean, just mentioned you can force VSYNC on or off on the software layer with the WGL extension.

04-03-2007, 07:01 AM
I've already almost finished my new framework.

There's some problems with that too.... (What else is new, eh? :) )
On my AMD Athlon XP it runs as it should (60fps rendering and 100fps game logic), but on my AMD Athlon 64 X2 both threads run at ~65fps, which is a bit weird.
I've been trying to set the thread affinity masks for the threads with no luck so far.

09-03-2007, 09:19 AM
Another progress report...

The current version of the "space sim" can be downloaded here (http://www.projectminiverse.com/preview/PGD2007_v006.rar). Additional Win32 executables can be downloaded here (http://www.projectminiverse.com/preview/FrameLimiterTest.rar). Let me know what kind of performance you get and if the game play is choppy. :)

I've started working on the indoor scenes for the game and the engine is going through some changes. I've also written wrappers for Newton based on my old wrappers that I made some time ago for 3Impact (which used ODE for physics). In theory my game engine now supports both. :)

I'm still working on the portal renderer, now that I've solved the problems of sector/portal creation in a modeler I think that I can get the first indoor scene into the game on this weekend.

I've uploaded some screens of the tools etc. in the project gallery (http://www.projectminiverse.com/site?node_id=5) on my site.

23-03-2007, 07:21 PM
My entry for stage 3 doesn't look good, I've been too busy with other stuff, like working on my track car and such.

I was hoping to be able to create the first mission for the game with the tools that I've been making, but I'm running out of time. :(

I'm not giving up yet, I just have to come up with something else in the next 24 hours. :P

23-03-2007, 09:30 PM
One day before the deadline :(
I hope things will work out for you then.

24-03-2007, 09:12 AM
Just to add to my list of problems one of my HDDs just died with a loud CLONK sound... :(

Desperately trying to find the backup image...

EDIT: Found the backup image... On a HDD that I replaced just two weeks ago because it broke down and (what a surprise!) the image is corrupted... Guess I have some reinstalling to do... Not gonna install even a single PC without a RAID anymore...

The HDD that broke down wasn't on my development rig (it has RAID anyway), but on my HTPC which I need for testing the game...

24-03-2007, 09:22 AM
Ouch! :shock:

I hope you'll be able to fix things in time.

24-03-2007, 09:26 AM
I sure hope so. I already got a very simple space station like thing working, it's made of modules that are connected together, now I just need to get the hangar doors opening/closing and write some kind of portal rendering code to draw the damn thing.

24-03-2007, 10:51 AM
I'm looking forward to trying this one out :). I hope you make it into stage 3 :D

24-03-2007, 01:58 PM
Got the hangar doors working, now they open and close on my command. :)

But now I have some problems with the collisions, the doors sometimes freak out and go all over the place... The doors are in small slots inside the station walls and they slide in/out. Problem is that the doors touch the walls all the time and go crazy. :P

I might have to remove the collisions from the doors to make it work, unless someone knows a way to tell Newton that these objects should not collide with each other?

24-03-2007, 02:08 PM
I can't help you with this particular problem, but if it only happens occasionally I'd recommend leaving it in as a bug to be resolved later, and focus on any remaing stage goals you might have.

24-03-2007, 02:26 PM
You need to assign materials to door and wall and provide a collisioncallback for this material pair which does nothing else than saying result := 1 which tells Newton to ignore this collision.

24-03-2007, 04:23 PM
Thanks. I'll put that on my "list of things to do if I have time". :)

I have soooooo many things to do before deadline. Just finishing the scene saving/loading routines, I might still be able to make most of the stuff for the mission in my scene editor. Should be a lot of easier than trying to put everything in place in the game code (too much trial and error for object positioning etc.).

I've written a sort of property wrapper for my base class in the game engine, I can now load/save all object properties to/from a XML file or DOM node, display them on Object inspector (similar to the one in Delphi) and modify them. Makes my life a whole lot easier. :)

24-03-2007, 06:57 PM
What FPS speed is the game supposed to run at? When I tried it out for the Highlights video the space movement seemed a bit sluggish. Then again it could be just the spacing between large body objects such as planets and stars. :)

Mind you the steering was very slow. Maybe some speed-up should be implemented, unless it's just my system running the game slowly. Then maybe it's a LOD issue. *shrug* ;)

It was looking very good though, I wish you continued success. :thumbup:

24-03-2007, 07:44 PM
The movement was a bit sluggish indeed (in some cases). You should try these executables (http://www.projectminiverse.com/preview/FrameLimiterTest.rar) and let me know if they work any better.

It's starting to look like I'm not gonna make it before the deadline... Still too much stuff to get working... Now I'm having trouble with the collisions again, I have no idea why they don't work anymore, in my test bed they worked just fine, but not in the game...

25-03-2007, 08:53 AM
I'm trying to solve the collision problems by rendering the collision geometry, but I just can't get it working. I always get access violation and I have no idea why.

Here's the wrapper class' method starting the rendering:

procedure TPhysicsObject.DebugRender;
if NewtonBody <> nil then
NewtonBodyForEachPolygonDo(NewtonBody, @DebugShowGeometryCollision);

Here's the callback

procedure DebugShowGeometryCollision(Body: PNewtonBody; vertexCount: Integer; faceVertec: PFloat; id: Integer);
i: Integer;
p0, p1: TVector3f;
va: array of TVector3f;
SetLength(va, VertexCount);
CopyMemory(va, faceVertec, VertexCount * SizeOf(TVector3f));
p0 := va[0];
for i := 1 to VertexCount - 1 do
p1 := va[i];
glVertex3f(p0.x, p0.y, p0.z);
glVertex3f(p1.x, p1.y, p1.z);
p0 := p1;

This callback works ONCE and after that I always get access violation when exiting the procedure. Why????

25-03-2007, 03:57 PM
Ok, I figured out that one. I added "cdecl" after the procedure and it worked. It only took me ONE DAY to figure out! :shock:

Now I can render the collision geometry and I can clearly see what's wrong...

What's happening here is that I have three modules that I've positioned to make a space station of sorts, then I created tree collision for them, but the collisions are a bit of... Eh...

In my original test the whole space station was one big static model, but here it's made of 3 separate objects that are connected together, I can move/rotate/etc. it in the editor.

I already figure out that tree collisions are static and it seems that the body matrix doesn't have any effect on them.

The question is: How am I gonna get my moving/rotating space stations and spaceships working? They have exterior and also interior where the player can move around while the ships/stations are moving/rotating. :roll:

If I can't figure out this one then for me the competition is over. :(

EDIT: The green lines in the screenshot showing the collision geometry are in the original position relative to the object center which initially is at 0, 0, 0 but when I move the objects then the collisions don't match up anymore.

25-03-2007, 05:03 PM
If I understand you right, you move your models and your collisions do not move with them. Is this right?

Which is your approach to make your ships moving?

So you move them yourself by rotating and moving them, then drawing them and "hoping Newton will do the same"?

Or do you let Newton do the work and physics and just use the Newton matrices to draw your models?

In the second approch, everything should work fine if you use the Newtonbodys matrices.

In the first approach you need to set the changed matrices to the Newtonbodys by calling NewtonBodySetMatrix.

It's a little hard to help here with no insight of what you are doing...

25-03-2007, 05:28 PM
If I understand you right, you move your models and your collisions do not move with them. Is this right?

I can't move them. I can't apply any kind of force to them and setting the body matrix does absolutely nothing. If I throw in a simple box it works as I'd expect, but these don't work at all.

In the editor from which that screenshot is I've placed the station to the center of the scene (but I don't want it there, in my scenes the sun is in the center and everyhing else is around it). The station is made of 3 models, two cubes and a sort of tube which I've connected together in the editor so that the game knows these are the parts that make the station. These modules have interiors, with walls, doors, windows, desks whatever and I want the player to bump into them too.

The green collision geometry lines show the positions where the collisions would be if I'd just throw all 3 models to the center of the scene, but obviously that wouldn't make much sense, so I've moved them to match the portals (basically a hole in the wall covered with a rectangle telling the game that you can go through this to another module/part of the station) that are used to connect the modules to make a station.

I can't make convex hull collisions for the modules because, as you can see, they are not exactly convex hulls.

Imagine your average Quake3 level flying around in space, that's what I'm trying so hard to do.

For me it seems that the developers of Newton imagined that a tree collision is terrain or your average Quake level that just sits there and the players bang their heads on walls and it does this nicely, I've tried it and it works. But my terrains/Quake levels need to fly in space and collide with planets, spaceships and whatever I can come up with.

25-03-2007, 05:41 PM
You should think the other way.

The way you get your level into Newton world makes your models have the mass = 0, which makes them immovable.

And in fact, there is no reason to let your level rotate or move. You should let the world around it rotate and move! Understand what I mean?

25-03-2007, 06:24 PM
Yes, I understand that, but it doesn't solve the problem of two collision trees next to each other, one of them has to move and I can't work around that just by rotating/moving the world or the collisions won't work.

I have to try that though, if I can wrap my head around that concept. :)
Guess my game engine needs some major modifications too, which may still mean that I'm out of the competition. We'll see...

Anyway, I couldn't even imagine that this would be any kind of problem for a physics engine, guess it's true when they say that Newton is pretty much the worse physics engine out there... Haven't tried any other engine though, I downloaded some and there's mostly just C source which I can't compile and usually not any kind of Delphi headers either.

26-03-2007, 10:23 AM
Time for a compromise. :)

Last night I solved the collision problem by transforming the points manually and then building the collision tree. The drawback is that whenever the objects move I have to recreate the collisions.

I noticed some strange behaviour when I still had the body matrix set and then when I transformed the vectors with this matrix the points were still in their original positions. Newton did some sort of inverse transformation on them. When I set the body matrix to a identity matrix, then the points appeared to be where they should have been in the first place.

Obviously this means that my space stations cannot rotate/move anymore, but I have to compromise to keep things going. Maybe I'll change this after the competition is over...

26-03-2007, 10:33 AM
I don't know your game/gameplay at all, but I don't think that it is really necessary to let the "level" collision tree rotate... it would be very hard to get gravity things working in this case I guess... Did you think about that? I mean, if you are walking withing your station, how will you apply the gravity force to player and objects when you station rotates and moves?

So a still "level" is the best here to make things easier in my opinion. It should be enough to let the camera rotate instead of your level, which will give the same visual result I guess.

26-03-2007, 11:16 AM
Originally I was planning to have one "main" NewtonWorld object which is the scene and the station exteriors would belong to that world. The station interiors would be their own NewtonWorld objects and all inside them would belong to them, I think this would have solved the gravity problem, but I haven't actually tried it (for the reasons stated in my earlier posts :) ).

I'm still planning to have at least two interior scenes for every mission in the game to justify the FPS genre. :)

12-04-2007, 08:46 AM
Haven't worked at all on my entry since my last post. The real life (tm) has taken it's toll.

I doubt that I'll make the next deadline, for now it's not much fun for me anyway, I got enough deadlines in my work already, don't need more for my precious free time.

So, I think I'm pretty much out of the competition then.

12-04-2007, 09:16 AM
If you can squeeze in a final entry that would be better than no entry at all.

12-04-2007, 10:19 AM
I'll probably do that. I'm still working on the game engine and on the game.