Outpost: Genesis Info Leak

[leeor_net]

Ok... I talked to stormy and apparantly Hacker and Freeza ended up looking through the member section of the website... what for I guess I'll get an explanation for soon enough, but here goes:

We have decided to go ahead with a 3D engine which is currently working very well. I have started preliminary coding for a 3D RTS engine and I have every intention of completing it.

We have thus far nearly completed the Story Outline and will be calling on OPU to write the actual chapters.

A Design document is in the works and now has a basic framework. This will be passed around between the developers for a few rounds before we let everyone here know what we want to do (this way we can eliminate clutter in the doc and can organize our thoughts properly). After it's out, we'll be looking forward to suggestions and whatnot.

We have also started some preliminary content work so that I can test the engine as it progresses (and also so that we don't have nearly as much to do as the game moves forward).

There have been several requests for pics (looks at Freeza and Hacker)... And here are some:

http://genesis.outpostuniverse.net/images/screenshots/ss_01.jpg
Screenshot of the actual engine in-the-works. This is an older version of the engine. Much has happened since.

http://genesis.outpostuniverse.net/images/plymouth/light_tower_02.jpg
http://genesis.outpostuniverse.net/images/plymouth/mhd_02.jpg
http://genesis.outpostuniverse.net/images/eden/advanced_lab_01.jpg
http://genesis.outpostuniverse.net/images/eden/cc_01.jpg
http://genesis.outpostuniverse.net/images/eden/comm_storage_01.jpg

Various structures. The Light Tower is the only structure with a completed skin. The Advanced Lab has a skin template. The others still need to be skinned.

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

[Freeza-CII]

ME like .  Thank you for some thing

[leeor_net]

There's definatly a lot more than this but I think this should keep the masses taken aback for awhile...  B)  

[Freeza-CII]

Thats all i am really asking for just what its going to look like. because i can care less about stories and movies lol.

[Stormy]

Note: most of the textures for like the sky were done quickly and are in NO WAY the final textures .  

[Freeza-CII]

its kinda scary because it looks like another sierra game i used to play.

[leeor_net]

Heh... well, the sky is on another planet whos atmosphere is more venus-like. Actually, I've done some 'research' into other 3D RTS games and I'm wondering how I'm going to handle the sky exactly. I may keep it because some of the in-game 'cinematics' will actually be using the engine itself rather than full-motion videos (it's easier and more cost-effective for our purposes. We don't exactly have the resources that Blizzard or Microsoft has).

Anyway, a lot's been done, a lot still needs to be done.

[BlackBox]

The reason I happened to find this I'll explain now:

I was told a while ago that someone had stored porn on their OPU web space. So I had to search every single account we've created for people to check for porn, and tell the offending person to remove it before I suspended their account (as you might have guessed, we don't allow porn on hosted accounts).

Well since I had to search every account for it, I stumbled across these. I was pretty impressed, but wondered, why didn't you guys release it sooner?

Apparently Freeza stumbled across it a couple days before when he was searching the web for OP2-related content.

Anyway: Yes I did find the porn. I'm not going to say who it was (for obvious reasons), all I'll say is that the problem has now been resolved.

Couple suggestions on the models:

Why not use more polys? design a high poly and low poly version of each model and let people pick in game (though I'm sure you've probably already thought of it)

The light tower looks nice. I might suggest, the texture on the sides looks a little unusual in that engine screenshot, like concrete texture or something.. (maybe it's just the lighting and angle of looking at it)

Besides that, good work so far!

[leeor_net]

Generally for 3D RTS engines, the models will be relatively low-poly. Most of the detail will come from the skins and materials applied to the model, not intricate detial work in the model itself.

The concrete look you mentioned is accurate. It was due to a few things: 1) I was using a point/point/point type filter which doesn't allow textures to be smoothed by the filter and 2) there was no lighting in the scene so everything was bland and muted. The texture filtering is controlled in the material script used for the skinning of the model. I forgot to turn off the point/point/point filtering.

