Game-Baker: Development Plan

This document is meant to show an overview of the current layout of the Game-baker code base, and discuss plans for its future. It may also be used as an introduction to the design of Game-Baker. It's original purpose was as a tool to brainstorm future changes to gamebaker.

see Architecture for more info.

Current Layout

The code of Game-Baker is contained within five separate entities. They are:

1. The GUI
2. The engine
3. the 'glue', as I call it
4. the game class definition
5. import/export/read functions

Let's look at these in order. The GUI definition is contained withing the trunk/GUI folder, and is saved as a glade file. This folder also houses the many event handlers for the GUI. The engine is located in trunk/runtime, and is currently split into init.py and paths.py. More on these later. The 'glue' technically is part of all the code files, but for the purpose of this document will be considered the gamebaker.py file. This file handles all communications between the different parts of Gamebaker. The next part of game-baker is the game class definition. This is defined in game.py and contains the class definitions for any game that is created. Finally, we come to the import/export/ read functions. These are pretty self explanatory, so they will not be discussed in the course of this document.

In the Future:

What we will be adding in future releases:

• defined paths (in progress)  Issue 63 
• arbitrary path creation (eg. bullets/projectiles) Issue 66
• networked play
• collision detection (done / in progress) Issue 17
• basic physics
• isometric support (tentative)
• pivot joints/ pins (as part of physics?)
• particle emitters (in progress)
• importing/exporting workstates
• follow cursor events (Issue 48)
• standard library of objects (issue 47)
• grid objects (Issue 21)
• better sprite management (Issue 68)
• exporting as Flash (this depends on pygame developments)
• and more...

Some questions for thought, so we can get something concrete to work towards.

• How much refactoring should we do as far as modulizing classes? I would suggest we modulize most of the classes in runtime as separate files.

• Compiler/Markup. We need to formalize a definition of what we want the compiler outupt to look like before we start work, otherwise who knows what we might end up with. Of course, the definition could always change overtime.

• What do we want our GUI to look like when we are done? (multiple windows/single frame?).

• What kind of added functionality do we want in runtime? Obviously we need to get grid objects at some point.

• ???- add any more questions here