Alien Complex Terror (Work In Progress) FPS game


mjohansson

Supporter
Joined
Feb 10, 2011
Messages
409
I wanted to talk about my progress so I decided to make this thread, I will update with new information whenever I have something I feel like talking about.

"Alien Complex Terror" is aimed to become the following:

An FPS game were you go from section to section of a big complex on a foreign planet that has been invaded by aliens.

Each section can consist of up to 5 floors in height and you should be able to travel between them either by staircases or elevators.

In the game you will search for research personal trapped in the complex to rescue, and any items to pickup which will include money

to purchase additional items for.

Multiplayer support for up to 3 players to connect online and play in cooperative mode.

Those are the main goals, I don't have any design document and will not produce one, everything is to be considered possible to change.

And the current status is this:

Rendering mostly designed and coded, have some things to change and add, but things are looking good were the original test ran at 100fps solid on my 600Mhz Pandora, including transparency, and the collision detection is the main threat to the framerate and I think its gonna go just fine right now.

The build is framerate limited to 100fps I don't know what the framerate would have been like unlocked, but it dosnt matter...

Collission detection, its finally shaping up! Ive been working on it for what feels like a loooong time, its probably only been a few days and I don't work all day long either... But I intended for the design to be simple so the collision detection could be quick and easy to do, it turned out to be much more difficult and problematic still and I even considered to just to with full ray traced collision detection... Now that I think of it that might even have been faster to process in the end since theres a billion "if else" statements in the current code... But it finally works so far, which is with the normal walls and you can walk up staircases, to the next floor almost :) Theres more work to be done to complete it but the rest is cakewalk, the difficult part have been done and finally works!

So staircases will be in the final game and thats important, it will add some much needed atmosphere and variation to the architecture really opening the space up. It will also be possible to have open spaces between floors and you could even fall down through several floors technically, but I don't know if thats a fun gameplay element so we will see how maps will be designed in the end.

I have completely forgotten about elevators but I have some idea of what I would want to do, and it should be easy to make it work, the staircases was always the difficult problem, I originally thought I would have to brute force code them but in the end the system I designed ended up to on its own and I can now make staircases wherever I want without any manual labour, they could even have different shape I think, the biggest thing about the staircases is that one stair is above another so you can walk both above and underneath the same surface, there can be many overlaps in height.

Thats about as far as I have come, the basic "engine" is mostly done, or the most fundamental part of it, running around in a rendered world that can be built quickly and easily in Blender and the .obj file loaded by the game directly, I also made a separate program that will process and save all data from the .obj file that is used for the collision detection system in the game.

Heres an image from the test map Im using right now, when I have completed the collision detection and last rendering changes Ill make a new compile for Pandora and see how it runs then, and upload it here if anyones interested to have a look at it.

act1.png
 
Will keep an eye on this and try it out as soon as you release a build. The colors on that test map remind me of some of the Wolf3D levels :)
 
Am looking forward trying it on a external monitor. Controlling it using a xbox360 controller. Just like a real console!


Ohwait
 
Wow what a day... Was gonna fix up the collision detection system a bit quickly I thought, well after I made a new check on Pandora it was major catastrophe, basically nothing worked, turned out I had completely fucked up the framerate processing and measurement.... After I fixed that I saw the real problem, it ran at below 10fps :S

There were some major faults I could fix, I read from many files and processed a lot of data every single frame, and that meant SD card reading on Pandora, but it still can't really handle as many polygons that I use... Every square floor and ceiling piece is 2 triangles, Im thinking that has got to go, Im currently between 20-30fps on my Pandora, I will have to recode the staircase collision detection for getting height and turn off gravity, thats the quickest and easiest solution I think to bring down poly-count on floors and ceilings, that will hopefully at least achieve a stable 30fps, I think I will have to settle for that.

Now I long for the Pyra....

If theres any interest I upload what I have right here and now, this is the latest source code (ah9.cpp) and Pandora build, navigate to the folder were you put in on your SD card and click the "a.out" file in a file browser or if you can find your way in the terminal you will know what to do.

Theres only a single texture I haven't fixed that yet so all walls and everything looks same, and staircase looks funny cos I have CULL FACEs enabled here and I moved the middle (railing) ploys apart to not have 2 or more ploys occupy same space that brings openGL to a crawl always. Things will look much better next time I upload a build, and hopefully run better to... 

