|
|
@@ -0,0 +1,254 @@
|
|
|
+
|
|
|
+= 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.
|
