Skip to content

Motobug Studio Project Design

Coderman64 edited this page Jan 11, 2022 · 4 revisions

Motobug Studio Project Structure

The hierarchy should be well-defined. Projects that are not in this format should not necessarily work with Motobug Studio.

Project/

  • Levels/
    • Zone1/
      • tiles.mbtiles
      • level1.mblvl
    • Zone2/
      • tiles.mbtiles
      • level1.mblvl
      • level2.mblvl
  • pkg/
    • defaultitems.mbitm
    • springs.mbitm
    • enemies.mbitm
  • res/
    • insert resources here
  • Project.mbproj

file types: (all ASCII)

.mbtiles

defines a particular tile set, including the image names, masks (if applicable), and scanning parameters

Format

should mirror the format that the tile scanner uses in the Motobug engine. Generally in the form:

[scan configuration characters]>[image path]

or (if the collision is determined by the mask)

[scan configuration characters]>[mask path]||[image path]

scan configuration characters are for collision detection and are as follows:

s - normal full scan 
n - no scan (non-collding tiles)
#nesw - scan in only certain directions, coming from the directions indicated from a compass rose. (e.g. #n would allow only collisions from the top)
m - scan using a mask

Example:

s>res/Level/CrystalGeyser/iceTile.png
s>res/Level/CrystalGeyser/iceTile-top.png
s>res/Level/CrystalGeyser/iceTile-wall1.png
n>res/Level/CrystalGeyser/iceTile-wall1.png
s>res/Level/CrystalGeyser/iceTile-walltop.png
n>res/Level/CrystalGeyser/iceTile-walltop.png
#ne>res/Level/CrystalGeyser/iceTile-curveSW.png
#nw>res/Level/CrystalGeyser/iceTile-curveSE.png
s>res/Level/CrystalGeyser/iceTile-underSW.png
s>res/Level/CrystalGeyser/iceTile-underSE.png
s>res/Level/CrystalGeyser/iceTile-ocurveSW.png
s>res/Level/CrystalGeyser/iceTile-ocurveSE.png
s>res/Level/CrystalGeyser/iceTile-ocurveNW.png
s>res/Level/CrystalGeyser/iceTile-ocurveNE.png
#se>res/Level/CrystalGeyser/iceTile-curveNW.png
#sw>res/Level/CrystalGeyser/iceTile-curveNE.png

.mblvl

defines a particular level design, including tile layout and item types/locations. Requires relevant mbtiles and mbitm files to be in the proper places

Example:

TILESET: Tiles.mbtiles
TILES:
1,2,3,4,5,6
7,1,2,4,6,8
ITEMS:
spring(1,2,3)
enemy(1,2,3)

.mbitm

defines in-game items like springs, enemies, platforms, rings, and anything else that isn't a tile or player. These should be usable as "expansion packs." Contains JavaScript code defining the item’s behaviors as well as mapping information to tell Motobug Studio how to configure it in the JavaScript level files.

These files are in XML format.

every item MUST have an x position, y position, width, and height.

hierarchy

here is the basic hierarchy for a .mbitm file:

  • itemset (all items should be in this tag)
    • item (contains all information pertaining to the item)
      • name (contains the name of the item, as displayed in MBS)
      • parameters (contains information about the parameters of the item's constructor, including types)
        • pmr (represents one parameter)
          • name (name of parameter)
          • type (the type of the parameter)
      • display (represents how the item is displayed in MBS. Currently, only colored rectangles are supported)
        • rect (draws a rectangle with the item's x, y, width, and height)
          • color (the color of the rectangle in "(r,g,b)" format, or optionally "(r,g,b,a)")
      • format (a formatting string for the item's constructor. Parameters must be the names of parameters defined above. Four of the parameters MUST be x-position, y-position, width, and height)
      • code (contains the code that defines the item. This is optional if the item is already defined elsewhere in Motobug engine. do note that "<" and ">" aren't allowed here, due to XML. Replace these with "<" and ">".

Example

An example can be seen here. Do note that it does not contain any <code> blocks, since it defines only items that come default with Motobug Engine.

.mbproj

the main project file contains references to necessary files, as well as Zone order, backgrounds, and other important info for the final game. Currently used only as a placeholder to mark the root of the project.