As far as lighting is concerned, the 'light' portion of the model as well as the blow 'glowy' stuff on the base now are very bright (As I would imagine they should be) and will soon be able to emit light (light entities can be horribly difficult to create via a script).

Now, back to the reasoning behind low-polys in RTS engines. The polycount for the models is low for two reasons. One, RTS games produce large numbers of moveable units in addition to the terrain, effects, structures, etc. In a crowded scene, the user may be rendering up to 50 or 60 thousand polygons on screen at once. This is a very big problem for users with graphics cards older than 2003 (which I would guess about 75% of the users on OPU are older. in fact, stormy was... ) Severe slow-downs and lag result and it just wouldn't be fun.

The engine itself actually generates lower-polygon models based on the users settings (for instance, graphic detail being low, medium or high). Also, as units and models move further away from the camera, a new Level Of Detail (LOD) kicks in and the model no longer needs as many polygons to represent what it is.

Also, just a note (and I think Freeza would like this), the colors for multiplayer games were... limited. OP3:GENESIS will allow the user to define custom colors by changing the Red, Green and Blue (RGB) components in their Player Setup Screen. This allows users to create any color they want, be it light blue, dark blue, black, white or puke green. Just thought it would be a nice touch.

I will post more information as it becomes available and we (the developers) deem it appropriate. So I guess, stay tuned. We have a lot coming!

[BlackBox]

Sounds good so far.

Of all things, you should make the engine as open as possible, maybe even to the point where people can plug in new functionality by creating a library and putting it in the dir.

So for example, people can create new game types, etc.

Another thing I'm hoping: Will it be crossplatform?

[Voyager7456]

This looks pretty sick guys! Glad to see an OP3 with some progress done on it!

Keep up the good work!  (thumbsup)  

[Stormy]

Oh and I think it will be cross-compatible.. but I don't know how the engine works coding-wise... other than it uses X,Y,and Z coordinates to place the vertices in the world and attach the mesh/skin  :lol:. I do know that we will make it easy to mod though . For you guys who might wanna make new gametypes!!

And of course... There will be the 'traditional' Outpost 2 'birds-eye-view'

[leeor_net]

Actually, stormy, the engine will not use the OP2 Birds Eye View (BEV). It will use a camera position similar to Age of Mythology/WarCraft III. However, the engine will allow for some camera movement (e.g., rotations, zooming in/out, etc.)

The graphics engine as it stands right now is completely cross-platform compatible (in fact, I'm about 99% sure it'll also work on the PlayStation 2 and xBox).

However, the rest of the engine will more likely be Win32 only. I am familiar with and very capable with DirectX programming. I do not run other Operating Systems so I don't know how to program anything else except with the SDL Library (which I know supports a lot of systems). I will be using DirectX coding for the Input and Sound systems of OP3.

However, the engine is designed with modular plug-in support. The graphics engine is plug-in based and currently supports DirectX 7, DirectX 9 and OpenGL Refresh engines. I plan on keeping with this scheme and making the rest of the engine plug-in based (e.g., sound plug-ins, input plug-ins, game logic plug-ins, etc.)

Also, my work with the Quake2 and Quake3Arena engines has made me familiar with the idea of making OP3 MODS extremely easy to deploy without changing the original engine's code or game-logic code. Through the use of what I will call the GameX86.DLL file, the games' logic can be controlled entirely through this one file. The 'Logic Module' contains all of the code relating to units, vehicles, structures, tech trees, AI, physics rules, etc. It must follow a few rules to conform to the OP3 Engine Loading routines but otherwise the 'Modder' is free to do whatever he wants.

