
= ERUTA PLAN =
 
== General ==

Eruta will be a 2D or 2.5D game. 
  Rationale: I like the old-school 2D look. 3D games are more resource hungry 
  and time-consuming to implement, so that's for the next project.

Programmed in C with mruby scripting:
  Rationale: I love Ruby, but no matter how easy normal Ruby is to use, 
  I ended up writing a lot of C anyway to support it. For gaming, speed is
  essential since a slow game is hard to enjoy, especially for an action game.
  So I decided to rather than use ruby extended with C, to use C
  extended with a scripting language.
  At first the choice of scripting languages was on Lua, but the mruby idea 
  and open source development on github came through, and I switched to mruby 
  since it does give me the sweet, easy Ruby syntax for the scripts. :)
  And no, don't even dare mention C++, it complicates matters without being 
  actually that helpful. And too bad that Objective C is not well supported on 
  Windows and messy on Linux.

Using Allegro 5.x.
  Rationale: SDL may be the de facto standard for open source games, but it's
  very poor in functionality. So I ended up having to write a lot of
  functionality myself. And SDL 2.0 is not as mature as allegro 5 is. I thought
  Allegro 5 was slower, but when  using plain C, and taking care to
  load the images after opening the screen, Allegro 5 was actually plenty
  fast enough. Allegro has so much nice functionality built in, it would be a
  waste not to use it when using plain C.

Virtual screen resolution exactly 640x480. Color depth minimum 16bpp or better. 
  Also implement scaling to other resolutions trough OpenGL or 2xSai, etc 
  to achieve resolution dependence later.
  Rationale: Old-style feeling and limit art requrements.

Hand drawn art with colors limited to a 12/15 bits palette. 
  I like bright colors that have a simple rgb expression and generated
  a palette that fits the limitations for drawing the hand drawn art.
  Rationale: Old-style feeling.

A role playing game with much onus on the story.
  Rationale: I want Eruta to be to RPG's what Katawa Shoujo is to Visual Novels.

Multi player game:
  Rationale: I want to be able to play together with someone on the same PC. 
  To begin just 2 players together is OK. Perhaps implement 
  split screen. 2 to 4 players are probably OK to divide the screen between. The 
  maximum should be the amount of 12 characters, but it will be hard to fit all 
  those on one screen. So perhaps allow networked play as well.
  
  
Full Action RPG or Chrono Trigger style menu-driven tactical or more FF12 style RPG?
  I'm still unsure actually! Oh my! FF6 shows that a menu driven game can be
  played by several players. Each player simply controls one character during 
  battles. And since all characters will always be visible and on the screen,
  the idea would be to allow controlling them even outside of battle. 
  They can talk and get small side-dialogs. They can search and help solve puzzles.
  Only the player who controls the main character will be able to make plot
  determining decisions, and control of secondary characters will be disabled in 
  camp.
  Even if I decide that the battles should be menu based, the players will be able 
  to use various forceful actions outside of combat as well.
  Ponderings about the 3 different options: action, tactical and hybrid. Strategic
  is not under consideration since I don't like strategic RPG's too much due to 
  too slow and too battle-oriented.
  Action RPG: 
  + Easy to get in to. 
  + Action based battles normally are the most "fun" at least to me.
  - May be difficult to control 12 or 6 characters all at once.
  - Action based battles lack depth in RPG's since you'd need the controls 
    of a fighting game to make the moves complex. That would work, but make the game
    less accessible again. I don't like to have to button mash or memorize button
    combinations.
  +- AI implementation is somewhat more complex. 
  Tactical RPG: (Classic menu driven)
  + If done correctly, and with some enhancements, can be deeper than action RPG.
  + For some players, and for me too the menu-based approach is more relaxed.
    The game becomes more like a tactical puzzle.
  - If done 100% classic style, the battles can devolve into boring bouts 
    of doing nothing but selecting "fight/fight/fight..." (or X X X, FFXIII :p) 
    over and over. More creativity and challenge even in normal battles is needed.
  - Could be harder to get in to.
  Hybrid (FF12/MMORPG style):
  + Can be as deep as tactical. 
  + Easier to implement networked and multiplayer.
  - Isn't as relaxing to play as pure menu driven.
 -+ Game engine is somewhat more complex than tactical and probably even more 
    than action based alone.
=> Conclusion: I want this game to be more "SOM"-like with a "PS4"-like 
atmosphere, so Action RPG it is. Let's see how deep that rabbit hole goes. :)
My next RPG project will be a more "PERS4" inspired 3D menu driven RPG.

  
  
== Needed Functionality ==

The Eruta game engine will need the following general functionality: 

Tile map 
Sprites
Physics, collision detection and resolution
Particle engine for effects
Camera module
Resource loading
UI Subsystem
Input mapping (to commands/events)
Music handling
Sound handling
Scripting of maps and events.
Game system: stats, skills, techniques, battle resolution, etc, etc.


=== Tile Map Requirements ===

Tile map with tiles of 32x32 pixels. Before, 40x40 or 64x64 were considered, but
these are too large and make the art requirements too high. Also, 32x32 is easy 
to accelerate with OpenGL later, and fits the resolution of 640x480 well.