Also you can't reach 2nd floor, you will fall down before getting to last platform cos collision detection was turned off for other floors for various reasons, you will probably fall down earlier then second top stair cos if framerate falls below 30 the fall speed will be to big increment for the collision detection to catch it... (roll eyes)

Wow what a day... Was gonna fix up the collision detection system a bit quickly I thought, well after I made a new check on Pandora it was major catastrophe, basically nothing worked, turned out I had completely fucked up the framerate processing and measurement.... After I fixed that I saw the real problem, it ran at below 10fps :S

There were some major faults I could fix, I read from many files and processed a lot of data every single frame, and that meant SD card reading on Pandora, but it still can't really handle as many polygons that I use... Every square floor and ceiling piece is 2 triangles, Im thinking that has got to go, Im currently between 20-30fps on my Pandora, I will have to recode the staircase collision detection for getting height and turn off gravity, thats the quickest and easiest solution I think to bring down poly-count on floors and ceilings, that will hopefully at least achieve a stable 30fps, I think I will have to settle for that.

Now I long for the Pyra....

If theres any interest I upload what I have right here and now, this is the latest source code (ah9.cpp) and Pandora build, navigate to the folder were you put in on your SD card and click the "a.out" file in a file browser or if you can find your way in the terminal you will know what to do.

Theres only a single texture I haven't fixed that yet so all walls and everything looks same, and staircase looks funny cos I have CULL FACEs enabled here and I moved the middle (railing) ploys apart to not have 2 or more ploys occupy same space that brings openGL to a crawl always. Things will look much better next time I upload a build, and hopefully run better to... 

Also you can't reach 2nd floor, you will fall down before getting to last platform cos collision detection was turned off for other floors for various reasons, you will probably fall down earlier then second top stair cos if framerate falls below 30 the fall speed will be to big increment for the collision detection to catch it... (roll eyes)

act.zip
 

Attachments

  • act.zip
    252.9 KB · Views: 245
@mjohanson: for a fps, getting 20~30fps on Pandora is fine, and it will be quite difficult to get more the 40~50fps!

I think your main isue is that it seems (didn't looked much) you are drawing everything at every frame, even what is not on screen. Your drawing loop is fine, because you draw everything using minimum gl call (don't forget to build an atlas when you'll have more than 1 texture for wall / celling / floor).

I recompiled (no Makefile :( ) using GCC 5.0 and agressive optimisation flags (well, standard Pandora flags, not too agressive, but fast-math, single-precision-constant, O3, you get the idea), and I got 2* more FPS ;) (I have a compilation running in the background, and got 15fps with your build, and 30fps with mine, so it seems CPU limited for now).
 
I don't draw everything, in the draw loop I sort polygons to draw from far to near for transparency, there I also measure distance to exclude polygons that are farther away then limit from getting rendered. You can get out of the room and walk away from it, and then FPS goes upwards to 50 I think, but that could indeed be the collision detection easing off CPU burden since polygons also get sorted for testing based on distance... 

I think I can get better result so Im gonna try a new test map with as heavy polygon optimization as possible and change the collision detection system. If enemies will use same collision detection system and it turns out to be the bottleneck then that destroys everything. Enemies should only be processed if they are close enough, but I would still like to be able to have a bunch on screen at once...

20fps don't feel good to me, Im sure I should be able to get a stable 30, for such simple architecture if I don't manage that Im doing something wrong for sure!
 
You should have 2 rendering loop in that case. One for Opaque surface, sorting from Near to Far, and drawing with DEPTH wrting / testing ON, and then a second pass for Transparent surface, sorting far to near (the current one), with Depth Testing on (but not Writing).

I have not tried to Profile yet, I can try to give it a look if you want (I just spent 10 min this morning, not enough to look at the code serioulsy, sory for the shortcut I have took).
 
Looking good, 3D First person games are not that common onto the Pandora, especialy not original ones, keep going! :D

So it's basicly your own engine? Even more impressive. I also tested somt 3D levels with Blender (borrowed fps scripts of course) but lack of talent prevented andyhing above some graphic tests. Blender game engine seems to be also pretty bad performing but for level making it's good enough I guess.

I can imagine thet performance may be a big issue onto the Pandora but with some optimizing it should be possible. I can play Quake 3 compared well on my Pandora, even with Bots and medium graphic settings. Q2 runs even better so the old OMAP 3 still has some potential for such games it seems. :)
 