All MODS will be contained in directory other than DATA (DATA being the default game code and content). All new content and game code will be contained in other directories (such as PRAXIS or LEEOR_NET'S MOD). When the game starts, it will scan all sub directories of the root for new game modules. In the game's starting menu, the user will be able to choose which MOD to load.

Also, as most mods rely on the original games' content, any content that is not found in the MOD directory will be search for in the default directory (DATA). If it's not found there then the game will return an error.

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

As far as an open engine, you bet. I have all intentions of leaving the game's source code open and free for non-commercial use. I don't think I'll allow commercial use of the engine without a liscence but I have yet to determine exactly how I would work that.

Either way, I want the engine to remain open so that when we release the beta's, other users of the community can download the source and make any necessary changes.

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

Sound/Input plug-ins aren't going to so much be handled like emulators or WinAmp will handle it. Essentially the game starts, reads a configuration file and goes ahead and loads whatever plug-ins are defined. Sound/Input plug-ins can't run side-by-side so they need to be complete or the game may not operate correctly. Also, I don't know if I'll develop the engine to allow for run-time switching of the plug-ins but you never know how it'll end up. I link everything into the game engine right now at run-time so it may be fairly easy to just shut down the current module to open the new one. Oh well, we'll see how it all develops.

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

Game content is fairly straightforward to create. I've developed a few tools already to make it easy for me to create new Overlay/Material scripts as well as generate several LOD's into a single model mesh file.

Also, I've started work on a mapper for the game simply so I have an easy way to generate a new map. It's not doing anything yet except loading in the layer scripts and generating new material scripts for the mapping layers.

As far as content creation, the members area of the Genesis website will have information about creating all of the content for the games. I have a lot of work to do before any of that even shows up in that section and before any of that information becomes publicly available but I can assure you that it will become publicly available.

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

Wow, that's one hell of a post!

[leeor_net]

New image file: Plymouth Agridome:

http://genesis.outpostuniverse.net/images/plymouth/agridome_03.jpg

Please note that this skin has taken me about 10 minutes to do. It's way late for me I've had no sleep in like 2 days and I just wanted something to throw up. Enjoy.

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

[leeor_net]

Updated version of the Agridome. The skin is finished. Here's the shot:

http://genesis.outpostuniverse.net/images/plymouth/agridome_03.jpg

compared to:

http://genesis.outpostuniverse.net/images/plymouth/agridome_04.jpg

The whole structure now looks like it's been in the elements for a long time. The 'dirty glass' is actually foliage, not dirt (although there is some there). I'm very eager to stick this in the game because I have bump-maps and everything ready to go.

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

[Freeza-CII]

O.O oh my that looks very nice

[Ezekel]

is it me, or does anyone get reminded (even a lil) of urban assault when looking at these pics?


also, i think you should me a new thread in this area that tells ppl about genesis.

like how its 3D and how its still an RTS and not an FPS (or a C&Crenegade style FPS)

[Death_Knight69]

Let me just say, it's been over 5 years and I finally found out about OPU. It's been so long since I played op online(when it first came out), and now I find out that ppl are getting together to make OP:U.  It's almost made me cream my pants!! Way to go guys!!
BTW, the models look sweet. Keep up the great work!

[zigzagjoe]

nice models...but would those said plugs also apply to the display? so that you could recompile, put a new plug and have it run on linux?

[BlackBox]

Depends how well the game is 'equipped' for porting to other OSes.

At the very least if you don't want to port the game, make it easy to do in the future. This would mean all the system calls should be done thru some sort of wrapper class (i.e. to open a file, read/write, open sockets and read/write them, query time, load / unload a library etc). Most importantly all graphics/sound/input routines should be done in a similar wrapper, or in separate libraries. This includes DirectX.

Also in your network code, pick an endian and stick with it. For example little endian since it would be primarily used on Intel x86 systems.

Make sure there's an easy way to convert from one endian to another. This would work if you run everything thru an abstraction layer like I suggested above, but you have to do some extra stuff to handle things like C structs (use a schema or something that tells the code converting the endian what fields in the struct exist, and what ones have to be converted).

If you do everything through some sort of abstraction layer, and use no system dependent calls or anything outside of that layer, porting the game would be extremely easy.

Other than that; keep up the good work!

[leeor_net]

hacker, much of what you're asking for is way more than I'm even looking at right now. First off, I'm only going to 'officially' support the Win32 versions. What other people do with the code in terms of porting is another thing and would be great but I will have nothing to do with it.

The graphics/refresh engine is ALREADY portable and will not need to have any changes made to it. It's as simple as obtaining the binaries for the appropriate environments (e.g., Linux, BeOS, MacOS, etc.)

Second, it would appear that some people don't realize that RTS engine can be 3D and still look like the traditional RPG. I'm posting an image of Age of Mythology in game for two reasons: 1) so that people can see EXACTLY what I'm talking about. There's no First Person about it and 2) because I'm modeling the camera view as well as the keyhandling after AoM... it works very well and there's no need re-invent the wheel.

