MV3D Development Blog

Well, I just realized both MV3D servers (including the one that hosts the development website) aren’t totally back up after a power outage the other day (got to install that UPS!), so instead of posting this to the dev website, I’m forced to write it here. Oh the horror! Sorry if I jump around or write about steps a and f, but miss b,c,d, and e. You should be used to that if you read stuff here often though.
I just did a little research, and it seems like it would be no problem for me to create a view setup similar to any 3D modeling program within Ogre. I can split the screen into 4 boxes which can show views from the top, side, front, and what your character sees. The top/side/front views could easily be set to wireframe as well so that you can see through objects. This will probably be useful in World Editing, though I think I may make it an easy option to switch into (say hit F10 or something to swap between normal view and that). Placing and moving objects with those views should be a snap because it would be very easy to line them up. The cameras for all the views should be independently controllable just like a 3d program.

Next, ideas for creating objects. I need to create an asset type for ClassGenerators if there isn’t one because when creating an object in MV3D, you just need an area to put it in, and a ClassGenerator. The ClassGenerator specifies the Python class that is becomes the object. More on assets in a bit. Somehow, you’d need to be able to select an asset to use as the object. That would require an asset selector. The asset selector should probably show assets from a particular asset group and should be configurable so that only assets of certain types are selectable. So that way, if you specified it should only show object creating assets, it would do that. Anyway, once you select the asset, it should let you place it.

Editing objects. All Objects should define a GUI for editing their properties. Since the properties for each type of object are completely different, this is definitely necessary. Part of me wonders if it would be best to generate the GUI in code, or even dynamically. Doing it without that would mean that developers would have to design (by hand) the GUI and code it for each object type, making creating new object types more of a pain. It would be easier on the developer to inherit from somewhere and just add to the properties GUI from there; however, that may cause retarded looking GUIs. Either way, a custom GUI for each object is necessary because for instance, a PC type object would have editable properties for health, experience, and so forth while a rock sitting on the ground would not.

Defining assets. This could be something that is best left outside the game. Many things in MV3D are specified by an asset (which is part of an asset group). For instance, images, models, sounds, pieces of code, and GUI layouts would all be examples of assets. Asset groups are just a way for people to say “these assets are part of Mike’s medieval fantasy pack” or whatnot. Anyway, the assets themselves will always be edited/created/etc outside of the game in 3D software, text editors, GUI editors, etc. It probably makes sense to have some sort of program that lets asset creators add, modify, and delete assets in a simple fashion that connects to a game server in order to register the assets within the game automatically….. oh… DUH! This sounds like the job for a WebApp. Asset creators could log in to it, upload the asset to the web app, and edit all the asset metadata. Cool. A good first step would probably to just be able to edit asset metadata. One issue is that there can be any number of asset types which can have completely different metadata. For a silly example, one asset type downloads via HTTP/FTP so it requires a URL. Another one may use some peer2peer mechanism to download and require whatever info for that. So, there needs to be a way to generate and parse HTML forms based on the structure of an asset object. I think that’s do-able. Ok, way off subject here. But first, you know what would also be cool? If you could dump a .3ds file on the web app and it would run Ogre’s conversion utility to generate the Ogre .mesh file and stuff. That would be cool.

The other major component of the world editor will be related to modifying the terrain. I’ve discussed this a bit in other places, but the general idea for terrain height modification is to show a greyscale image where lighter colors represent higher points on the terrain and allow the user to ‘paint’ over it with various operations. I think the image shown should not be directly used in the heightmap as each pixel in the image is limited in range between 0 and 255 and is an integer whereas the value for the height of that image can be a decimal number between… the extents of a 32bit float. (-a lot to +a lot) I think in the old MV3D, I made 0 be the lowest point in the terrain and 255 be the highest and everything in between would scale accordingly. That’s probably a good idea still. It would probably also be nice to be able to adjust the points in the 3d view as well.

In addition to adjusting the heights of the terrain, people will need to paint things on it such as roads, grass, sand, rocks, etc. (I’m talking flat texture maps on the terrain) For this, I’ll need the splat material compositor I’ve been thinking about working, but other than that, it could work similarly to the height editor with its image that you draw on. Painting directly to the 3d view should work as well. In addition to flat things, there will be non flat things such as vegetation. Once again, this could work similarly to the height editor.

One problem with editing the terrain will be that MV3D’s current terrain consists of a grid of terrain blocks which are not really connected to each other. Somehow, the editor will have allow you to modify the heights of one terrain along the edge, the heights on the corresponding edge of the terrain next to it will need to be modified as well.

I just had an interesting thought. Maybe it makes sense to not separate out terrain from regular objects. In MV3D, terrain is a regular object. Some places won’t have terrain even. So, all these terrain editing details could be part of the terrain object’s properties. That actually could work very well because some terrains will have features for grass and such while others may not.

Finally, not all objects in an area are viewable on the client. Some things just don’t have a visual representation. That makes them a little hard to select with the mouse. It should be possible to pop up a window that lists the content of the area and lets you select things. Once select something, it jumps into the properties of that object. When editing those objects, it may not even be possible to place them, so placing objects will have to be dependent on the type of object. That means the placement code should be part of the object properties GUI.

Ok, that’s probably enough blabbing for now. This is going to be a lot of work to put together, but it should be pretty kick-ass in the end.