This page is meant to outline the module system which is a feature that we are hoping to add to Wild Pockets in the near future.
Module System[]
The ProblemCreating Games is HardThe Plan Allow users to create mash-ups of games from component parts
The Difficulties
Making user created component parts play nicely together. Allowing users to tweak components to create unique gameplay.The Idea Define standard sets of interactions between objects. Create two levels of editing an object, properties and script editing.
Goal[]
The goal is to tie the behavior of objects to the places that people would normally expect the behavior on real objects. For example, when you pick up a gun in real life, you have two interfaces, "Point the Gun" and "Fire the Gun". The gun will take care of the fiddley details such as igniting the gunpowder, directing the bullet, automatically moving the next shell into place, etc. Because the interface is the same for almost all guns, most people can pick up a gun whose internals are compeletly different and use it. The same with our minds and bodies. When we want to walk to the door, we just think about "Walk To Location" and our body/brain takes care of all the electronics to get our muscles moving, our bodies balancing, etc. If we can abstract behaviors onto virtual objects the same as real objects, it will be drastically easier to both understand complex game behavior and to moduliarize it. Imagine in a game, being able to switch out your avatars weapon with one written by an anonymous user and as long as the interface of "Point" and "Fire" exists you can immediately use it.Wrap the "Point" and "Fire" methods into a class named <Weapon>, now the avatar that you've written can use any object of class <Weapon>.In addition, if you filter your global library to show only <Weapon>, your avatar can use anything from that library search.Take that one step further and in game be able to switch out your avatars body from a human to a spider robot, and as long as the interface of "Walk To Location" exists everything runs the same, just with a different avatar body. This goal of the module system is to separate game pieces in a way that makes sense and guarantees that they work together.
Modules[]
A module is a object in the world that has scripts associated with it. A rocket launcher, fighter jet, or 1-Up Mushroom could be a module.
Modules have one or more classes.
For example these three module are all of class <Weapon>.
Each class has an interface that defines what kind of methods it must implement.
These methods are standardized, for example the <Weapon> class has the following interface:
- Fire()
- Reload()
Since the methods are standardized, then any avatar that uses a <Weapon> can switch out modules and everything will work. Each module has a control script that makes the module work. For example the AK47 script creates bullets and applys forces to those bullets.In addition it would assign a collision handler so that the bullets do damage to whatever they hit.
Tweakable Properties[]
In addition, each module contains tweakable properties.For example the AK47 module would have the following tweakable properties:
The tweakable properties are used in the control script to modify the behavior of the module, but the properties themselves are exposed to the user in the builder.The idea behind tweakable properties is so that a novice user can bring in a module and make significant changes without having to modify source code.
For example, you drag in the AK 47 weapon, but you can tweak the "Clip Size" property to 1 and "Damage" to 100.
Now you've created a sniper like behavior without having to touch code.
This allows for a large amount of variation and play for a novice user.
In addition to just numbers, tweakable properties can contain other modules.
An example of this is an avatar.
One of the avatars tweakable properties is its weapon.
This property would expect another module of class <Weapon>.
So you can lay down an avatar that comes with its Current Weapon property set to AK47.
A novice user can swap out the AK47 for a Rocket Launcher since both modules have the same interface (Fire, Reload).
Advantages[]
The advantage to the module system is that it allows us to specify standard interfaces for user content to allow them to all interact.
While we specify the interfaces, the modules themselves are extremely customizable.
For example an avatar must have the following interface
- MoveToLocation()
- MoveForward()
- TurnLeft()
- TurnRight()
This interface allows for an avatar to be anything from a Elf to a Spider Robot.
Since there is such flexibility, users will be able to create there own unique modules.
This reduces the burden on SimOps to create content that works well with other content.
The module system also allows for different levels of skill, and more importantly a nice blending of those levels.
For example, in real life, a novice user can easily use a gun.
They can point and they can pull the trigger.
If they want they could even load different ammo into the gun.
But a more advanced user that knows how a gun works, could take it apart and modify the internals to suit their needs, or even build a brand new gun.
As long as the interface remains the same, the naive user could pick up and use this newly created gun without a problem.
The path to take an existing object and customize it isn't novel, but the ability for a novice user to use the newly customized object is extremely important.
Communication Channels[]
Modules by themselves need to be able to interact with other modules, even if they are not part of the object. An avatar module needs to be able to call the "Fire" function on the gun module that its holding.The bullet fired from a gun module needs to be able to call the "Take Damage" function on whatever it hits.These channels can be unified via the module system as well. In this example, if your module implements the class <Killable> then it must have the following functions:*takeDamage(amount, (optional) type)
- die()
This way, the creator of the bullet script just needs to check if what it collides with is of class <Killable>, then it can call these functions.
Standardization[]
The core to this whole idea is that we create standard ways for things to interact.These classes that define interactions will be split into to categories, Official and Non-Official.Official classes are created or vetted by SimOps and are guaranteed to never change.This allows for users to build content that relies on an official class without any doubt that it will always work.But in addition to official classes, we should not restrict users if they want to play and design new cool classes.In fact we should encourage it, since the creation of these classes could produce really awesome things, and the best classes we can adopt as official.This is a good point to repeat the idea that the only thing SimOps is trying to regulate is the interfaces between objects.The regulation of the interfaces is the key to allowing user modules to work so well together.
Versioning[]
In order to accommodate changes to the standard, we may want to consider versioning <Avatar v1.0>
Since it is almost guaranteed that we won't think of everything versioning will allow us to change the standard without mismatches.
A <Gun Model v1.0> would work in a v1.0 slot, but not a v2.0 slot, since the second might expect methods that aren't there.
A <Gun Model v1.5> would work in any slot equal or less than v1.5 because the lesser slots should still be able to find the methods they need.
A <Gun Model v2.0> would not work in any v1.0 slot, simply because a major change might not have the same methods as before.
Subclasses[]
It would also be benificial to implement a hiearchy of classes.For instance a <Flying Vehicle> would also be of class <Vehicle> and of class <Model>.Or a <Bipedal Character> is also of class <Character> and of class <Model>.This way you could have a weapon that shoots anything of class <Model>, so it could shoot practically anything, even if it's also a <Bipedal Character>.
Art Pipeline[]
One of the base classes <Model> is the container for geoms and animations.
A model can include a geom and as many animations as needed.
This can be used to couple animations with geoms, which we've needed for a while.
The art exporters should be able to produce a model with animations and anything else that should be coupled with the model.
Other things may be attached such as textures, sounds, etc.
Ideally the exporters should be aware of classes, so if you want a character it can tell you that you need to specify a "Walk", "Turn" and "Jump" animation.
Example[]
Below you can see a fully functioning avatar made up of its component pieces.
Completely laid out this may seem like quite a few components, and it is because an avatar is a complex system.
The benefit though is the tree structure which allows you to focus on individual parts.
For example, most users would never open the <Char Model> of Rocket Dude, they don't care about its animations or geoms or textures.
But this system allows them to not care and still use the module.
Features Still Needed[]
This module system is a huge first step, but we'll need additional system to create fully functional games.Global systems that keep track of score, game state, loading/saving, etc.We'll need to tackle these problems before game creation is really as easy as we anticipate it to be.
Appendix A : Avatars in Detail[]
The word avatar has been thrown around a lot so here is a more detailed look at what that means.An <Avatar> does not refer to a particular model of an alien, or zombie, or spider robot.It instead refers to the behavior of the character that the player is controlling.Some examples of behaviors:"Mario Avatar"
This avatar can simply move and jump. It applies damage to anything it lands on.
"Link Avatar"
This avatars does not have jumping controls, instead it will jump when it runs off of a ledge.
In addition it can hold onto a ledge and climb ladders.
"Bouncing Ball Avatar"
This avatar does not slide, instead it bounces around the level.
"Prince of Persia Avatar"
This avatar has scripts to run up walls it encounters and perform crazy aerobatic maneuvers.So an avatar is a collection of behaviors and in addition an avatar will generally refer to a <Character Model>.The <Character Model> is responsible for the visual appearance of the avatar.Since this property of the avatar is a module, it can be switched out easily to change the avatars appearance.Here are some examples of <Character Models>*Night Elf
- Alien
- Spider Robot
- Pirate
Each of these <Character Models> comes with standard animations, so they each know how to walk, turn, and jump.So you can create a "Link Avatar" with a "Pirate" model, or a "Bouncing Ball Avatar" with a "Night Elf".This will allow for some interesting combinations.Also, since the behavior is tied directly to the avatar, the gameplay will stay the same even if you switch out the visual <Character Model>. (With exception to collision?)As a bonus feature, when working on a team, the programmers could give the current <Avatar> to the artists and they could replace the <Character Model> to test drive their new art.
Appendix B : Controllers[]
Above, the idea of controllers is glossed over.A controller is responsible for calling methods on an avatar.This controller could be an AI, or a remote control, or a director.The default controller for an avatar is the "Remote" <Controller>.This controller basically hooks up the wasd keys to the avatars movement functions and lets the player manually drive the avatar around.It's important to note that a controller is a child of an avatar (Though it might be beneficial to explore reversing that order).So a child of a module should be able to call its parents methods.We can't guarantee the class of a childs parent, so it will have to gracefully handle methods that don't exist for that class (Telling an AK47 to "Walk Forward").
Appendix C : Overarching Systems[]
Overarching systems control the games flow instead of the interaction between the pieces.Some Examples: Intro / Menu ScreensWe need a system to make the switching of game state super simple. Developers should not get hung up on loading screens, level switching, menus, etc. Scoring / Goal SystemA system for determining a users progress through the game and reward system for their effort. Bonus points for a way for the scoring system to automatically connect to a leaderboard. Boooom SystemQuick easy visual effects. Grid SystemA system for having grid based movement with ways to query occupied spaces, generate path movement, etc. Which systems are active probably depend on the genre of a game and should be controllable either by the developer, or by modules needing the systems.
Appendix E : COMMENTS![]
Please leave comments here:
Jesse sez: Off to a good start! Some thoughts I had in my head, I'll just dump them here:
1) I think there is a hierarchy of structures here. I think the top structure is "genre", maybe? But is that true? At first I thought it was -- maybe race genre, fps genre, etc., but now, I don't know if I believe it... why not be able to mix and mash racecars into your shooter... yeah... that's probably right. hmm... so what is the hierarchy, if there is one? Well, let's see... what every game needs:
a) Every game needs a goal. When you reach the goal, you win. Possible goals:
i) Get x points
ii) Collide with x
iii) Eliminate x
Hmm... as I think about it... I think every goal can be represented as points. If the goal is to get out of a maze, give one point for colliding with the exit, and make getting one point the goal. So -- yeah.
b) Every game needs a score. Especially if all our goals are points related! So -- there should be many ways of getting points.
i) When avatar collides with x, points are given
ii) When avatar shoots x, points are given
iii) When x disappears, points are given
etc.
So, in other words, whenever something undergoes a transition, it may choose to award points.
c) Timers. Well, maybe not all games need these, but they are handy. After x amount of time, y happens.
Now -- we've all been down some of these paths before, and we know that this stuff can get complex. So, here's the slogan we should all live by:
FUCK COMPLEXITY
Do this the way google or twitter would do this. Sacrifice flexibility in the name of clear understanding and simplicity. Many things can be done by combining simple elements.
Oh -- also -- there should be a lot of customized explosions. Because that's super fun. These games should be SUPER JUICY. If I want to shoot a car and see it explode into a bunch of sheep, I should totally be able to do that.
Oh! and for controls. KEEP THEM SIMPLE! Don't make them programmer controlled! Come up with simple, switchable control modes, and let the modder switch to one that is appropriate. I would come up with simple controls like:
WASD running, with mouse turning, and fire button
3D flying with mouse
top down arrow based control scheme
etc.
Anyway, come up with simple, standard control mechanisms, give each one a name, and then only let the modder control velocities on each.
Ian Responds:Great feedback!The modular system above is only half of what we're going to need to fully make mash-up games. The stuff you're hitting on is the other half that needs more design and discussion, communal modules that are shared between game components. The scoring system, the make big explosions system, the make simple intro/success screens system, etc.
Ability to combine objects from a global library + Overarching systems that control game flow = AWESOME
So I'm adding an appendix for overarching systems. Also I completely agree with the simplified controls. I'm picturing a class called <Controllable> that implements a moveForward,moveBackward,turnLeft,turnRight,jump. This way any module that implements <Controllable> can be quickly hooked up to WASD.Not only that but an AI knows how it should hook up too. (Need to standardize sensors too probably for an AI)