Isomyr 0.1

Development

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 following:

$ bzr branch lp:isomyr
$ cd isomyr
$ sudo python setup.py install

Easy Install

You can use the setuptools easy_install script to get txSpore on your system:

$ sudo easy_install Isomyr

Manual Download

You can manually download the source tarball from the Python Package Index by visiting the following URL:

http://pypi.python.org/pypi/Isomyr/

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:

$ ./admin/testDocs.py
$ ./admin/testRunner.py

That will run the test suite and report on the success and failure of any unit tests.

Misc

• 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 titlebar image.

• Locate all XXX comments, fix them, and remove them.

• Rename all some_thing methods and variables to someThing.

New Examples

• 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).

Docs

• Update USAGE with into about tutorial (and move the tutorial section out of the README).

• 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.

DirectedAnimatedSkin

• Split out getImage into separate methods.

• Give a method name for every direction.

World Building

• 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.

Player Tweaks

• When a player picks up an item, that should re-parent the item (new parent = player).

• When a player drops an itme, that should re-parent the item (new parent = scene).

• 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 Improvements

• 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 else, maybe:

  • create a new gui subpackage with view.py, title.py, inventory.py, textarea.py modules?

  • 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 dynamically).

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 players).

Physics

• 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)

• Time

  • 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 an instance

  • 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

• Weather

• 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)

• Planetary bodies

• 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 surface

  • 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.

Complex Interactions

• 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.

Networking Support

• 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.

Isotope prior to 1.0

• Unknown.