Tile map distinguishes between tile layers wich dictate rendering and world
layers which dictate gameplay (ie, on which levels the sprites can “be”).
Tile map has 4 drawing layers of tiles. Testing shows 4 is optimal for speed.
Layers are usually grouped in pairs for the “world layers”. Layer 1 is the first
floor, layer 2 is anything that stands on that floor and any fringes/overlaps
from one kind of floor to another. Layers 1 and 2 are always under all sprites.
Layer 3 and 4 are normally the “floor above” the player, however, the player may
walk there in case of bridges, overlays, or parallax.

Every layer may have a background image that is drawn before the tiles of the layer 
are drawn. the tiles can also be made invisible if the background layer by itself is 
enough visually. In that case the tiles influence the game play and physics only. 
Although only one bitmap background can be displayed per layer, it's possible for 
a layer to change the background depending on what's needed. 
(night/day/scripting/etc). The background bitmap width and 
height must have a size that is an integer multiple of 32 pixels.

There will be options for parallax scrolling of the background bitmap versus the 
tiles in a layer, or, for paralax between the layers in total. Scrolling
can be locked or unlocked in x and y directions though scripts or by using
special "scroll lock" tiles.

View culling will be possible, in that, if enabled, only the direct area around the 
player sprite will be shown, and anything outside a rectangle set by special 
culling tiles will not be drawn. This to allow inside areas to be stored more 
compactly.

Every map layer uses exactly one tile set based on a single tile image. Tile images 
are are files in .png format with a width and height that are integer multiples of
32, and that contain many individual tiles.

Keeping with convention over configuration, the tile sets are read in, split up
in 32x32 tiles and interpreted according to the following rules:

Every map describes the names of the tile it uses. The file name of the 
set is of the form set_name_xxx000.png where xxx000 is a number with at least 4 
digits that signifies the start index of the set. Tiles in a set are numbered 
from left to right and from top to bottom, starting from 0. So, for instance  
the second tile at  the top left of a tile set will be numbered 1.

The idea of this is for maps broadly compatible with each other even if 
they use different tile sets, and also to make it easy to swap tile sets if 
needed.

The map engine loads tiled .tmx map files. The properties of a tile, such as 
solidity or animation are loaded from the Tiled file. Tiled has animated tiles 
since tiled 0.10 so support those as well.


Particle and effect engine
--------------------------

This module can display effects like rain, snow, blood, bursts. Explosions and spell 
effects would be nice as well. Will use the camera for correct views. 
allow bitmaps as well as drawing for the particles. Need to allow bitmap
animations for certain effects.  


Camera module
-------------
The camera module should model a camera, that is, a view of a
rectangular area that can move in the “world” of the game and translate these
world coordinates to screen coordinates. 


Physics
-------
Finally got rid of Chipmunk. I was able to implement a useful system 
that's simpler than chipmunk but that works well and doesn't require bazillions
of static shapes for the tile map walls. Also need to implement battle related 
area sensitivity.

+---------+
| Modules |
+---------+

According to the requirements, the following modules will be needed, each
in one C file (although smaller modules may be joined tohgether into one c
file if appropriate)

camera.c  : Camera, active view of current area.
bevec.c   : 2D vectors and points.
bump.c    : Physics and collision detection.
dynar.c   : Dynamic arrays.
alps.c    : Graphical effects using particle engine and likewise.
every.c   : Iterator for dunamic arrays, etc.
toruby.c  : Functions that will be used in the ruby scripts
glh.c     : OpenGL helper functionality.
rh.c      : Ruby helpers.
main.c    : Main function of program.
mem.c     : Memory management and malloc wrappers.
mobile.c  : Mobile entities 
sound.c   : Sound and music helpers.
state.c   : Program state, and also, high level functionality.
tile.c    : Tile functionality.
tilemap.c : Tile map functionality.
tilepane.c: Tile Layer functionality.
sprite.c  : Sprites on the tile map.
mode.c    : Different game modes (menu, normal, ect)
menumode.c: Menu mode
playmode.c: Play mode
openmode.c: Opening (intro) mode
confmode.c: Configuration/settings mode.
editmode.c: Edit mode for built in editor.
goal.c    : Goal of motion of mobile or camera.
player.c  : Player control and data.
ncp.c     : Npc control and data.
foe.c     : Foe control and data.
switch.c  : Switches.
treasure.c: Treasures.
door.c    : Doors.
obstacle.c: Obstacles, pushblocks, etc.
route.c   : Path finding and planning.
item.c    : Items player can have.
gear.c    : Equippable items.
useable.c : Useable items.
being.c   : Logical and play-related information about beings.
inmap.c   : Input mapping (links input to in-game action).
ai.c      : AI for npc's and foes.
saveload.c: Saving and loading state.
initfile.c: Loading and saving settings.
react.c   : Map events and NPC/Item/Foe reactions.
world.c   : World state.
ui.c      : UI.
widget.c  : UI widget.
wimenu.c  : UI menu widget.    
wibox.c   : UI text box widget (more widgets needed).

(Probably more...)

Maybe     : 
intmap.c  : Maps game objects to integers and vice versa for easy lua wrapping?

47 modules/c files -> upper estimate 80 modules.
80 * 1000lines per file (upper limit) = 80kloc.
