Mubbles

QTMBA (Questions that may be asked):

What is Mubbles (supposed to be)?

The basic idea for Mubbles came from a game called "Geometry Wars(R)" (which you may know from as a XBOX360 arcade game or maybe even a much older version). In that game you have to hunt and destroy several geometric forms to earn highscore points, new equipment for your ship etc. .

But because the OLPC project is about education the main goal of the "game" is to get the kids involved in creating their own version of it - to modify it.
Some steps for them could be to influence the form and color of the objects, their behavior, create their own objects and share them with others over the mesh network.

I dislike the concept of a violance centered game especially as an educational project. So I came up with the idea to treat the geometric objects as creatures. They could then interact with each other or just show some bevavior.

It would still be possible to program some kind of "ship" and make it controllable by a player.

What programming language does Mubbles use?

Python

How could one ensure that the modding is simple enough?

The basic idea is, to create a base class (or classes) which holds the necessary functionality an object needs in the Mubbles game world and to implement some specific yet simple objects (i. e. a circle). It would then be possible i. e. to change a single value in the source code (like color, size). This would give immediant feedback to the kid and it's just changing a number. You could do a subclass and overwrite a specific function to change a more complex behavior i. e. how the object moves or how it is animated while keeping the rest exactly like it was so your code does not get cluttered. Of course you can create a whole new object completely by your own by subclassing and overwriting.

Why use the name Mubbles?

This is just a crude combination between math and bubbles (= Mubbles) :).

A first visualization

Basic ideas of elements

The following piucture shows some potential objects in the Mubbles playground.

1: This is a basic outlined and filled circle. Think of it floating lazily over the screen, bouncing back from the screen borders. The code for it should be in a seperate python file. There should be simple understandable variables/properties for the numerical values the objects consists of like: outlineColor, fillColor, outlineThicknes, center, radius, name.
The kid could easily copy the file, set new values for these give it a new name and restart the game. Because of a new file in the "objects" folder a new object gets added to the playground and floats around.

2: This is an other basic object with almost the same basic values. (An other python demo file).

3: This is a more complex object composed of one of the simplest. The big circle still drifts lazily around the screen but the four sattelites rotate around its center. There are multiple colors (multiple stacked circles of a single color) in the big circle. Its behavoir has not changed. But there is a new beavoir for the sattelites. Let's call this thing "mothership".

4: This object adds to the basic form of the circle a much more complex shape. It is supposed to resemble some kind of aircraft and was originally designed to represent the player ship which could be directly controled. (A lot of new code would be necessary for that.) But as I said in the QTMBA the basic game should not include the element of fighting but more the element of individual creativity in designing new mubbles.

5: This represents a graph of a mathematical function or a visualization of static (or also dynamic) data. In this image it is supposed to be a preview for object number 6.

6: Think of it as the function graph (5) wrapped around a circle. (Finally something fun to do with all that functions your math teacher throws at you :). ) I. e. it could constantly morph by iterating through a ever growing range of input values while keeping the simple drift behavoir of the circle.

More advanced concepts/ideas

The objects discussed so far and the understanding of the program code may come from math teachers. For now there even wasn't any kind of text involved (except the program code and there are already enough discussons about how universally understandable and "language independent" code is). So what else could be done?

Well think of advanced behavoir: friction, mass, speed. An object could go faster or slower each time it hits an other object. Collision detection has to be done here as well as some other physics. How could an object reproduce, hunt for food or die (biological aspects here)? I. e. when to objects reproduce (obviously some additional programming has to be done to anable them to do that) the offspring could inherit some simple properties of its parents like a mixture of their color, or the thickness of the out line from one "parent" and the fill color of the other. This could be done by the known rules of biological inheritance.

Would it not be cool if a pupil would come up with just a simple circle in which he changed the behavoir to follow other objects and maybe even let his circle "eat" them? How about "undead" objects which return when they are supposed to die and counter objects which can cope with that? How about objects forming a flock/herd and counter objects that "hunt" in a pride/pack? Think of a mubbles which acts like a plague and spreads from object to object.

