Engine

__INDEX__

Programmer's Quest Engine
This is a tile based engine, using the Cocos2D game API on top of Python. If we choose to use some of the more advanced transistions, some work on the upstream API may be required to use GLES functions as opposed to the older APIs.

Title Screen / Main Menu

 * 1) Fade in/out Logos ( Cocos2D, Raspi? (ask about this))
 * 2) Fade in title (maybe just fade in the whole main menu)
 * 3) Slide Main Menu in bottem?

Credits
The text layout for the credits (and used for spash screens) is in a format that I can only call "HTML Inspired." The cocos crew are pulling it in from pyglet. They call it HTML, but it really isn't. It's a subset, and I found out the hard way that some times it doesn't like what should be valid tag from the limited tagset (lost a couple of hours sorting that out). If you have problems with it,

It's working for now, but long-term it may not be worth the trouble. Might try out the pyglet's RichText (which it probibly not the same as a .RTF).
 * 1) make sure you are extra-careful with font tags.
 * 2) the size field is not a point-size, it's an arbitrary index to a list of point values. It goes from 1 to 7.
 * 3) Default is left aligned, you can use center tags to center align. I do not see a way to right align.
 * 4) If you are doing actions against it, and you get errors about "NoneType" not being subscriptable, it's the parser

World Map
Tile based engine.
 * Should support hot-spots to take you to another map.
 * Should support hot-spots to take cause actions.
 * Should have a per-tile value to indicate what random incounters are permitted when entering that space.
 * For buildings/caves/etc, do we do


 * 1) scripted covering-uncoverings?
 * 2) scripted teleports?
 * 3) A map for each building Exessive.

Map Editor?
A map editor would be useful for the design work. we may even find it a requirement.

Battle Engine?
There has been some debate on if we want fights but, while this concept may be in the "edutainment" catagory, I (Oninoshiko) want it to feel more like a game then educational software. These games always felt "hokey" to me in the late 80s early 90s. I don't think that hokeyness is a forgone conclusion, but I'm also not sure violence is required to avoid it.

Current idea for battle engine:

1. User creates combat code in cities. It will be a full (but basic) program in program language to be determined.

2. First time used code is sent to txt file and compiled via external compiler (will be listed as a dependency when program is installed) to check syntax only

3a. If code is bad, error message is stored for user to view back in city and technique (program) does not execute. Random bad thing happens to person using the technique (ranging from funny explodes in face and darkens face to HP loss or status affects)

3b. If code's syntax is good the technique (program) is "run", an internal flag associate with code is marked true and code doesn't go to syntax check again unless it is modified

4. The "Execution" of the code is really done by grabbing approved power words (while, for, if/then) and approved command words (attack, defend, use) out of the code and running those commands

The implicaiton of this final point is that we'll have an interpreter level for the power words. Since every language is a little different in how the implament the same concept, the interpreter level will take the instructions in the program language of your choice and translate that to the underlying code of the game engine. I'm thinking that the scope of the game will be limited to 1st semester programming so this should be a fairly simple deal to swap out the modules for different programming languages, but one thing at a time.

Licenseing
TBD. I would lean toward Dual Licensed GPLv3/CDDL (or something similar). I (Oninoshiko) like code I release to be useable with other peoples code, even it their code is not open, but still require you to share my code if you distribute it.

Thoughts?