- Iso Realms Engine
- Spindizzy Dimensions
- Stunt Bike Coaster
- Virtual Reality UI
- Slide Puzzle Panic
- Land Transport Simulator
- Tsunami Puzzle Solver



- Blood Maps
- Music
- Other Work



- Home
- About / Contact

Iso Realms Version 2.0 - Features Brainstorm

This page documents features to be considered for implementation within the Iso Realms after version 1.0 has been completed and released. These features are currently proposals; the final feature set of Iso Realms version 2.0 has yet to be decided.

Phase Out of Zones

In Isorealms Engine 1.0, zones serve two distinctive purposes:

1: Performance Optimisation. Modules relating to collision detection and surface calculation use zones in their optimisation techniques. By eleminating elements of distant zones from consideration when performing these actions, the game can run much more efficiently.

2: Functionality. In Spindizzy, zones have many functional purposes, such as determining block colour schemes, activating, deactivating and resetting the lifts and enemies, as well as serving as the primary game objective, which is to explore every zone.

When zones are phased out from the engine, collision detection and surface calculation modules will be required to group their objects into appropriate data structures for optimisation. It may be possible to implement some generic data structure classes or templates that can be reused by different modules for this purpose.

From a Spindizzy point of view, the zones will obviously still be required for their functional effects. The existing Zone class will be ported to a module and will be represented as an Element Group that contains the Elements of the zone, as well as necessary attributes such as the zone theming.

As an example of the implications of this, the player craft will no longer intrinsicly know anything about a zone, so it will be necessary to determine zone entrance and exit events using a different mechanism. One possibility may be to use the existing collision detection module to also register zones. Instead of "bouncing" the player as a normal floor or wall would, the properties of the zone "surfaces" would be set to not affect the player physically, but instead just trigger the entrance/exit scripts.

The motivation behind this is to remove the burden on the creator to manually add optimisation elements to a project. This system works well for Spindizzy because Spindizzy requires the zones anyway, so the optimisation becomes incidental. However, in a hypothetical remake of Spindizzy's sequel Spindizzy Worlds, where each map constitutes a single massive zone, such manually optimisation via zoning would become very cumbersome.

Enhanced Graphical Capabilities

Lighting should be considered a high priority. Shadows would also definitely be nice to have, as would particle effects. Other visual features such as shiny surfaces, etc. to be considered as required and as time constraints permit. These changes would require modification to the engine rendering process.

Arbitrary Positioning, Rotation and Sizing of Objects

Isorealms Engine 1.0 is limited to tile-based placement of objects. It should be possible in Isorealms Engine 2.0 to place objects anywhere, not directly aligned to integer spatial values. It should also be possible to rotate objects to any angle. For example, to have a wall at 37.4 degrees. Although it is not necessary to allow existing Spindizzy element types to use this feature, it would be nice to have some new element types that allow it, making Iso Realms a more general purpose development tool.

It would make sense at least to have GERALD and Enemies support this, since these element types are not confined to the grid during gameplay anyway.

Improvements to the Surface Processing and Collision Detection Modules

This ties directly to the previous feature. With the ability to place surfaces in an arbitrary manner comes the need to process surfaces that are placed in such a manner. The current distinction between floor and wall surfaces in collision detection should be removed. Instead, an entity should be responsible for determining which surfaces act as floors and walls based on their own capabilities (e.g. a vertical surface is a wall as far as GERALD is concerned, but a spider could treat this surface as a floor).

Backwards Compatibility for Isorealms Engine 1.0 projects

It should be possible to run Isorealms Engine 1.0 in version 2.0. For example, since Isorealms Engine 2.0 will have no intrinsic concept of a zone, the parser should be capable of instantiating the new Zone module automatically and instantiating instances of the zone when encountering the deprecated "Zone" XML tag (the new format will use the "Element" tag with a "type" attribute specified the zone element type to define a zone instance. Other possible changes to the XML format will need to be accounted for.








Avalon One - Copyright 2001-2013 Martin Brentnall