RFC Game Project Manager

Thanks to everyone who has been so helpful getting me ramped up on Blitz3D the last few weeks :) I think I'm far enough along to start seriously working on my first game, but I've noted one major thing that could make life a whole lot easier for everyone -- We need a Game Project Manager and I'd like some input for features and abilities.

Basic concept:
GameManager will be an IDE + runtime library for managing artwork, models, and maps, performing automatic conversions and processing when source artwork changes, and through various tool programs, allowing the designer to configure the runtime properties associated with a model instance (more on this later)

As an IDE, GameManager is not intended to replace apps like Protean, though it will provide some basic editing and compile capability for testing. Instead, GameManager assists in the creation of your world, be it terrain or interior based. As you add/edit models, drop props on terrain, and define the behavior of props in your world, GameManager and its tools read the model/map files and, using either automated tools, or gui based editors, allow you to setup the property data that will be used by the runtime library to load and manipulate your level.

To avoid the "I'm locked into this stinking framework" issue (Yes, I can hear people griping already), GameManager will provide a plugin interface for interfacing tools, automatic processors, and custom property editors to the IDE. Plugins can, if appropriate, include runtime extensions which will be built into the runtime library when a model or map uses the specific plugin. By rebuilding the runtime library based on the specific tools that you have chosen to use, GameManager will avoid the "code bloat" that a more generalized, limited runtime would have if it tried to support all the different GUI / model / terrain / lightmap / other tools currently availabe.

Initially, I'm planning plugin support for the following apps/tools:

Advanced Landscape Editor
AlphaGUI
XlntII GUI
Tokamak Physics

and a couple of tools that I plan to create as part of the project:

CS_Exterior (90% complete): auomatic/manual external visibility scanner/editor for large complex models. Intended for terrain based games that have buildings with complicated interior layouts. CS_Exterior computes the surfaces of the model that are visible from outside the model's bounding box, and stores that data in the model properties file. The runtime library extension tests the player position against the bounding box of the model, and appropriatly activates/deactivates the interior geometry of the model. In tests, CS_Exterior has reduced the visible poly count of some models as much as 60% on models that have little interior detail. The more detailed your interior is, the greater the reduction.

CS_Interior (10% complete): fully automatic CSP visibility generator for interior maps. Creates a matrix of visibility data for use while a player is moving through a model. The runtime extension will manage the showing/hiding of geometry in real time. Suitable for use on terrains, models used as building props on terrains, or stand alone interior maps.

The core runtime library will support loading entire levels by reading a single master property file for the level, and will keep track of everything loaded for easy unloading before switching levels. Access functions to fetch the mesh/entity handle of a model will be provided, as well as an UpdateWorld function that will process each loaded entity according to the loaded property set for that entity. Specific plugins may provide additional functions for use by your game logic in addition to any automatic processing features that the plugin adds to UpdateWorld.

Your ideas and suggestions will be very much appreciated :)

Sounds like a big lot of work. Especially the Tokamak part. And make sure to test the CSP VIS part, it is only useful for some special situations and the whole Hide/Show jobs can easily slow things down.

I wish you good luck for this project.

It is big -- but not as bad as you might think. (Thank you, C#.Net)

I assure you it's gonna get tested to the hilt -- my 1st game is gonna combine terrain CSP with in-building CSP. A 2 layer setup to really cut down the poly counts :)

If hide/show is only done when transitioning from cell to cell in the CSP matrix, it shouldnt cause much of a problem. Only have to deal with what was visible from the last cell getting turned off, and what in this cell needs to be turned on -- should be reasonably short lists in both cases.

Also, if you dont tell the IDE to generate CSP data for an object, its not going to do CSP in the runtime -- so you have full control :)

I've only read up a little on tokamak, but it seems pretty straight forward how you define the physics properties of a given object.

Ive built one for a commercial project, and I am currently writing one for game development, its alot of work, but they are really something the indie/shareware community needs.