http://www.microsoft.com/games/ageofmythology/img/screens/aom_screen11.jpg
http://www.microsoft.com/games/ageofmythology/img/screens/aom_screen3.jpg

As you can see, these images are not in a First Person perspective. Outpost 3: Genesis will have a very similar, if not identicle view to this. (quick note: the shadows in AoM are just dark spots underneath units. OP3 will have the option to turn shadows off, basic, and accurate. I would be able to run the game with full graphic quality. Many people don't have the hardware I do so it becomes necessary...) {Thinkin' of you, TH300!}

As far as wrapper classes, I'm just going to code the engine the way I code it. The porting I'll leave up to someone else. I run Windows. I will probably always run windows. I refuse to acknowledge MacOS and Linux is just too different for me to make a migration at this time. So Windows it is. If you want OP3:GENESIS to run on Linux, download the code and make the necessary changes. The same goes for any other OS.

Please also note that the engine right now is far from an engine. It's just a program that starts its refresh engine, loads a few files and goes from there. Basic input allows me to move around a height-field terrain and to use the mouse to point the camera in any given direction. I can turn debug information on and off. And that's about it right now. Great for testing but far from a complete engine.

but would those said plugs also apply to the display? so that you could recompile, put a new plug and have it run on linux?

I hope I answered this. If you want Linux, you can write it.

I don't mean to sound harsh or rude but as a few know I've not slept in, quite litterally, a long long time (I'm on day 6 right now). Also, I write software as a hobby right now. I would absolutely love to write software proffesionally but I can't exactly work for EA or id or Maxis right now and OP3 isn't going to land me a big fat check so I'm only going to go so far. Yes, the code is going to be quality code that works, no it won't be incomplete and s***. But I'm only going to make sure the game works on Win32 platforms (namely XP) and that's it.

Hopefully I've cleared up some questions. If not, e-mail me (outpostmia@yahoo.com) and I'll post a new thread answering each and every one.

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

[Stormy]

It would still be good to make it to where you don't have to re-code everything if someone wants to port it to MacOS or something.

[BlackBox]

Yeah, that's what I'm asking. You don't have to do the actual cross-system coding; just 'insulate' the system from the program by creating some sort of abstraction layer.

E.g. if you're doing it in C++ just create a generic file reader/writer class and do ALL file operations thru this. That way, you don't have to recode all places where file operations occur in the program; just recode the file management class to port to a different OS.

If you use SDL that's easily done.. just the other parts like for sound and input, files and network would need an abstraction layer to make porting easier. (Have you considered using stuff like SDLnet and FMOD for network and sound)?

[plymoth45]

Guys, have a look at the EE2 graphics, they are rather good, though the game itself is lagged by AI issues.

[zanco]

I have read the suggestions you-lot made about the game coding and other stuff. The only thing I will say is not to worry and let Leeor_net do what he is planning. He is really talented worker and I think knows what he is doing. There is no need to worry about that.

Nice job ;p
Hmm I didn't think the skin would add so much details.