basic framework

[mrozbarry]

Program in C. That is basically industry standard for games.
Do a MMORPG - similar style to WoW.
For graphics, use SDL and OpenGL. Both of these are open source, and we can write our own engine. If we're not comfortable making our own engine, and want to have very large download sizes, we could use Ogre3d, which is a free, open source, game engine. It does more than 3d, so it may be a good choice.
Most of the modular code should be in Lua script. This is very portable, and very fast, and once again, free and open source. It can be very easily and powerfully integrated into the game engine (C code), and we can write C functions to work in Lua, and visa-versa.
As far as graphic design goes, I believer blender is probably the best bet - it's free, and it's powerful.

Here is my concept of the basic game loop (pseudo code-C):

while( not exit )
{
refresh.screen(); // or something to that extent
get.input(); // keyboard/mouse stuff
run.scripts(); // this may be in a seperate thread, depending how often we need these to be run
update.player.info(); // tell the server what you are doing
update.network(); // the server tells us what everyone else is doing (in a certain radius of your location on the map)
do.framerate(); // self explanatory
}

Questions? Comments?

[mrozbarry]

I forgot to add that most of the Lua parsing should be done from DLL files. This means no full recompile after every update to the engine.

File layouy:

game.exe
* render.dll -> loads Lua files for how to render, which models to use, etc.
* network.dll -> handles how the network interaction works (protocols, sending appropriate data to functions, etc.), Lua files that may need to send data to other Lua systems
* plugins.dll -> addins, like interacting with dll/Lua plugins
* others?

Keeping things module means better productivity. Updates take up less space, no full recompiles every time (although I'm sure it will happen on occasion depending on what components are updated, and how they interact with the full engine).

I hope that gets the brain juices going.

-Oz

[CGAdminEric]

Breaking parts of the game engine into dlls is very useful. You can dynamically load and unload dlls, so that you can update them (conceivably) without shutting down your program.

The architecture of a game engine is extremely important to get right. Your game loop is missing pieces...unless refresh.screen() or other routines is intended to have these pieces in them.

The rendering steps are many, so your refresh, should be more like...
updateWorld()
renderWorld()

or wrapped in a single all...assuming that updateWorld and renderWorld should happen together...which they might not. I'm not a 3D programmer, so I don't know all the issues, but have dealt with enough issues surrounding our game engine, to know that this is a rather complex issue.

The networking aspects are probably best enapsulated in a single update where you send and receive data. Also keep in mind that network updates could be in their own thread.

Speaking of threads, you should consider that future game engines must deal with having 'n' number of threads and make good use of them in the engine.

And your last item, is just one of many statistics you'll be updating. You'll be wanting to monitor a heck of a lot of data..you'll want to know what's going on inside your engine so you'll need probes and other ways of gathering this info.

Eric

[MirariSoftware]

Um... I believe this project is doomed for failure fundamentally for 2 reasons...

First, the whole Analyze step of the software design waterfall has been skipped and you have jumped right to design.

Second, your platform is all wrong. Because of publishing issues, you may find it very hard to get a copy of your game in enough peoples hands to make this project worthwhile. You should, instead, build it in java and then they only need to download a small framework, then the "meat" of the game is pulled from the servers. that way, you don't have the extra cost of buying and burning CDs and paying some very expensive fee to get this thing sold by someone.

Then the funds come in from integrated ads directly in the application.

So essentially, you build your own specialized browser that can only pull content from two places: the game servers and google adsense.

[king of the unknown]

call me a little of subject but a good game is based on inivation not because of techlical skills... take games like the Katimari series, where you roll a ball around to pick things up...