So many people start the "ultimate game" project with no real plan beyond a title, and a small premise, and start coding, and how many MMORPGs were started on these forums alone? How many made it to the fully playable stage? Or even had the mechanics of the game designed? My bet is almost none.

I would get laughed out of anyjob I have done with out a comprehensive plan, with everything outlined.

I was glad to see this thread, wish you lots of luck and fun doing it. :)

hehehe the fun has already begun :) I wont even begin to code core game logic until I have a working pipeline from the artists to the engine that is fully tested. I dont intend to get stuck because I'm fighting issues other than learning the blitz engine.

Already got the explorer section and the basic plugin system in place. Plugins are "extension sensitive". when you select a model in the explorer for the 1st time, you get a checklist of plugins for that extension in a tabbed area of the screen. As you check/uncheck the plugins, tabs are added and removed that give access to the properties & actions exposed by that plugin. You can go back to the "Global" tab and change the active plugins for a file at any time.

For instance:
>you have a file test.3ds

>you select the Convert 3DS plugin and set the options to convert to b3d, and to autoconvert if the 3ds file is updated

>after clicking "Run conversion" or "Build Project", you'll have a new model in the explorer, test.b3d

>for test.b3d you select the ExteriorVis and InteriorVis plugins. Setup their options, build again, and you have CSP/ICU visibility data for both outside and inside the model.

and so on and so on.

some plugins will work on the files in place, others will output new files so you can define chains of processing step by step to get exactly what you want. And all with the idea that when you build the project, any source files that have changed trigger the tool chain to process the changes.

I've got a partial plugin interface and a sample plugin if anyone wants to get a preliminary look at how it fits together. The plugin interface WILL change before I'm done. C#/VB.Net/VS.Net 2003 required (unless you like beating your head against a wall creating COM objects in C++)

Pretty simple really, define the basic plugin which isnt much more than the file extensions, and a UserControl that will be the plugin properties page.

"How many made it to the fully playable stage? Or even had the mechanics of the game designed? My bet is almost none."

Well, since I agree that a good project manager helps a lot (although it might be even harder to build a project manager than to build a game at all), I have to say that it is possible to work out a usable game engine without a manager.

I did it and I guess the latest version of my FPS Engine isn't that bad. If I compare my work with the work of any commercial FPS game, I think it's not bad at all if you consider that I am a one man team with a little help from 2 or 3 guys, while the commercial engines usually list hundred to 150 persons or jobs in the credits.

I do agree a Project Manager is a must when a lot of people are working on one game.

Actually jfk I meant a plan, not a project manager.

"So many people start the "ultimate game" project with no real plan beyond a title, and a small premise, and start coding, and how many MMORPGs were started on these forums alone? How many made it to the fully playable stage? Or even had the mechanics of the game designed? My bet is almost none. "

A PM would help alot, but its not really needed if they are organized, thats also why I said "almost none" because there are coders who can do projects with out a plan. I used the MMORPG reference because its impossible to design a real MMORPG with out a plan. No matter what anyone says

@Falelorn: you know it -- I've been off and on thinking about doing an MMORPG for about 3 years now, and even now cant say that I have it all planned out.

@jfk: This isnt a project manager in the style of Gant Charts and such -- though we could certainly do a plugin to manage the per-file data, and display charts.

After hashing some things over last night, I came up with a new idea -- instead of requiring a DLL plugin for every external app, I'm creating a "simple plugin" manager. Allows you to define properties/fields that the user can edit per file, and actions which execute external apps with field data passed on the command line.

That should limit the creation of plugin DLLs to the more complicated apps/processes, make it easier for anyone to customize the system for the tools they prefer.

Just about done with the plugin editor, once that and the SimplePlugin module are done, I'll post up some screeners :)

I could use some help with one thing -- collecting freeware/open source apps that would be useful to include with the package, and creating the plugin definitions for them. When it comes time to release, I want to package it all together so GManager is instantly usable after the install :)

If you help out on this, I'm particularly interested in apps with source code so we can tweak them to work better with GManager.