DecouplingUseCases

Description

What do I mean by "decoupled"? In this case, I mean that the WorldForge binaries (cyphesis, ember, sear, etc.) should be completely decoupled from the worlds built on top of them. At the moment, the default install of cyphesis + ember include world configuration (config files, python scripts, media, etc), so it is difficult to create completely new worlds. It is easier to make modifications to what is there.

Rather than have WorldForge create a single online world that everyone uses, I am trying to allow other world creators to use the WorldForge binaries as engines to power all sorts of other worlds.

Much in the same way that Linux is a stand-alone (and useless) kernel from which usable Linux Distributions are constructed, so I imagine it could be possible to use cyphesis and ember as generic core engines upon which stand-alone multiplayer games are packaged. Just like Linux distros take a kernel and add a host of other applications and files, so a packaged game would include its own Python scripts and media to add game rules, behaviors, and presentation built on top of the core WorldForge engines.

Design Goals

The goal is that all elements of world creation (topography, objects, creatures, behaviors, combat systems, skill systems, graphics, animations, ...) are completely modularized and shareable. A world creator should be able to pick and choose components (any of the above) by drag and dropping file packages into a directory structure (for instance), adding a few additions where necessary, and then packaging all of the components and core WorldForge binaries into a downloadable, installable game package.

Put simply, game authors with a story to tell should be able to quickly construct a world in which multiple end users can experience the story.

End-users of these game packages could then take a fully-packaged game, set up their own server, and explore the worlds with other users of the server. This would be a lot of fun even for minimally-scalable servers (only a handful of connections), and as WorldForge binaries scale to 100s and 1000s of users, the opportunities increase.

NOTE: this decoupling effort focuses on the ability for game authors to put together and distribute functional, fully-configured game servers/clients. It is also possible to modify worlds within a game, but not all game authors will want to allow that to happen, and in any case in-game modification isn't an efficient way to create large worlds from scratch. For these use cases (game authors constructing full worlds), in-game modification is more fun as part of the game once constructed. Also, in-game modifications don't work for things like creating new combat systems, new AI behaviors, etc.

This is NOT a new design direction for WorldForge or anything like that. It is just a side project to see if it is possible to use the WorldForge binaries (which are pretty powerful engines) where this sort of decoupling is possible.

Use Cases

Here is a list of semi-explicit use cases to try to illustrate decoupling and drive design decisions. I've tried to keep use cases in rough priority order, with the most important at the top. (WC == World Creator == game author == person constructing the world)

High Priority

1. WC can specify world topography (height and terrain characteristics at specific x,y value)
2. WC can specify world objects (a 3D object with a corresponding 3D model)
3. WC can specify structures (3D buildings/objects with corresponding models, which may involve multiple stories. For instance, a large building with multiple floors and rooms, with balconies, etc. World physics, when coupled with the WC's building specification, should allow users to explore the structure.)
4. WC can specify game mechanics (character system, combat system, etc)
5. WC can specify creature Artificial Intelligence (AI)
6. WC can specify game effects (particle effects, etc)
7. WC can create a single downloadable package which when installed on a user's machine sets up a running world server (e.g., cyphesis + config).
8. WC can create a single downloadable package which when installed on a user's machine sets up a running world client (e.g., ember + config).
9. WC can copy and/or extend a previously-built world object/structure.
10. WC can copy and/or extend a previously-built set of game mechanics
11. WC can copy and/or extend a previously-built set of creature AI
12. WC can copy and/or extend a previously-built set of game effects

Low Priority

1. WC can specify world physics behavior (collision detection, etc)

Links

See DecouplingCyphesis for the genesis of these efforts, and DecouplingEmber for the client-side version.

The outcome is intended to be a functional WorldCompiler.

Great Unknowns

I'm side-stepping a bunch of tough design questions for now. Here are some hard questions:

• Can a combat system be modularized independently of a character creation system? Probably not. Is there then a hierarchy of game mechanics modules? For instance, a world creator first specifies how basic character attributes work, then different skill systems can be chosen, and once a skill system is chosen, one of many combat systems can be specified, etc.