Technical framework

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

This article explains the agreed upon technical framework behind the project. Furthermore it wants to provide rationale concerning the decisions and proposals.


Supported platforms

  • Most Linux distributions;
  • Windows OS;
  • Macintosh/OS X & FreeBSD;

Programming language

Python 2.6x and 2.7x.

Rationale for Python (General)

  • Easy to learn;
  • Clean syntax;
    • An old buddy of mine who is a pro C/C++ game coder had this to say about Python: At first, the whitespace rules are totally irritating. But then your realize it just forces you to write code that can be read; (zenbitz)
  • Large standard library and good third party library support;
  • Easy and fast prototyping of concepts;
  • No need to deal with low-level memory management thanks to Python's garbage collector;
  • Easily integrated with C/C++ code;
    • Time-critical code can be still moved to engine side (C++);
  • Native support in FIFE via SWIG;

Rationale Against Python 3.x

  • Third party library support for Python 3.x is still lacking as Py3k is incompatible with older Python releases;
    • We can always consider to switch to Python 3k once third party library support has improved;



FIFE - open source isometric 2d game engine.

Rationale for FIFE

  • Cross platform support for Linux and Windows with unofficial support for FreeBSD & Macintosh;
  • Very few isometric engines with Python bindings seem to exist at all;
    • Offers more needed features than comparable isometric game engines e.g. Kyra;
    • The only alternative to create an own engine for PARPG seems to be GemRB. Although it appears to be more feature-complete than FIFE, it seems more geared towards the Infinity Engine games and less flexible than FIFE;

Working with FIFE

  • The key priority of the project is to create a post-apocalyptic RPG, not to continue active FIFE development.
  • Therefore we should consider what the best option for PARPG is (main priority) and if FIFE could benefit from it as well (secondary priority).
  • The majority of the needed functionality for PARPG can hopefully be implemented in Python so we we wouldn't need to modify FIFE for these purposes.
  • PARPG will use FIFE's OpenGL rendering backend and features will be geared towards it; FIFE's SDL software renderer is not meant to be used as a real alternative to the hardware accelerated OpenGL renderer for PARPG.
  • In case we'll need to implement time-critical functionality in C++, we got the following options:
    • Build the relevant code as dynamic library to import it into Python (the way FIFE bindings are working).
    • Send in patches for FIFE and wait until they get applied to the FIFE trunk.
    • Fork the FIFE code and maintain our own modified FIFE source repository.
    • We could also use a combination of these different approaches. E.g. maintain our modified FIFE repository but sending in patches so that our modified code and the official FIFE trunk won't become two totally different, incompatible engines in the long run.
  • PARPG will be a FIFE-based game among others like OpenAnno & Zero-Projekt.
  • Stay in contact with the FIFE development team as well as with the developers of FIFE-based games to share experience.

FIFE documentation

Personal tools