This is some of the early schetching type of code so don't worry about it, when I have come up with a complete design Im happy with I will clean it up and comment and maybe rewrite some stuff to make it more readable, if anyone is interested in looking at the code, otherwise it might remain uncommented mostly and with cryptic short variable names.

If you sort all polygons theres no need for 2 passes, would the writing of depth be a performance save on Pandora? With this few polygons as well, probably less then 100 in game world thats rendered when all is said and done and I have optimized polygon use...
 
Well Quake 3 was programmed by John Carmack, Im not John Carmack... :)

Yes its my own engine, I find it easier to make my own stuff then trying to figure out (usually failing) how to use any one else's stuff.
 
Well, the separation of surface with transparency (or alpha) and opaque is very important for SGX, So I think it shoul dbe possible to not loose to many cpu cycle and while separating surface type and sorting it (idTech3 engine is doing that in fact).
 
Well Quake 3 was programmed by John Carmack, Im not John Carmack... :)

Yes its my own engine, I find it easier to make my own stuff then trying to figure out (usually failing) how to use any one else's stuff.
Don't worry, even John Carmack only cooks with water. ;) I just wanted to point out that the Pandora is capable for such kind of games. ^^

I have no real gaming coding XP but I made some levels and used a couple of level editors back then and for fun. A well made level can drop the poly count alot, this can also be an important factor for stable frames, beyond the engine skills. Not showing to much at the same time is one example, as long as your engine can done "hidden surface removal" and such things.

I remember that Unreal engine for example can use a technic to separate rooms/areas through invisible "portals" and everything "inside" this area can be hidden if not visible from outside to lower the polycount. It was called "BSP zone portals" afaik. This can be used for an entire level "level streaming" or so.
 
Last edited by a moderator:
Hi all !

@ mjohansson: I don't know if that's related, but maybe you could use "Level Of Detail" in your game. AFAIK, Cube Engine uses such a technique.

And I'm obviously looking forward to playing your game :) Keep up the good work !

Cheers, Magic Sam
 
I could divide up the level in a 3d grid were only polygons in the surrounding grid slots to the one that player is currently inside gets processed, a primitive sort of BSP file I think.

I have some good ideas for things to do next.
 
I could divide up the level in a 3d grid were only polygons in the surrounding grid slots to the one that player is currently inside gets processed, a primitive sort of BSP file I think.

I have some good ideas for things to do next.
Check out Octrees. They're a known technique to organize the world and objects into recursive subregions to speed up everything from rendering to collision detection.
 
Last edited by a moderator:
Don't have the energy to read up on octrees and I suspect its quite the project to implement anyway and this is just a small and quick thing Im doing by the side of other things. But thanks for the tip anyway.

I did some more work today and have changed the collision detection a bit in preparation for new level build, it turned out to work so much better and easier now also, I could still add gravitation I think but Im gonna go without, so you can't fall down from one floor to another, but the staircases work like they should.

Made a quick test for enemy, a 2D sprite that always face the player, that was easier then I expected, I just rotated it with camera angle and it worked perfectly apparently... Previously I have had much more work to do to get angle between character and enemy position and turn it right way adding to that angle and so on, you live and you learn I guess but back then my coordinates were F*UP anyway, I don't know what it is with openGLs built in matrixes and  stuff but they are turned around for Z dimension or something, always have trouble using built in openGL stuff...

I have an idea for how to do elevators, I will try that next.

I have no idea how to make the doors...

Hmmm thinking now about how to make terminals, you could activate doors the same way, when I process polygons for collision detection data I save a collidable wall as a line, so I could just make a line-cross-line test were the length of the line is the distance you can be as far away as max from the terminal to access it, and reuse the collision detection data program but only process polygons that have the terminal texture! That would save some time and effort not having to build anything manually beyond putting together all walls in Blender. And use same system to activate doors, and the line that symbolizes the door can be used for extra collision detection if the door is closed but not if its open! I have to exclude doors from the normal CD program, or I just build a level in several steps, make it for normal CD program then go back and add doors they can even be on a separate file!

Allright thats the most of the fundamental parts, I have to figure out how to do collision detection for enemies also so they don't run through walls.

Im just gonna reuse same system I use for player and it will go as it will go, I really think its the number of polygons rendered thats the main burden anyway, but we will see.

Ill upload a new test build when I have gotten all these things working.
 
Back
Top