Lycadican CRPG

Design Specifications

  • 2D Isometric, diablo style.
  • Full Screen.
  • Min resolution, 800x600 funning full screen at min 256 color, standard should be 16bit.
Atmosphere:dark and sinister or Normal (Ultima Online look)
  • Imlib
  • Gtk+
  • Multiplayer
  • Plugable modules (world modules)
  • Independent game engine
  • C++, Java for networking and multiplayer.

Make a game engine completely open, without any traces of a story in it, and make it use different modules (I'll call the 'world modules') in which the map, story, etc. will be included.

This way, it will be in every sense like a traditional RPG (Fiddler on the roof again :) ): the game engine would be like the game itself, the world modules would act as the campaigns, and every person willing to create a new world module would be like a Dungeon Master. A game like this would be absolutely open and expandable without limits.

We could also make it networkable, so that different characters could play in the same world and collaborate (or fight) if they want to, but you could also load a module and play it all alone if that's what you want.

Finally, everybody on the Internet could write their own world modules. This would make it an incredible game, always growing. We have configuration file that defines the modules that are currently installed.

We have configuration file that defines the modules that are currently installed.

The init code would go through this list, and add a module object to a stack one by one. The module objects would be derived from a pure abstract class that defines functions that must be present, like Init, PlaceCreatures(x,y, possibly z and t), PlaceTreasure, IncrementTimeIndex, etc..

Whenever something needs to be done:

for (i=0; i< StackObject.length(); i++)

If a module doesn't have anything to do at the specific time (if this is a forward going story, some elements may not be available until a certain time has past, like a war or something), or at the specific location, it will pretty much immediately return.

Possibly another module object method, SizeLoc <or whatever we want to call it>, that returns not only the location of the module (if it is a new island or something), but the size. That way the main code can use this to determine the minimum size of the map that has to be generated/tracked, and still encompass all of the modules.

Character Class

ReadWriteResourceLoader extends ReadOnlyResourceLoader

ResourceLoader implements ReadOnlyResourceLoader, 

ImageResourceLoader extends ResourceLoader Dialog Sound Map Character data, Critter Item data Saved games (however we want to tackle that) User settings Magike info Game tables for combat/character creation. and, Character/NPC dialog.


  • data
    • magnitude
    • target (what modifies)
    • scope (when active)
    • source (where it comes from)
  • methods/functions
    • boolean checkScope() // does this modifier apply here
    • getScope() // get the situation that the modifier applies in
    • getSource() // get where the modifer comes from
    • getTarget() // get what the modifier applies to
    • getMagnitude() // get the magnintude of the modifier +- X
    • setMagnitude() // you can figure these out
    • setScope()

In regards to modifiers we need to know what is being modified for each character, what the original value is and how much it is being modified by.

Each character will have a collection of modifier objects. One object per modifier.

There are a few ways we could get a characters current state with all modifiers applied:

We could have a master modifier object (more of a caching function of the engine) that totals all of the modifiers for each target (statistic) that a character has. It would have the same functions with the exception of getScope (as it would be global) It would need to know when any of the modifiers below it changed. Thus it would need a registry of all modifier objects
We could just iterate through all of the modifers adding them up.
Each stat. that may have modifiers would have a collection of modifier objects therefore eliminating the need to find the target. The problem is finding the scope and the fact that you can be in multiple scopes at any time.

Breakdown of needed character data:

Here is the character data that I could think of off the top of my head, The character class needs to be event driven, especially for modifiers. We need to track:

  • modifier objects for every modifier a character has.
  • skills
  • weapon abilities
  • abilities
  • powers

and the initial cost of each. and level of each. and if they go up levels or are static.

  • racial attributes and modifiers
  • attributes
  • healthpoint distribution
  • health die
  • defence rating (Natural)
  • base defence rating (according to level)
  • natural resistances
  • Body parts, what ones do you have
  • Flight class if applicable
  • alignment
  • tendency
  • social class
  • quirks
  • flaws
  • personality traits
  • appearance
  • handedness
  • wealth and wealth modifier
  • equiptment
  • age
  • height and weight
  • movement points
  • magike stats (a whole new ball game)
    • psychi points
    • spiritual life points
    • magikeal aspect skills
    • magikeal law skills
    • arcane art skills
      • need to cache
      • thresholds
      • spells
    • volatile percentage.
  • character development points
  • resistances
  • experience points cumulative
  • soul strength
  • life points
  • location of character Waato' si
  • diseases, curses and conditions( conditions overall and per body area)

We also need lookup tables on the games static tables.

Join Lycadican Developers