Outpost: Genesis Info Leak

[leeor_net]

Ah, I see your point about the wrapper classes. Agreed. I would rather create wrapper classes for everything so that it would be particularly easy for somebody to port. I will develop the Win32 stuff. Since it's C++, things like the File System, Input, Sound, etc. will just simply have standard interfaces that the program would use without needing to know how the internals work. If you want to port to another system, just write the new code for a different OS and let the binary file decide which one to use.

Well, that's not a particularly good explanation of what would happen, but I'm sure Hacker and a few others know what I mean. I don't plan to make it difficult to port to other systems. By all means, let's port it to other systems so that ANYBODY can play the game! I'm just going to create a base.

BTW, I finally managed to pass out earlier today and was asleep for like... I dunno... 14 hours or so... I feel much better!

[leeor_net]

Have you considered using stuff like SDLnet and FMOD for network and sound?

Yes. I don't like SDL at all. FMOD is a possibility. However, I've done a lot of sample programming with DirectX for sound mixers and whatnot. Chances are I'm going to create the code for the sound processing myself. If someone wants to use SDL or FMOD for input/sound in a port, they would just simply need to make the new calling conventions within the abstraction classes... simple enough.

The big reason why I don't want to use SDL is because on Win32 systems, there is a lot of potential overhead. It uses DirectX for Win32 so why wouldn't I just use DirectX myself? I don't have to go through a series of library calls or extra function calls just to call a DirectX function. I didn't like it the first time I used it I doubt I'll like it the second time I use it. Besides, DirectX has moved quite fast from the joke that it was in version 1.0 to a highly sophisticated, highly optimized HAL that works all-to-well.

Also, one note about the way the program will start (the int main() function, or rather the WinMain() function), is that it will be created for use under a Win32 environment (hence the WinMain()). This should be easy enough to change while porting because I don't think I'm going to create any win-specific stuff except for the WinMain and WndProc functions. Besides, the WinMain function will simply call the Init functions for each system (Refresh, Sound, Input, Network, Logic) and then call a GameInit function.

While I'm at it I'll just describe the way the program will start.

Basically, once the program starts, it will call up the default Refresh, Sound, Input and Network plug-ins (I love plug-ins... makes changes and updates TOOOOOO easy!). The Logic module will not be loaded until just before the actual game starts.

The user will be able to make changes to various settings like Graphic Quality, Sound Quality, Network Settings and Player Setup (color, name, colony, etc.). The user will also be able to select which GameX86.DLL file to load (the gamex86.dll file is the Logic Module... I assume that other systems will have different extensions than *.DLL so the Plug-In loaders will also be wrapped up into abstraction classes). After the player has selected the Logic module to load (by default, GAMEX86 will be loaded from the DATA directory), the game will initialize its Logic module and begin.

As the user will be able to choose different Sound/Input/Network plug-ins, these will all be loaded at run-time. The user will not have to restart the game for the new plug-in to start. If the plug-in fails to load, the default plug-in will be started. If that fails then the game will terminate and the user will be given approriate error messages.

I'd say it's a pretty fluid system with a lot of potential if I can get it to work right. It will allow for MOD's to OP3 to be developed and deployed very easily and will also make it easy for the user to to install and play new MOD's. I don't plan to do all of this myself as it would take years to complete an engine of this calibur on my own, especially since this is hobby-work. I will eventually be calling on the help of others from OPU as well as other game programming forums (such as GameDev.net) when I have the framework for the engine set up and working. So hopefully I have some really interested people looking to be part of a large project!  B)  

[leeor_net]

Hmm I didn't think the skin would add so much details.

The skin adds almost all of the detail to a model. Plus, these images there aren't showing what the bump, specular and highlight maps will make it look like. That screenshot is not an in-game shot of the model. It's in the modeling software I use.

The Graphics engine supports what are called bump-maps (amoong other things). A bump map essentially tells the renderer how to render a texture and light it in such a way that the surface with the bump-map on it will look like it has much more detail than it actually does.

