View RSS Feed

The Mad Wizard

Traipse – Code Structure [Part 2]

Rate this Entry
This is a repost of a blog post found here:

This next part of the blog post centers around some variable names for objects that I want to make common place in the code. In the last post I showed how names like ‘widget’ and ‘layout’ are designed to be common, but there are a few other names that I wanted to list. I’ll start with the previous so the list is more complete.

Common Names
  • widget – Common name for a returnable widget
  • layout – Common name for a returnable layout
  • menu – Common name for a returnable menu
  • treeType – Due to the multiple Game Trees running, this variable name holds the type of tree being created
  • treeWidget – This name refers to any widget found in a Game Tree instance
  • nodeData – This is the Element Tree instance of a node.
  • xmlData – This is a string version of a node’s XML.

This is but a small list of common names that are found throughout the code and, if not yet, will be commonplace. They should become easily recognizable so the developer knows what type of data they are dealing with. Eventually the whole software will come with a nice formula and an entire naming convention .. for now these are the ones that are common.

Folder and File Names

Developers may have noticed a major change in the naming of the files and folders. Even if the naming is disliked I am sure a developer will appreciate the reasoning behind the change. First we have the CoreEngine. This file is where the entire software is derived from. All major components are found here. Inside the CoreEngine folder we have some other folders, a few ending with _engine.

Each of these folders ending with _engine is a major component of the software. Inside these folders we find files ending with _dock or _gear. The three endings have significance. The major component is created from gears and docks. Gears are the core computations. They are the heart of OpenRPG and most of the code in here has only seen renaming and cleaning up. Docks are the UIs and import the _gear to create the working _engine. It’s quite simple and elegant.

Files ending with _gear don’t actually depend on the UI. They do provide callback methods so they can communicate with the UI, but those portions can be re-written. This design increases portability, and with continued development and some Mercurial branching it will be possible to host the same software written for multiple devices.

Submit "Traipse – Code Structure [Part 2]" to Digg Submit "Traipse – Code Structure [Part 2]" to Submit "Traipse – Code Structure [Part 2]" to StumbleUpon Submit "Traipse – Code Structure [Part 2]" to Google

Tags: traipse Add / Edit Tags