The Genesis Engine is the software created by Gavan Woolery to run Genesis. It is built in C++ using the DirectX API.
Graphics[]
Genesis uses a graphics engine that is far different from most engines out there. At first glance, it looks like an old-school isometric engine (although technically speaking, it uses diametric projection) with pre-rendered 3D graphics. Actually, scenes are not rendered in an external application; they are rendered directly by the program, on the fly, in very little time. While the camera cannot be freely rotated (although it can be zoomed and panned), this otherwise greatly empowers the graphics engine. It allows the use of software displacement mapping (although hardware will be supported too in the future), so that texture actually sticks out objects (unlike projection/parallax mapping, this uses true displacement, so even the edges of objects stick out). Further, since scenes only need to be rendered once every so often, polygon counts can be hundreds of times higher than in strictly real-time engines. Moving objects are, of course, rendered in real-time, and not bogged down by static objects in the scene. Additionally, the scenes can be correctly lit in real-time, making them virtually indistinguishable from a real-time engine. The camera can cut away any level in front of the player so that the player can see behind objects.
Even though many parts of the scene are statically rendered, there are many parts that move as well. Trees and grass can blow in the wind (or, to increase performance, they too can be statically rendered), water ripples and refracts everything below it (eventually, it will probably support reflections as well, although this will decrease performance and require more texture memory), fog drifts through the air, and of course the creatures and races move about.
One thing that makes the Genesis engine render such amazing scenes is the per-pixel materials. Not to be confused with per-pixel texturing, per-pixel materials determine the lighting properties of a scene on a per pixel basis. Essentially, every pixel reflects ambient, diffuse, and specular lighting in a unique manner, which allows for extremely rich textures. Textures can be created where half of the texture glows in the dark and the other doesn't, or is shiny in one part but dully-lit in another, and so on. Even “unrealistically lit” materials can be made. For example, the specular color of a material can be made darker than the rest of the material, which creates a velvety surface. Or, the diffuse color can be darker than the ambient and specular colors, which makes for an anisotropic-esque metallic surface. Most importantly, however, is the fact that every pixel can have its own unique ambient properties, which makes the scene look much more realistic then standard shaders (it can be used to roughly simulate light bouncing around a room, so that even if a surface isn't receiving direct light, its features can still be made out). In short, the texturing looks much better than in most standard engines.
The plant engine is absolutely amazing. In an older iteration of the engine the engine was powered by voxels, and I wrote a plant engine for that. The way the engine was setup, it should be fairly easy to convert the algorithms to work with polygons (which the current engine uses). The plant engine is powered by a relatively simple piece of code, but at the same time it is extremely powerful and capable of modeling any plant or tree you can imagine, even the blossoms and fruit that they produce. It can model anything from a palm tree, to a pine tree, to an oak tree, to a banyan tree, to a rose bush, to a mushroom, to a vine, all using the same algorithm. Moreover, it can model these plants with a dynamic level of detail, using only polygons (no “faking” with texture maps), right down to the leaves on a tree. Additionally, seasons come and go in the Genesis world, and plants adjust accordingly. Leaf and grass color changes, trees shed their leaves, flowers blossom, and fruit grows. This is very important to the realism of the world, since players must grow and harvest their own food to survive.
Unlike a standard pre-rendered isometric engine, many depth effects can be used. Two examples of this are atmospheric haze and focal plane blurring (blurring objects that are far away from the camera. The Genesis engine can do a depth-lookup on any given pixel, which allows for realistic occlusion. For example, even if the grass is statically rendered, each blade will appear in front of your character if it is supposed to, while other blades are correctly occluded.
Sound[]
There isn't anything special about the sound engine, at least for now. The standard environmental effects are used like most games. However, one thing that is being thought about is text-to-speech. It is not definite how high of quality could be achieved with this, but if it were reasonable it might be integrated with the game. For example, when somebody texts you a message you actually hear their character say it, and the sound is correctly modified based on the environment and the distance of the person talking. Moreover, the sound could be modified to make voices sound deeper, coarser, etc. To complement this, another possibility would be a system that could translate speech to text, freeing your hands of the keyboard and making responses much faster. Now you are probably wondering, why convert speech to text, and then back to speech? The first reason is bandwidth, sending a string of text takes much less bandwidth than a few packets of voice data. Secondly, this allows players to truly mask their identity, so that an ogre doesn't sound like a kid. Additionally, the dictionary system could be implemented so that inappropriate words are modified. Another thing to note is that sound will play a strategic role in gameplay. Certain races and beasts have better hearing than others, and this allows them to hear sounds better and detect stealthy opponents more easily.
Music[]
I am very excited about the music potential for Genesis. Music can be contributed in an open-content model (see section C3 for more information). This means that any player can contribute music to the game. However, a central authority (currently me, for the time being), will judge whether or not the music fits with the game and is of high enough quality. The only other game I have ever heard of that has done something like this was Star Control 2, and critics agree that it has some of the best music of all time.
One idea that I have been very interested in implementing is the ability to play instruments within the game. This way, virtual bands could come together and create their own music. If I chose not to go to this extreme, then I might at least allow people to come together in the game and play songs that have already been written. If the songs were in a tracker-based format (not compressed into a sound-stream, but rather just the play sheets for the music, like midi for example, but much higher quality), then songs could be modified on the fly. One possible use of this is to make songs out of tune, tempo, use the wrong notes occasionally, and so forth, based on the musicians skill level. So, essentially, inexperienced musicians would sound horrible. Again, these are all just ideas, and definitely won't be implemented until the rest of the game is successful, but it never hurts to dream.
Input[]
Mouse and keyboard will be used, and no other input devices will be supported. Ideally, you should have a mouse with at least three buttons, and a wheel (note that on many mice you can press down the wheel, which acts as a third button). Eventually, I would like to be able to integrate exercise into the input scheme. Laugh if you will, but I really think that the future of exercise lays with video games…you are challenging your mind, why not challenge your body at the same time? I always feel like I have wasted my life after playing a video game for 12 hours straight (Ok, you could argue that I exercised my brain and improved eye hand coordination, but does this really attract the opposite sex?). I think by integrating exercise with video games, we can erase the stereotype of gamers as pasty-white couch potatoes, and replace it with a stereotype of gamers as pasty-white meatheads. Much better, right? I think the Nintendo Wii (or whatever god-forsaken name they have given it now) is a good step in the right direction. DDR is also good, but of course has limited applications (and sex appeal). But I digress…
Physics[]
There are physics in Genesis, but buildings (at least for the time being) do not obey the laws of physics. In fact, you can make a house that floats in the air if you want. How do I rationalize physical paradoxes like this? Magic. They are magical buildings. Get over it. The reason buildings do not obey the laws of physics is because the compression engine is not very physics friendly, and calculating how a building made out of all sorts of weirdly-shaped rigid bodies would realistically explode is just more detail than I have the time to implement. Perhaps eventually I will change this, but for now, things are simpler just leaving the buildings as these potentially floating masses. Of course, you can still destroy buildings, bit by bit; just don't expect any fancy effects. Really, as far as gameplay goes, I don't think it will make a huge difference. However, all of the dynamic objects in Genesis obey physical laws to an acceptable extent. Rain drops bounce off the ground, create ripples in the water. Grass and trees sway in the wind (if enabled to do so – they can be statically rendered too, to improve performance). Arrows stick in walls, and are blown off course slightly by the wind, and so forth.
Networking[]
Here is where things get interesting. You are probably wondering how and the hell would I make a MMOG with dynamic content, where players don't even have to buy the land (as in Second Life). Compression is the solution. Maps in Genesis are extremely small, usually only a couple hundred bytes maximum. Keep in mind that is bytes, not kilobytes! Even on a modem, maps download in less than a second. Note that because Genesis is based on a dynamic world, when players download the game initially, no maps at all exist on their hard drive. Maps are downloaded from servers, on the fly, as players enter the region. All of the maps are stitched together seamlessly, so players don't really notice (although they will notice a slight delay for loading and rendering time as they rezone, but this should be less than a second's time if you have the proper hardware).
Where in the world am I going to get enough money to have enough servers to run this MMOG, you ask? Well, there are two options, possibly more. The first is that I get a publisher. Not only is this unlikely, it is undesirable, because I would rather not work under the constraints of a publisher, and you (the player) would not want to pay the monthly premium that a publisher would surely charge. The second option, also unlikely (but hey, a man can dream), is that players will give me enough help and support so that I can keep this venture going at a strong pace. If I receive enough support, I will give out the game for free, as well as the server software. If I can give out the server software for free, players can form their own remote clusters, or even LANs. I have come up with a networking scheme that works, in a way, like peer to peer programs, except much, much faster. In essence, each player uses a small portion of their CPU and memory to serve the game, or (optionally) the player can setup a computer solely used for serving the game, even multiple servers. Each player's server hosts a cluster of maps in a given location of the world grid. Obviously, player's servers could go down at any given time, at which point a neighboring server picks up the slack (although if too many servers crash or are shutdown, a portion of the world becomes untraversable). While this provides some potential inconsistency in the world, there are a number of advantages to this serving scheme. First of all, low ping. People can form MMOG worlds just in their neighborhoods or on their college campuses (might as well put all of that bandwidth meant for research to good use, right?). Low ping allows for more interesting gameplay features, like the combat system I have described. The weakness of commercial MMOGs lies in the fact that they can only afford to pay for, manage, and staff so many server centers. This means you usually have East Coast and West Coast servers in America, and a few other places if you are lucky. With my solution, there would be no wait for servers to appear in your area; any part of any country could host games immediately. Secondly (regarding the advantages), NO MONTHLY FEE!!!! Yes, it is exciting, I know. Last of all, giving server software to the players lifts the responsibility of managing servers and subscriptions off of my shoulders.
System Requirements[]
System requirements are still to be determined, but I can give you an idea of what to expect. Don't run out and upgrade your system yet though, as Genesis is not going to be playable for a some time to come.
OPERATING SYSTEM:
Genesis will most likely run on Windows XP, although if Microsoft wants to fund the porting of my code, I will make a Vista version as well potentially. Speaking of which, if I can secure enough funding, or if Genesis is successful, I will port it to Mac OSX and Linux as well, although this will likely take a lot longer, as it means porting the code to OpenGL. Genesis will not be released on any current generation console, as they simply do not provide diverse enough hardware to power the engine.
GRAPHICS CARD:
Genesis will definitely require a Pixel Shader Model 3.0 Graphics card, with a minimum of 256 megabytes of video memory. If it is released for Vista, it will require a DirectX 10.0 capable graphics card, with the same amount or more of memory. This might seem like a rather extreme requirement, but by the time Genesis reaches beta, I estimate these cards will be available for just a little more than $100.00. For full detail, it may require a graphics card with 512 or 1024 megabytes of video memory (it is very texture hungry), although it should still look beautiful on 256 megabytes alone. If you are wondering about performance, I get 130 FPS average on my e-GeForce 7800 GT CO. Please note that the code is largely unoptimized, and there will likely be a performance increase once the code is cleaned up. On lower detail levels, I get as high as 400 FPS. Genesis is not optimized for SLI cards, since I don't have one. Again, if I can get a card to complement my current one (I have an SLI capable system), I can optimize the code for SLI (NVidia, are you reading this?).
CPU:
Any CPU should run the game fine, as long as it is not really old. I currently run the game on a dual-core AMD Athalon 3800. The game will be optimized for dual and multi-core computers, and should run much better on these systems. However, a single core computer should offer acceptable performance.
MEMORY:
Genesis will probably require about a gigabyte of memory. Again, this may seem extreme, but memory is getting extremely cheap. Currently you can buy a gigabyte of DDR memory for less than 80 dollars if you shop right.
SOUND CARD:
Any sound card should work, as long as it is not some old, crusty relic like an Adlib or 8-bit SoundBlaster.
CONNECTION:
Even though Genesis uses a large amount of dynamic content, it should be playable on a modem due to great compression algorithms. However, a high-speed connection is, of course, preferable. Like most multiplayer games, Genesis will not be playable on a satellite connection due to the large ping associated with these systems.
HARD DRIVE SPACE:
Genesis should have a very small install size, at least relative to most games today. Right now it is only a few megabytes large, but as the number of textures increases, I would expect it to grow to a few hundred megabytes in size.