For instance, say you had a wall with a concrete texture on it. Normally, a renderer would just simply slap the texture onto the surface of the wall and that's that. While from a distance the texture may look absolutely stunning, as soon as you move up to the wall the texture becomes flat and bland.

By applying a bump-map to the concrete texture, moving up closer to the wall will make the wall look like it is actually textured rather than just having an image drawn over it.

I have compiled a short video demonstrating the use of bump maps and what they are capable of. Please note that the program rendering the image in the video is rendering this REAL-TIME and is totally useable in a real-time game (proven by the fact that I'm moving the globe around with my mouse). It's a low-res video but should get the point across. If anyone wants a hi-res video just say the word and you've got it.

You can download the movie here: http://opmia.outpostuniverse.net/download/bump_mapping.rar

[Sl0vi]

ehm.. this simply just looks amazing!  

I must say you've done a great job leeor_net, and I'm definetly looking forward to seeing more of this game.

Keep up the good work!

[gamerscd0]

nice this is a good start

[BlackBox]

Yeah, that makes sense leeor; provided all the directX / system dependent stuff is only done in the abstraction classes.

That way for example, if I wanted to port it to Linux, I'd just have to write the underlying interface to SDL or another system (maybe just access the framebuffer directly..)

Entry point isn't much of a big deal; that's a problem with any system.

Oh yeah, on code organization -- it might be nice to store the system dependent stuff in a separate directory. that way it's absolutely clear what has to be ported.

[leeor_net]

Believe me, I've given a great deal of thought to the way I intend for the system to work.

As far as the abstraction classes are concenred, that's exactly the way I'll be writting them... Let's say for instance (and this is going to be a class that I write) that I had a wrapper class for File System calls (Obviously, Linux FS is different from MacOS FS is different from Win32 FS etc.). Let's look at a SaveGame for instance:

Code: [Select]

int CFileSystem::LoadGame(char* FileName)
int CFileSystem::WriteGame(char* FileName)

Simple enough. The game would just simply need to call these functions without the need to know what's in them. It just needs a file name and it returns an integer about whether it was successful or not (various returns could mean various errors like "File Locked" or "File Doesn't Exist" or whatnot). Then it's just simply a matter of writting new internals when porting.

Of course, this is an extremely simple example of what I would actually do. Chances are the LoadGame() and WriteGame() functions would be abstracted versions of the game. The file system class would probably have low-level functions like OpenFile, WriteByte and the like. The LoadGame and WriteGame functions would just simply use the lower-level functions. In fact, they may be part of a different object that uses a FileSystem object. I havn't gotten too specific with myself right now about exactly what functions I would use for various things but I'm definatly getting there.

Anway, I have some new Screenshots for everybody. You can see that the Light Tower has had some changes made to it. Certain parts are much brighter than others now. THey are actually emitting light. However, the shadowing code I still need to add. Either way they're nice, my favorite being the close-up of the Agridome!

=====================================================

http://genesis.outpostuniverse.net/images/screenshots/t_screenshot_1.jpg
http://genesis.outpostuniverse.net/images/screenshots/t_screenshot_2.jpg
http://genesis.outpostuniverse.net/images/screenshots/t_screenshot_3.jpg
http://genesis.outpostuniverse.net/images/screenshots/t_screenshot_4.jpg

In order:
===================

• Close-up view of the Plymouth Agridome.
• View showing the extent of the landscape with the Plymouth Light Tower and Agridome
• Another shot of the whole scene with the Eden Advanced Lab. No skin for it yet (hence the colored template skin).
• A view of the Agridome and Light Tower from the perspective that the game will likely be in when the game is ready to be played. Note that this screenshot has Full-Screen Anti-Aliasing turned on to the highest setting (Level 4). This image has not been modified at all.

A few notes about the engine:

The engine Frames Per Second (FPS) has been capped at 75 (which is awesome for fully developed real-time games). Anyway, the FPS remains between 74.5 and 75 on my computer regardless of the whether it's rendering 3000 polygons or 35000 polygons. So it's working out quite well.

EDIT: Removed 'img' tags and left the original links instead. Unfortunately I no longer have these images.

[Stormy]

Any more thoughts about this?  :lol:  

[Leviathan]

Looking great, good work, make sure you add the screenshots to the wiki project page.

Why did you decided to start from scratch with your own engin? Did you not look at using a open source engin which has allready had a lot of work done on it? I just think your giving your self more work than is needed like you love to do? You know its coming.... have you looked at the Spring code?

[Stormy]

I don't remember when we decided on a new engine.. but still.. I REALLY enjoy making models... and It's not all that much work if you spread it out...  :lol:

Oh and the Spring code... we can't do that.. everyone has to have TA to run the game.. So thats why we are making our own

[leeor_net]

Actually, it comes down to a few things.

I have been wanting an excuse to create my own 3D RTS Engine for awhile now. There are several games that I want to develop and I just never found a good reason to start on any of them.

Another reason, my personal vision for the look and feel of Outpost3 requires a graphics rendering engine particularly good rendering high poly-count scenes at very high frame rates (currently, I have the throttle for OP3 set to 75 but I've achieved rates of 1800 FPS with scenes rendering 40,000 polys).

In addition, the graphics rendering is already done and that's easily the largest and most complex part of any 3D engine. It's now a matter of telling the graphics engine what to do with itself, detect input and respond appropriately and handle sound/network. Not a lot in the grand scheme of things but still quite a bit to do.

Besides, using someone else's engine doesn't always garantee that it's a good one nor does it mean that you can do what you want with it. (e.g., image a Tokamak exploding. All the way across the map you've got debris coming from it which can possibly damage your own vehicles/structures. I don't know too many RTS engines that support that sort of thing).

[Leviathan]

Stormy: wrong.

Leeor: Well its still more work for sure. Why reinvent the wheel? Do you realy think some other project wont be good enough for what you want? With spring or any other open souce engin you  are able to add and edit it to do whatevea you like, like adding morale, tubes, op2 stuff, tokamak exploding etc. There is a lot of support from people to help.

What program are u using to make the 3d models?

[Stormy]

Blender and MS3D

Edit: Why does it matter what we use.. as long as they are compatible with the engine  :rolleyes:  

[Hooman]

Lev, just looking at and understand a large open source project like that is a lot of work. Nevermind editing it to suit your needs. And then you're pretty much always left wondering if you've forgotten or overlooked anything. Reusing source like that isn't as easy as you think, and reusing compiled code usually isn't as flexible as you'd like. Besides, if there is no interest in playing around with someone else's engine, then there is even less chance of a project being finished then making one yourself.
 

[TH300]

very nice screenshots and many good thoughts.


As for the engine - it can be more difficult to learn to use an engine that someone else made than an eninge you made yourself.

[leeor_net]

See, Hooman and TH300 have exactly the reasons I would rather write my own engine. Granted I'm using an already-done graphics rendering engine but it's quite clear and very easy to use.

In addition, it took me easily 6 months to fully understand the Quake2 source code... and it's not particularly advanced. Again, it would probably not take nearly as long.

Also, as I had previously mentioned, I want to write an engine that is extremely capable of very high-quality graphics and allows me to easily allow the user to change the various graphics settings. While many of the people on this forum do not have extremely capable graphics hardware, I am counting on users from other communities to become interested in Outpost 3 and essentially the OUTPOST Series. These users will very likely have much newer graphics hardware and will thus expect much more from the graphics engine.

So anyway, that's one reason I am writting a new engine. There are various other reasons but I think the graphics is the biggest one.

[Leviathan]

Well that sounds great and we all look foward to every update. Good luck and thanks for the work and input as allways.

[Freeza-CII]

Um question.  Isnt this going to leave alot of people not able to play the game because they will need a good processor and or vid card.

[Stormy]

We are making it to where you can play with at least... a crummy GPU maybe.. But Leeor knows more on this area as he is the 'video man'  :lol:  :rolleyes:  

So Leeor... reply plz

[leeor_net]

Um question. Isnt this going to leave alot of people not able to play the game because they will need a good processor and or vid card.

Not at all. The idea behind the engine is to allow the user to 'tweak' the engine to his or her computer for optimal speeds. For instance, my computer, as it stands, will be able to run the game on its highest graphics settings at around 60 - 75 Frames Per Second. The Highest settings will render accurate shadows, dynamic lights and will use complex particle systems.

The lowest settings will turn off shadows alltogether (medium setting draws shadows as simply dark splotches underneath units), will reduce the polygon detail of every model down to 30% of the original polygons, no dynamic lighting will occur and will use just basic particle systems (no fancy effects and simple gravity simulation). Also, the Lowest graphical setting will not use special effects such as Vertex and Pixel Shaders (typically found in most newer games).

So anyone with a lesser graphics card will be able to run OP3. However, the better your graphics card, the better OP3 will look.

=====================================================

As a general note (and continuing on what Hooman said but with numbers) I would rather spend 4 - 5 months working on an engine that I know will do exactly what I want it to and that I know exactly how to modify it and where instead of working 4 - 5 months going through someone else's code and not being garanteed that I'll be able to achieve exactly what I want.

In addition, while it's a hefty project and will certainly take some time, I plan to use this engine for other games that I have sitting on the backburner as well as releasing the engine in a simple SDK for other users to use (with extremely easy modification abilities). I find that many free engines (especially RTS) are seriously lacking in many reguards so it just seems easier to me that I create something new that definatly works or definatly doesn't work.

[Freeza-CII]

So tell me the atmosphere of this planet ,which i know you named BOB till you get a good name, its suppose to be like venus yes.  

[leeor_net]

It's supposed to be similar, but not the same as Venus. (and for those of you who have ever watched Titan A.E, you'll know where I came up with the name!)

Anyway, so yeah, it's supposed to be similar to Venus with high concentrations of Carbon Dioxide. However, in order for some of the elements in the story to work, I'm changing the atmospheric makeup a little bit. The atmosphere is now comprised of approximatly 60% Carbon Dioxed, 30% Nitrogen and the remaining 10% is various other gasses. The thick clouds covering the planet are made of Sulfuric Acid droplets (as opposed to water droplets on Earth).

These changes were necessary for a critical component of the story, Natural Explosion Phenomena. Heh, the name sucks but it explains essentially what happens.

There are a few points in the story were naturally occuring and extremely violent explosions occur. This is due to various salt deposits (not Sodium based salt, mind you) that are uncovered due to the high wind-velocities on the planet. The atmospheric Nitrogen is bonded with other chemicals in the cloud layer form Nitric Acid which appears as a white gas. These Nitric Acid clouds roam around for awhile before they are evenly dispersed.

Sometimes these gas pockets in the air come into contact with the salt deposits on the surface of the planet. When that happens, the explosion occurs.

Nearby vehicles and structures can be destroyed or damaged. If these explosions happen to occur immediatly adjacent to a building, the only thing left will be a smoking crater.

This also adds an element of challenge to the game because the acidity of the atmosphere (being that these nitric acid pockets have been forming and dissipating for a long time) is very high. Because of the high acidity levels, units and structures will need to be constantly repaired as a result of the corrosive nature of acids. Sufficient research will remedy this problem with new structure and mobile armor which can be integrated into the original armor plating of any of the units in the game.

[Leviathan]

haha sounds totaly great

[Leviathan]

haha sounds totaly great

[Freeza-CII]

Well I can see the problem with that atmosphere.  If its like venus then its nothing more then a pressure cooker.  The Green house effect.  With temps that could eventually destroy the buildings and lynx.  Well if it does have th cloud cover like venus then not one damn drop of any thing will get to the surface i dont know if a super heavy gas like neon or argon could.  Every thing would be to super heated.  Plus the constant cloud cover wouldnt allow any day light or very little light with maybe a red or orange hue.  

Expoding salt deposites i love it.  Now if you had some kind of tech/building that could remove the salt deposits from around the base thus avoiding a major disaster.  How ever to remove one deposite means another appears else where.