UFO:Alien Invasion
Development => Design => Topic started by: Destructavator on June 13, 2012, 09:56:24 am
-
EDIT: The updated version of the demo (version 5) is at http://www.destructavator.com/ufoai/terrain_test_5.7z
EDIT: The updated version of the demo (version 6) is at http://www.destructavator.com/ufoai/terrain_test_6.7z
Note: The download is just under ~70 MB, and the pre-compiled Windows version (built for 32 bit) requires SSE2 (which shouldn't be a problem unless you have very old hardware). It also uses OpenGL, and as such I'd recommend using the latest graphics drivers direct from the manufacturer (NOT Windows Update) for best performance.
EDIT (again) Please also look at: http://www.destructavator.com/ufoai/TigersEye1.7z
and http://www.destructavator.com/ufoai/TigersEye2.7z
Sorry, I used the wrong compiler, the working version for 32-bit is at: http://www.destructavator.com/ufoai/TigersEye3.7z
-- For reference, on my several-year-old Dell desktop (i7 CPU, 2.67 GHz) with an almost-as-old Nvidia GTS 450, I can run most terrain selections in the demo at full screen with anti-aliasing cranked up all the way and get around 150 to 190 FPS while viewing most parts of the generated terrain and objects in the demo, using Windows 7 HP. Also, the demo is not currently multi-threaded, right now it is built to use just one CPU core.
The technical, coding thread on this is at: http://ufoai.org/forum/index.php/topic,6772.msg53968.html#msg53968
OK, I've been working on developing code and stuff for a new system for air combat / interception.
It'll work in a 3D environment, and unlike the battlescape all aircraft and things will move and fight all at the same time, although the speed and pause controls from the geoscape will still be available - in fact the player won't leave the geoscape at all, it'll all take place in a custom UI node on top of the main geoscape view.
As I picture it, if the combat starts with the player's aircraft chasing the UFO, the UFO will start in the center of the map, with the Phalanx aircraft at an edge, approaching the UFO. If the UFO is coming after a dropship or player craft, this is switched, and if both are coming at each other, all opposing forces start at opposite edges of the map.
The biggest obstacle I ran into was trying to get background terrain - I needed to code something that could quickly (with an optional seed value) generate background terrain that wouldn't leave the player waiting a long time, and also be displayed as a 3D model in the scene graph able to be rotated and moved around in realtime.
I've worked hard on this, and I've now gotten together some terrain generation code that can do these things in a work-able way.
Don't expect anything photo-realistic like Terragen 2, that wouldn't run fast enough for realtime animation for a video game.
The code I've written isn't fully complete, but could generate different types of terrain for various areas on the map, so arctic terrain would be made over Antarctica, mountain terrain over a mountain region, etc. It could also make lunar or alien-world terrain.
Oh, and any aircraft that pass beyond the border of the generated map would be considered to have escaped combat (for the moment).
The code I wrote also retains data for each spot on the terrain, so when a UFO is shot down the game will know if it fell in a lake, on some trees, on a mountainside, etc. This information would then be passed to the battlescape, so a ground battle in a matching map would occur.
I also plan to extend this to generate buildings, cities, trees, etc. and place them on the terrain.
Right now, if anyone wants to demo the terrain generation, it is currently compiled to run with 64-bit MS Windows, using OpenGL via the Irrlicht 3D Engine (also on SourceForge), just for a quick demo. If you can run it, use the cursor arrow keys to move around and the mouse to tilt and steer to move around the landscape. Use the usual ALT-F4 to close the program.
For the technical side, this code generates and writes WaveFront OBJ model files of the terrain, water plane, and other objects. It also generates a texture map for each, and the texture pixel data, although it doesn't include any PNG writing library of its own, but has get*() functions for getting the data.
I kept this version of my code very general as I intended to use it in not only UFO: AI, but also other games and programs. For UFO AI I plan to modify the code and extend it to feed the generated terrain directly into memory instead of a file, as well as the texture, and of course render it with the game's engine, not Irrlicht.
You can download the demo at http://www.destructavator.com/media/terrain_test.zip .
EDIT: Look at the top of this post for the latest download.
-
I forgot to mention that if the UFO AI graphics engine could support a "detail map" texture - via a second texture on a model with different texture coordinates, something like what is in this screen shot would be possible, which would look nicer.
-
Destructavator is back yay! Cant believe my eyes - GIVE ME INGAME - NOW! Awesome Awesome Awesome!!!! Will post a news on IndieDB about that!
-
I've put an updated version on the server for my website.
This one is compiled to work in 32-bits, so nearly any Windows user with OpenGL capabilities on their machine can try it. I built it with 32-bit MinGW, TDM build, so it should be easy to recompile for anyone who knows a little programming.
There is also an import .a library (for Irrlicht, which is needed for the demo) for Linux users - I didn't have time to build a Linux binary, or a makefile, but if you run Linux and know how to compile stuff you could probably figure it out with the source files.
Note that Irrlicht is seperate, my own code does not depend on it, it is only used in the demo to display the created models on-screen in 3D in a window and allow the mouse and arrow cursor keys to move around. My own code for the terrain generator just uses a few basic standard libraries from C++ and could be plugged into nearly any graphics or game engine.
If anyone has trouble running the demo, one can also load the OBJ and texture files in Blender or another modeling program. Depending on what engine my code is put into, the Y-axis of the graphic textures that are generated might or might not have to be flipped.
If you're playing with the source code, you'll notice I no longer have it all stuffed into one almighty header file, it is now broken up into multiple .cpp and .h files, all of which are in the terrain folder under ./include.
I'll mention a few technical things in the coding section of the forum.
-
I posted a news on IndieDB (http://www.indiedb.com/games/ufo-alien-invasion/news/improved-air-combat). Ppl already commented it. :)
-
After a lot of hair-pulling, cursing and swearing, and frustration I finally got my new terrain code to work better and include dotting objects all over the landscape.
I've done quite a bit of work on it and have improved many parts of the code for it.
Right now, it just sprinkles trees, which only have two main varieties: A standard one and a snow-covered version of the standard one. The generator algorithms and maths help decide which version to put in a spot based upon the terrain there.
Yes, the trees are very basic, very simple and crude-looking up close, but they need to be that way to run the terrain and objects in realtime.
There is a hard-coded index limit of just 16 for every model sprinkled on the landscape, whether it is a tree, rock, building, alien launch pad, whatever. This is to keep the whole scene running fast enough on most computers for realtime. What this index limit means is a max of just 16 verts, 16 faces, 16 normals, and 16 texture coordinates (as per what the OBJ format allows) for every little model sitting on the terrain.
Of course, that 16 limit does not apply to additional models independent of the generated terrain, such as aircraft fighting in the sky above or around it.
I'll upload a new version of the stand-alone demo app for people to play with in a few moments. It currently can create ~4 to 5 different basic terrain types, which is a fraction of what the code supports (I have not configured the parameters for other terrain types yet).
Note: The textures on the terrain objects are a different story, they can be detailed graphics if desired, right now the trees share a combined texture map image that is 1024x1024 pixels, but the vertex count and number of faces are the real limitations in the code. So if anyone wants to contribute very simple models to put on the terrain, go for it. I can especially use man-made buildings and structures and such, as well as alien design, for UFO AI.
Finally, I'd like to point out that the object generation can be controlled via parameters for changes in density according to altitude, whether or not the object is above the water plane or not, etc., as well as clumping and clustering of the objects. Each parameter "slot" in the code for the map can also repeat the same object type (or of course mix different object models) with different values, as well as scale and size factors.
-
:-O
awesome!!!
-
Holy Crap!!!!!! I dont know what to say. I just cant wait to see the first airfights in the new render...
-
Some insignificant incompetent personal opinions:
* The trees are way too large at the moment an could be omitted, or at least colored so that they are less visible.
* The ground could as well be plain color that depends on height from sea level (rather than texture), maybe a city could be a texture with some gray crossed pattern.
* Breaking up battles at edge of map rather than at some range is probably going to be annoying either at chasing or else at escaping, though maybe the fast-forward-time will be helpful.
As I understand, my interceptor would need to be twice as fast as the UFO to have any chance of catching it.
It would be nice to have:
* Fog and cloud effects, maybe even wind but that is probably negligible.
* Night with some lights on the ground + whatever aids pilots use not to crash at night.
* Unbounded terrain even if the terrain would need to be MUCH simpler, and starting/ending battle at some range.
It is certainly more awesome than the current UFO:AI air battles, though, so I am not really negative about it like this post might have sounded, but excited rather.
Especially that it takes into account the actual terrain on the geoscape (as I understood what you wrote).
The standard aircraft (dogfight) maneuvers are planned?
-
terrain_test_5.7z doesn't open in the last version of 7zip (9.20), claiming that archive is damaged. Investigation shows that file ends with a long train of zero bytes instead of data. Tried to redownload it, result is the same.
-
terrain_test_5.7z doesn't open in the last version of 7zip (9.20), claiming that archive is damaged. Investigation shows that file ends with a long train of zero bytes instead of data. Tried to redownload it, result is the same.
I'm not sure what happened there - I tested the link myself and surprisingly ran into the same problem - but I've uploaded a new archive. Please let me know if version 6 unpacks and works OK for you.
-
A case of gremlin infestation, I suppose ... Anyway, this version downloads and works for me. Will check the code later.
Quick suggestions: yes, detail texture is desperately needed and you should consider using more realistic colors already (just colorpick them from some photos after blurring). Also, some sort of fog/haze could be used to add visual depth -- scene is supposed to be a few kilometers deep, no?
Even more, if you can make generator to be fast enough, there will be no need to exit combat when leaving the tile; just generate extra one (or two, or even three which is the worst possible case) and continue. Actually, you will have to keep a 9-tile cache and update it as the dogfight moves from one tile to another.
-
...Also, some sort of fog/haze could be used to add visual depth -- scene is supposed to be a few kilometers deep, no?
There should already be some type of OpenGL-based fog effect for distant parts of the terrain, as seen in some of the screenshots in this thread. I already programmed that in, although I'm not sure exactly how the Irrlicht engine implements it - It might be possible that Irrlicht was trying to make the fog happen with a method that doesn't work as well with your graphics hardware as well as it does with mine (likely the engine's fault, as it is a development trunk branch of Irrlicht, or it could just be your default OpenGL settings for new applications - I know that Nvidia drivers, for example, often mistake many applications and even UFO AI as being totally different programs by mistake and then apply the wrong 3D display settings).
Regarding terrain colors, those are easy to change.
Even more, if you can make generator to be fast enough, there will be no need to exit combat when leaving the tile; just generate extra one (or two, or even three which is the worst possible case) and continue. Actually, you will have to keep a 9-tile cache and update it as the dogfight moves from one tile to another.
Yes, that's a workable idea.
----
BTW, I think I may have found the culprit behind trees not sitting level on the terrain (when up close, some are floating a little, others are dug into the terrain) - The terrain and the objects sitting on it are in two vastly different scales for the position of each vertex, and the system currently writes the generated WaveFront OBJ files using float (32-bit) math, and then only writing out 5 or 6 decimal places in the files for vertex positions. If I change the precision and then also change the number of digits the program writes (It uses a standard ofstream from the C standard library, and I already know how to tell it to write more digits), it might solve this issue.
-
Regarding to the TigersEye version, released in the coding topic:
http://www.youtube.com/watch?v=dbFM_moCEMI <--- i think that explains my anticipation good enough. ;)
-
wow thats really cool! Will there be any city backdrops for air combat, like when the UFO flies over urban areas?
-
wow thats really cool! Will there be any city backdrops for air combat, like when the UFO flies over urban areas?
There could be, possibly.
I've actually got more than one idea on how to implement cities and densely-populated areas.
One idea is to create the terrain and then plunk down a ton of static meshes of city buildings, much like how I did with trees, they would be VERY simple building models with no more than perhaps a dozen or so faces, so that a large number of them could be rendered on the terrain at once.
Another idea I've been thinking about, one that perhaps might work better depending on how it is done, is to totally replace (get rid of) the terrain for city areas and instead of building a terrain mesh, simply use different algorithms to create streets and buildings. If this second idea was done right, it could work quite well IMO. I'll really have to do some tests to try this out. As far as the textures for the buildings in this second idea, that would actually be rather easy, it could be done with several grey-scale textures lumped together into one texture file, so that several "base" starting textures are used for variety in buildings, and then after mapping the texture use vertex colors to color the buildings differently, so the resulting combinations of buildings would be a fairly large number but without using too many resources on the rendering system. I know how to do this in Irrlicht but will likely need help from a few others with coding it to work in UFO AI's render engine.
An alternative is to map two textures to a city mesh, in layers, so that one would have the grey-scale textures and the other would be a low-res collection of colors for coloring the faces. The only big issue with this idea is that all the faces would need two independent sets of texture coordinates for the two different layers. I don't know how well OpenGL can handle that, I'll have to do some research on this version of my idea.
-
Will this still support mass fights? I can't imagine trying to bring down a Harvester or Corrupter with one aircraft.
-
Will this still support mass fights? I can't imagine trying to bring down a Harvester or Corrupter with one aircraft.
From the beginning of my plans I intended for support for multiple aircraft within the combat area, as well as the ability to get reinforcements involved mid-battle, so to some extent, yes, although I'd imagine there would be a (hard-coded?) limit of some kind on how many aircraft are in the zone at once.
I'm not sure what that limit will end up being, whatever number it will be will affect gameplay balance and of course be subject to Mattn's approval.
-
Its just an idea but what about if we not add a cap which is restricted by the count of aircrafts but rather by a "value cap" which is effected by aircraft type and aircraft equiptment. So you can attack a corruptor with 4 stilletos (with standard weapons) but not with 4 starchasers.
-
An alternative is to map two textures to a city mesh, in layers, so that one would have the grey-scale textures and the other would be a low-res collection of colors for coloring the faces. The only big issue with this idea is that all the faces would need two independent sets of texture coordinates for the two different layers. I don't know how well OpenGL can handle that, I'll have to do some research on this version of my idea.
In OpenGL, every texturing unit got its own coordinate array.
-
Regarding number of aircraft: I realize it's a little bit early to ask about it, but are there any plans to implement aircraft collisions? So far, none pilots expressed kamikaze tendences, but who knows what may happen...
-
Regarding number of aircraft: I realize it's a little bit early to ask about it, but are there any plans to implement aircraft collisions? So far, none pilots expressed kamikaze tendences, but who knows what may happen...
Hmmm.... I hadn't really thought of that. Thanks for bringing that up, I don't know if that will be in the final product or not, but I'll keep that in mind.
-
I hate to be a killjoy, but I think I'd rather have something like XCOM's air combat, with just the little window that pops up. Abstracted a bit, but it tells you everything you need to know (how fast are we going, how far away is the target, which of my weapons are in range, how effective is my attack?). It also let you just shadow the UFO until more interceptors showed up, so you could gang up on particularly tough ufos.
In the game, these UFOs are hundreds of km away and are moving at speeds beyond 1000 km/ hr. No camera could show you the whole battle, every aircraft would be fast-moving specks tremendous distances away from each other at high altitude. Really, there isn't much to see there, I'd hate to see some corny Starcraft or Galciv type air combat in an otherwise gritty, realistic game. Or the UFO interception happens right over the obscure town I live in, I expect to see how house, not just some green and hills and stuff. I also don't imagine all the aircraft fighting anywhere close to the ground to see anything anyways, they'd be way up in the stratosphere and everything, with the alien craft and interceptors being unaerodynamic bricks and all.
If you want to use the 3d models, then have each aircraft shown by it's self in it's own little window (along with a menu with all the data on it, it's weapons, distances to the target, damage, ect) with clouds and whatnot rushing by it. Maybe don't have a top-down camera angle so you don't have to represent the ground. Blue skies, dusky/ dawn night. So the 3d model, with swoopy camera angles with blue, orange, purple or red or black in the background, with clouds.
Just a thought, the whole 3d modeling landscape idea thing is still better then the interception combat the way it works now, which really does need improvement.
-
I realize this has been on hold for quite some time, but I got this going again and after a lot of hard coding (C++ and GLSL), I have a new little demo for all of you to try out:
You can find it in the folder at:
https://sourceforge.net/projects/tribalcreature/files/terrain%20demos/
It features 3D moving clouds as well as some of my better terrain generation code and such.
Right now it is only built for Windows, it has 32 and 64 bit binaries in the download plus a config / game launcher utility for setting up video options and such (which is incomplete at this time, I admit, but most of the important stuff needed for the demo is in there).
Use the mouse and cursor arrow keys to move around, and ESC to quit.
Yes, it's from my own game project, but I plan to use some of the same code and concepts for air combat for UFO AI and possibly along with a new system for the battlescape as well.
It does have some known issues, which I plan to fix.
On my test machines it runs smoothly, in real-time, and mostly looks great, but I wanted to post it here so others could tell me how it works for them.
I await feedback...
-
Works and looks great for me! Good work Destructavator! :)
-
When will you implement this into UFO AI?
-
Well, it´s meant to be soon.
Whereas "soon" has a special meaning here, especially for those guys that spend their rare spare time contributing to the project. Usually it will be "as soon as its ready". :)
-
Well, you all id great work here with this game. Best UFO inspired game there is and that is amazing considering how much money is being spent on crappy ufo clones and they stay just that..crap!
-
Regarding to the TigersEye version, released in the coding topic:
http://www.youtube.com/watch?v=dbFM_moCEMI <--- i think that explains my anticipation good enough. ;)
why video in private?