<> I S O M Y R
A Python Isometric Game Engine
i-so-myr: (n) Any of one or more scenes with the same measurements in
foreground and background, that have different properties and can exist in any
of several game worlds for a measurable period of time.
Isomyr is an isometric game engine based on Pygame, and written in Python. A
fork of the Isotope game engine, it provides the framework for constructing an
isometric graphics game with actors who can pick up and drop objects, jump onto
plaforms, and move about in projected 3d isometric environments.
- Actors: used for player and monster game objects. Capable of facing, gravity,
collision response, jumping, automation and inventory.
- Multiframe animation and images.
- Simple physics simulation of velocity, collision and touch detection.
- All objects can be customised and extended using Python.
Isomyr currently has the following dependencies:
If you want to develop for txSpore or use the latest code we’re working on, you
can install from the sources. You’ll need bzr installed, and then just do the
$ bzr branch lp:isomyr
$ cd isomyr
$ sudo python setup.py install
You can use the setuptools easy_install script to get txSpore on your system:
$ sudo easy_install Isomyr
You can manually download the source tarball from the Python Package Index by
visiting the following URL:
You’ll need to untar and gunzip the source, cd into the source directory, and
then you can do the usual:
$ sudo python setup.py install
Checking the Source
Once installed, you can test the source code by executing this from the
top-level source directory:
That will run the test suite and report on the success and failure of any unit
In the top-level source directory for Isomyr, there is an examples directory.
This contains the following:
- The original example from Isotope, ported to work with Isomyr. This is a
two-room world where a player can pick up two objects and jump on a bed.
- A new open ground example with 14 “rooms” that represent an outside
environment. This example simply shows moving between many connected and
Examining each of the Python files in the example directories is the best way
to get a sense of how to use Isomyr to create a game.
The examples may be run from the top-level source directory, for example:
$ python examples/TwoRooms/tworooms.py
You may navigate the player with the arrow keys, <SPACE> for jump, and <ENTER>
- When increasing the player velocity, their jumping height also increases.
When it’s high enough, the player can jump out of the scene. This may require
that ceilings be placed on rooms… but the jumping physics should be
examined as well.
- Add a wrapper for managing sprites (related postion vectors, sizing, etc.;
see code in isometric.py.
- Add support for ConfigParser engine/game configuration.
- Add a sandbox example for drawing just a wall.
- Add logging for all actions (for easy debugging in the console).
- Provide a configuration mechanism whereby game developers can define a
- Locate all XXX comments, fix them, and remove them.
- Rename all some_thing methods and variables to someThing.
- Examinable object.
- Explodable objects
- Procedurally-generated background images/grids/etc.
- A “room” with multiple terrain types, walking over them demostrates the
fractional player velocities as determined by the terrain.
- A time demo where time passes differently in different rooms (doors would be
teleports to other worlds with different calendars).
- Update USAGE with into about tutorial (and move the tutorial section out of
- Update USAGE with interactive prompt example.
- Update USAGE with info about unit tests.
- Update the docs with information about the perspective ratio used by Isomyr.
- Add unit tests.
- Move FAQ out of README and into docs.
- Split out getImage into separate methods.
- Give a method name for every direction.
- For the new Thing objects, make sure that if an object with children is added
to a world, that all the children get their world attribute set properly.
- Add support for parsing an ASCII map to generate a room.
- When a player picks up an item, that should re-parent the item (new parent =
- When a player drops an itme, that should re-parent the item (new parent =
- Changes to scenes, players, etc., should cause a refresh to happen in the
scene. The engine shouldn’t have to check for individual object changes.
- add an object history-tracking mechanism
- Player sensation occurs in the engine right now… this is not a good
abstraction. Player examination should be an interaction between player and
object, within the context of the world (or more practically, within the
context of a given scene).
- Engine.start refers to pygame.time.get_ticks – let’s put a wrapper for this
in our own gametime instance.
- World-relative time belongs in worlds, but gametime belongs in the engine –
move it back there.
- Add a panel for textual data from the world (reading descriptions, talking to
NPCs, naration, etc.)
- need to examine the regular view and the info panel, with the idea in mind
that a game GUI is developing here… need to consider how to make this
extensible and usable as future feature will impact the layout
- probably need to pull view out of engine module and put it somewhere
- create a new gui subpackage with view.py, title.py, inventory.py,
- or just a gui/layout.py module for now?
- Provide default skinning for objects that don’t have skins. Maybe just lots
of grey with grids on them (spaced to whatever the base unit is for objects).
- Define the mathematical relationship between the following:
- player character size and scene boundaries
- background size/placement and scene boundaries
- Allow the perspective ratio to be configurable. (prototype in the sandbox)
- Write a floor/grid-generating utility function. (prototype in the sandbox)
- Allow grid elements to be controlled run-time (e.g., changing tile colors
Multiple Skin Supprt
- Add support for objects to have differnt skins that would be switched based
upon environmental factors (e.g., broken windows, limping players, sitting
- Module organization:
- universe needs to become a subpackage
- universe/world.py, universe/weather.py, universe/universe.py,
universe/time.py, universe/sky.py (moon, meteors, comets, stars)
- add local in-game time tracking on world instance
- create configurable calendar object
- each world should be instantiated with a calendar, with the option to pass
- worlds need to define degree of axial tilt, length of day, length of year
- scenes need to indicate location on globe so that daylight hours can be
determined; they also need to indicate starting season (time of year)
and starting time of day
- type of atmosphere
- distance of the sun from the planet
- worlds need to define an average global temperature
- based on this, highs and lows need to be calculated for various latitudes
- similarly for the seasons, with axial tilt taken into consideration
- weather conditions should be predefined based on latititude, season, global
temperature, axial tilt, etc., (as well as allowable transitions from one
type of weather to another)
- type of sun, color of light
- configurable moon count
- mass/visibility of moons
- light level given off by each moon
- regularity of visible meteor activity
- Movement on world surface
- worlds need to define mass so that gravity, rate of fall, weights of
objects, etc., can be calculated
- objects also need to indicate their masses
- visually, movement could take place in outdoor and indoor scenes, but could
also take place at a top-down map-level, allowing for an interactive and
visual means of traversing great distances
- Add support for fractional velocities.
- it seems that this won’t be possible with the current isometric transform,
as it uses bit-shifting.
- Add gravity multiplier for rate of fall (this goes on world instances).
- this affects velocity of fall as well as traversal speeds across the
- this affects weight of objects.
- Add terrain traversal modifiers (that augment player velocity)… e.g.,
pavement, sand, mud, water.
- Allow players to pull objects.
- Pushing and pulling objects should affect player velocity (depending upon the
weight of the object and the surface over which they are being pushed or
pulled). This is going to require fractional velocity values.
- The idea of having weather simulation sparked another idea: events registered
for various world or scene changes. For instance, a farmer NPC could
subscribe to weather. Weather transitions could call
notify(WeatherChange(last, current), and if the transition is defined as
harmful to crops (mist->rain is cool, drought->downpour is bad, anything to
hail is bad, etc.) then the farmer NPCs could emote dramatically, rush about,
leave taverns in a hurry, etc.
- Support multiple servers for load-balancing purposes.
- Use RabbitMQ for message exchange.
- Use txAMQP for client code.
Isotope 1.0 to Isomyr 0.1
- Refactored in-game object classes for improved abstraction.
- Added abstraction for universe and world object and refactored relationship
between world and scenes.
- Added an event/handler system (based on the Zope 3 event system) for
abstracting interactions between objects and their environment.
- Replaced slow vector math with Numpy vector math.
- Refactored GUI code into its own module.
Isotope 0.9 to 1.0
- Cleaned up code according to Twisted coding standard (augmented PEP-8
compliance); removed unused and redundant code.
- Refactored skinning code to improve the game-creation workflow.
- Added abstraction for world object and refactored game component
relationships (e.g., player to environment).
- Improved object velocity implementation.
- Started adding unit tests.
- Added an “open ground” example game.
TODO: Brief introduction on what you do with files - including link to relevant help section.