I don't claim that every suggestion is fully thought through (especially concerning coding effort) but take this more simple idea: Think of the "mothership" gathering its sattelites by adding other free floating objects to itself.

Comments

The game's intention is not to deliver all those objects/mubbles mentioned but to deliver a framework for them which should be easily extensbile and explorable. The mubbles mentioned here are just to get some ideas flowing what might be possible with this framework.

This page is also supposed to hold information about what individual problems need to be solved throughout different development stages. That means it should teach about different aproaches to solving these problems and how a programmer "has to think" about them. So I am planning to add a section about some techniques for collision detection in the near future. Teachers should feel free to add descriptions about basic mechanics for example. They must not be necessarily on this page but an a more general purpose one and get linked in here, though it would be cool if their contributions could be directly related to this project.

Networking

• Share your mubbles over the network.
• Sign you mubbles and earn reputation :).
• Share your playground and let your mubbles interact with those of your friends.

Additional ideas

These ideas are just thrown in and will be sorted out later:

• increase playground field to be n-times bigger that the normal screen
• add camera control and effects (i.e. camera shake)
• What threats to the system do exist? (I. e. a kid figures out the it is possible to create a mubble which deletes all other mubbles in the object folder. This would be cool in a way :). But is there also a threat to system critical files?)
• Make a context dialog possible for each mubble, so that some properties can be changed while the game runs.

Development

What needs to be done?

• Basic framework with lots of possibilities (all knowing, all seeing game environment).
• Plugin structure for the individual objects so it may even be possible to receive new mubbles via the network while running the game and they get dynamicly added.
• Demo implementation of some objects.
• Extend this list ... :)

Things to come on this page

• some thoughts on collision detection
• basic concepts of object orientated programming direcly related to this project
• built in possiblilities of pygame useful in this project

Some stupid demo code

You should have Python 2.5 and pygame for that version installed. And you should know how to start python programs, because I will not describe how to do it, at least for now. You should save the downloaded Textfiles with a ".py" file extension (They aren't allowing *.py files in this wiki.

Mubbles base program
"BumbleBee"-Mubble You'll need this for now so the program will run.

The Environment

The environment supplies some general information and "hooks" that the mubble objects can use. This is an incomplete list of those variables:

• environment size (NOT! pixel based - I want to go for a generic unit based system that is not dependent on the actual display or pixel size.)
• peekSpawnpoint(onScreen=false/true)
• getSpawnpoint(onScreen=false/true)
• all active mubbles
• all active display layers
• all collidable objects
• get random path on screen / off screen
• some paramter based random number generation functions
• location of the mouse pointer
• manage system events

later features:

• network code to connect your mubbles playgrounds (share the activity)
• browse and download shared mubbles

This is not supposed to be the discription of a single object. The environment is something like a framework, which each mubble can use.

Mubbles is stricly 2D although "existence" layers may be used. Think of an "unlimited" number of transparent pages stacked over each other. The mubbles can choose on which layer or layers they want to live on. There is a high probability that there will be some named default layers.

The Abstract Mubble

The abstract mubble may supply the following variables:

• name
• creator
• version
• object center
• scale factor
• bounding box / rectangle (look out for all those "rects" in pygame and pygames sprites!)
• update, draw, (collide?) function
• active layers
• the environment object
• functionality to draw the bounding box
• context menu (right-click)
• actual outline of the object as a series of coordinates; the amount of points could be specified in the function call
• lifetime
• speed and heading vector
• behaviour descriptor (because this should be changeable this has to be implemented as a new class)

(An adapater class should be supplied.)

Q: Are dependencies allowed? Some effects a mubble could spawn may be implmented as mubbles themselves!? So the mubble has to check if its "package" is complete.
A: When a mubble gets subclassed there is automatically a dependency! Missing dependencies are definetly a thing to worry about and the environment has to manage missing dependencies so the game does not crash.

Q: What if a mubble consists of multiple mubbles?
A: It should be possible to supply a more complex mubble in a single file by defining needed classes before the "main" mubble in that file.