Design Document V2
From Hero of Allacrost
Because I’m writing the document a lot of changes or different ideas slip in, to make certain that this is the general idea of everyone I have added a list here with things that are different. If you have an idea that is different, please say so and I will add it here.
- The term “modules” is unclear
- Running is no longer a flag that is set with a map, but a check if there are monsters on the map.
- Different sprite definition and sprite loading algorithm, it should make it easier to assign definitions.
- Gave map a unload function, this can be useful for fading and fading out
- I need to add a bit more to contexts to make it a bit clearer
- Added regions (trigger areas)
- Passable layer added, It’s unwise to let that be decided by the tiles themselves and it becomes a whole lot clearer when you can view it as a separate layer (this is in the engine, the editor might be different)
- Added object behavior
- Added subtle object behavior
- Added an list of triggers
- Added pathfinding
- Added a section about scripts and triggers
- Decided the game has four save games
If you have an idea for the game design document, please use the Design Idea List and add it there. We will then be able to discuss the idea and work it out further. Keep in mind that your idea(s) might not be accepted, if that happens and you disagree with the reason given try to approach some of the staff (through forum or IRC) and explain why we made the wrong call. However please do not edit this document to add a new idea without discussing it up front.
Goals of the Project
Hero of Allacrost (here after HoA) is an open-source RPG. For this we need two things: a game engine and a game editor. We plan to release the game in several instances, which we call “modules”. Although the game engine and game editor can be used to create other games we won’t support those as our primary goal is to make an RPG and not a game engine and game editor.
About this document
Goal of this document
The document is written by ElonNarai (Wouter Lindenhof) as an attempt to collect all the written and unwritten design information of the game at one place (this document). If you see something that is unclear or lacking please post it on the forum and contact me through a PM or otherwise. If I have left the project find out who has taken responsibility of this document and get the latest document as this one is most likely outdated. Also note that you won’t find in this document how to code and what is done. This document is about how the game should work and look like after it is done.
In the end the following should be archieved with this document:
- A single document that includes all gameplay behaviour
- A final design of the document with exception to story, technical and artistic decisions and design.
How the document is Setup
This document consist out of various parts.
- Logical section, how something works
- Artistic section, how something looks and sounds like
Although this means you might find your self jumping often between the various sections it should allow you to find the right information in the right section. At the end of this document you also find a technical section which describes what data formats are supported and how they are implemented in the game.
Basic information about modules
Before we start explain the game, the reader (reader, not user or player) should be made aware that the entire game is build up of various modules. Each module can be compared to chapter of the game. Throughout this document various references will be made to modules.
When the game starts an intro screen will be displayed. It shows the title of the game (“Hero Of Allacrost”) with an animation. This entire animation can be skipped by pressing a key.
First time welcome
It will tell the user the minimal information to navigate through the main menu. The player will have the option to disable this message for the future but the default selected option is to show it at the next run of the engine.
This is the top menu of the game. It is the first thing shown after starting the game (and after the welcome and intro screen). within the main menu the player has the following options:
- Start a new game
- Load a game
- Adjust game engine options
- View the credits of the people who worked on the Allacrost game engine
- And quit the game
Screenshot from windows
This will start a new game. New games will always start at the beginning of the first module.
The game engine will display a list of save games. Selecting one will load the game with the data stored when the game was saved. Before a save game is loaded and check will be executed to see the module is available. This is needed since the loaded game is the result of the last save of a module.
The option button in the main menu will display the options menu. These options can be changed real time and should not require the user to restart the game. If an option would require the user to restart it will display a message telling the user that it needs to restart which includes the reason why the user as to reboot. The settings will be stored as soon as the user has changed them and closed that menu.
The video option has the following options that can be altered:
- Change resolution
- 1024x768 (default)
- Windowed mode or full screen (default: full screen)
- Image quality (default: best option)
The audio option menu has the following options that can be altered:
- Sound volume, a slider that ranges from 0% to 100% incrementing with 10%, adjusting this will change the volume of the sound in general.
- Music volume, a slider that ranges from 0% to 100% incrementing with 10%, adjusting this will only affect the volume of the music. It will also be modified by “sound volume”
The language menu will pop a list of languages in which the current module can be played. By default it will select the one that is recommended by the module.
The following actions can have keys assigned:
- Move Up (default: key up)
- Move Down (default: key down)
- Move Left (default: key left)
- Move Right (default: key right)
- Confirm (default: “f”)
- Cancel (default: “d”)
- Menu (default: “s”)
- Swap (default: “a”)
- Left select (default: “w”)
- Right select (default: “e”)
- Pause (default: key spacebar)
Further it will have an option to restore all keys to default. To change a key the user must select it a key and press confirm after which the engine asks for a new key. If the new key is already assigned to an action the action will swap keys, else they will be assigned. The “escape key” is reserved and can not be assigned. It will cancel the input dialog. The reason for this since it is used to quit the game from any point. (See: user input)
TODO: Currently there is no way of changing the joysticks, I will add this at a later day when I can review the joystick settings.
This will display the list of people who have worked on the engine.
After the user has confirmed that he wants to quit the game the game engine will shut down.
The game has various functions. All of them are described here.
The world is a collection of maps over which the player can move and interact. However this section will only be about the action that can be performed on the individual maps. Further it will cover how maps and various systems like combat are related.
On the map the following actions can be performed:
- Moving, the user can move the player around using the movement keys. However the map can restrict the movement of the player. Further movement can cause the “Map transition”.
- Interact, this means that the player will perform an action in the direction it is facing. For example: talking, opening, searching. It is triggered by pressing the “confirm” button. Often there is nothing to interact with and it depends on the object that is interacted with what the result is. If there is nothing to interact with nothing will happen.
- Running, the player can run by pressing and holding the “cancel” button.
Further there are triggers that can be activated depending on what the player does.
An object (the player is also an object) can change position two ways:
- moving, it will move over the map.
- teleporting, the object is instantly moved to that location.
The player can also not move in that case he will be using the “standing” animation set. If the player starts walking he will use the “walking” animation. The user can instruct the player to walk over the map, but only where the player can physically move. The player can’t walk through objects or anything else that is marked as impassible. If the player can’t move in the direction that the user tells him, he is blocked (refrained from moving in that direction) and this might cause a trigger. If the object that blocks him is moving towards him or away from him the player will match his speed in the same direction unless he is moving in that direction The player can walk in to eight directions: Up, Up-right, Right, Down-right, Down, Down-left, Left, Up-left. But the player sprite will only know four directions (Up, Right, Down, Left).
- If the player walks in two non-conflicting directions (for example, up and right) than it’s sprite will face the direction he first walk (so if up is pressed before right, it will face up, if right was pressed before up, it will face right).
- If the user starts walking in to one direction again, it will switch to that direction
- If the players walks in two conflicting direction (for example: up and down) than those instructions will be ignored and it will seem as if the user isn’t pressing those keys.
The player can run, however running will cost energy. Running will switch to the “running” animation set by default. Running will happen at twice the speed.
- If the player actually runs (This is when the player does run and not if he standing still) he will use a constant amount of energy
- If there is no more running energy the player will switch back to walking (including the animation)
- Energy will refill when the following conditions have been achieved:
- The map has a free running flag
- The user is no longer instructing the player to run
- The user is no longer instructing the player to move (this means the “run” command can still be given)
This is when a player moves from one map to another map. This is done by triggers which tell the game engine to load another map. For more information about triggers see map-triggers. How the transition takes place is all up to the associated scripts of the maps.
A map consist out of various contexts. If you think of a map context you should think in terms like: “inside”, “outside”, “walking above”, etc. You can switch various map context. When a map context switches it changes the map. There is a maximum of the amount 32 layers and at least 1 has to be used. For example:
| Outside the house |
(context 1 is turned on, context 2 is turned off)
| Inside the house |
(context 1 is turned off, context 2 is turned on)
The idea is that when the player enters the house the map will slowly transforms to the other context. Contexts can also be used for:
- Multiple levels (think of an entire bridge network in which )
- Multiple floors
The advantage of contexts are:
- No need to load another map
- Executions on the map will continue (if you switch map the previous map will no longer be in memory), so if your followed by an enemy it will continue.
Disadvantage of contexts are:
- Need to specify when to turn a context active.
- The order in which the contexts are drawn can not be changed.
- Only 32 contexts are allowed (this is to keep memory requirements low)
- Objects that need to switch between contexts need manually be switched.
A context will hold layers, regions and passable area grid (where one can move).
A single map context consist out of three layers:
- Upper layer
- Middle layer
- Lower layer
- Passable layer
By default the order of drawing is:
- Draw the tiles of the lower layer
- Draw the tiles of the middle layer
- Draw the objects that lay on the floor (so called first pass of the ground objects)
- Draw the pass object layer (the walking and moving characters)
- Draw the objects that are floating (so called second pass of the ground objects)
- Draw the tiles of the upper layer
- Draw the objects that are flying (sky objects)
The passable layer is special since it defines where the player can and can not walk.
A region is an area defined on the map which is not visible to the player. This area can be of any size but to be valid is has to cover at least one tiles. Regions however are placed on a context and not on the map. Further a region will always cover a tile. Each region will have two functions:
- Is PosXY inside the region?
- Is PosXY outside the region?
Where PosXY needs to be replaced by the position of the object of interest. Further regions will hold two triggers
- AutoContextChange, when a object moves in to a region (so without teleporting) the region can have an option to teleport the object to another context. The "OnEnteringRegion" will be given AFTER the teleport is completed. This is required to keep pathfinding easy.
They will only be triggered when a object enters or leaves the region. If an object is transported (just updating the position) these triggers will no be called. Regions can be used for:
- Checking if a the player leaves a village. There will be region around the village as a border, which will send the player to the worldmap if he enters it.
- Changing contexts, we use a switch to activate a context and a second one to leave a context. One is placed in the “inside context” and the other is placed in the “outside context”. Though they share the same place they will
- Changing maps.
Advantages of region:
- Allows scripting based on position.
- Easier to switch context
Disadvantage of regions:
- Regions are limited to context in which they are (though if well used this can be seen as an advantage)
A map context can contain tracks. Objects will use this to find the shortest route to their destination. When a route is found it will be given to the object.
Since this section is riddled with terms we will list them here for review purpose:
- Track, a system of lanes that is placed on the map
- Route, a object follows a route to it's destinitation. A route is composed out of lanes from current position to destination
- Node, a node is point on the map. There are two special nodes:
- Begin node, this is the position of the object when it gets a route
- End node, this is the destination of the object when it recieves a route
- Lane, a path between two nodes
Before we explain the entire algorithm and use, we will first explain why your average A-Star search algorithm is not a good idea to implement on tile level by using an example. You see that the algorithm here looks for it's destination. It will check each tile and look how to go further. And in fact it will check more 100 tiles to find the best path. The best path is go down 9 tiles and then go right 18 tiles. This means that more than 70 tiles are not used and are unnescary to calculate. This does not mean that A-Star algorithm is bad but the implementation is wrong.
If we have a slightly more complex level and we add tracks (shown by green lines) we can use weights (the length of each lane) to calculate the shortest route from one node to another node. However the object doesn't have to move exactly over the lane (since A-star algorithm can't be used here we will take the Dijkstra algorithm) but can decide to take a short cut.
An example of a route
- The object starts between node A and node B and wants to move node F
- The Begin Node will be placed where the object is standing and it will be connected to each node it can draw a straight line too. The same is done for the end node.
- If th Begin and End node attached to different tracks the pathfinding will stop and no route will be returned.
- The object will recieve the following route. A->B->C->F (apperantly it was closer to node A than it was to B, which makes A the start node)
- The object will asses the situation by going from the destination node back to the start node
- Node F can't be seen
- Node C can't be seen
- Node B can be seen from where it is, the object will there for move to Node B
- Node A can be seen as well but the object has already decided it's next move
- The object will look at intervals each time again and before it arrives at Node B it will notice that it can already see it's destination and will move directly towards it.
- BUT before it can arrive at Node F it will notice that it's blocked.
- The following lanes can't be used in either direction:
- We will assume that it has a subtle behaviour to find an alternative route.
- The following lanes can't be used in either direction:
- the object will back up looking at it's route. The route was in reverse order F<-C<-B<-A so it will first go back to Node C and request a new route. This new route is C->J->I->H->G->F.
- The entire route now know by the object is A->B->C->J->I->H->G->F
- When it arrives at Node C it will notice that it can see node H and will check if it is possible to move to node H, except that it will notice that it is blocked as well and won't even attempt to go node H
- If node H was no longer blocked it would of course try to take a shortcut
- It will then move over J->I->H->G->F final reaching it's destination.
The route was only calculated twice, the AI it self found two shortcuts. The path is best calculated using the Dijkstra algorithm and not the A*-algorithm.
Pathfinding over multiple contexts
So the following situations can't be solved by only giving a destination:
- Going from the lower left corner of the bottom context to the upper right corner in the top context (reason: the end and begin point will be connected to a different track)
- Going from the lower lef corner of the bottom context to the lower left corner in the top context (reason: the end and begin point will be connected to different tracks)
- Going from the left side of the top context to the right side of the top context (reason: the end and begin points will be connected to different tracks)
If you have the above situation it can be easily resolved by adding a few steps. In this example we want to move from the left side of the top context to the right side of the top context. For that we will give the object the following instruction:
- Move to the left green dot (this is a region) on the top layer
- On entering the region the object it will be automatically transported to the lower context.
- When a OnEnterRegion was triggered the destination became the right green region on the bottom layer. Since there is only one path on the bottom layer this is possible.
- On entering that region the object will be moved to the upper context.
- Now the destination can become the final destination.
On a map there can be various triggers, triggers call events which are really scripts that are executed on call. An example for a script is a dialog with a character. Here is a list of triggers:
- Region Triggers, can only be assigned to regions
- OnEnterRegion, will trigger when a object enters the region (without teleporting)
- OnLeaveRegion, will trigger when a object leaves the region (without teleporting)
- Object Triggers, can only be assigned to objects
- OnInteractObject, the player faces a object and is either seperated by one unpassable tile or stands close to it and the user presses the "confirm key"
- OnTouchObject, the player touches (walks in to) an object
- OnTouchPlayer, same as OnTouchObject but then the other way around. The object now walks into the player.
- OnCollideObject, the player runs in to an object (rams the object)
- OnCollidePlayer, the objects runs in to the player (rams the player)
- OnPushObject, the player keeps moving against the object as if it tries to push it away.
- Global triggers, can’t be assigned
- OnTime, will be called with each update and will have as parameter the Delta time
Objects on the map
There can be a various amount of objects on the map. Objects are always sprites and they can be of any size. The size of a sprite can not be changed after loading.
All the functionality have one huge issue: Spawning inside another object. This is what will be covered at the end.
Object Collision Detection
The goal of object collision detection is to prevent two or more objects to contain the same space as the other object. Objects should be able to look ahead, check if there is something and adjust the movement distance in that direction.
- There is no pixel precise collision detection, the reason for this is because if the animation changes it can happen that one pixel will be in the collision. The collision area is always a box that is decided on load (see technical details for more information)
- The above collision detections will prevent teleporting through borders (though this happends only in pixel precise collision detection) and walking behind someone at the same speed (see: map movement)
- Collision detection is limited to the context of the map. Two objects who are both on a different context can not collided with each other.
If an object collides a collision a trigger might be called. The triggers related to collision are:
- OnTouchObject, the player touches (walks in to) an object, won't be triggered if the player is running
- OnTouchPlayer, same as OnTouchObject but then the other way around. The object now walks into the player.
- OnCollideObject, the player runs in to an object (rams the object), this won't be triggered if the player is walking
- OnCollidePlayer, the objects runs in to the player (rams the player)
- OnPushObject, the player keeps moving (keeps bumping, keeps touching, keeps colliding) for more than a 0.5 seconds the same object.
Object Actor behavior
How can objects behave. This is mostly related to how NPCs (Actors) move around. All behaviours have a list of options. These will be added later using a table. A list of object movement behaviors:
- User controlled, this object is controlled and moved by the user. This object is called the player. Though this behaviour can be assigned to multiple objects in general it's assumed that there is only one object having this behaviour.
- Approach the player, the object will look up all the paths to all user controlled objects and then follow the shortest path.
- Flee from the player, the object will try to move to a node that is further away from the player than his current node prefering nodes that do not bring them closer to the player. If the prefered node is blocked by the player they will move away from the player ignoring paths.
- Pure random movement, the object will move X steps in a random direction untill it is blocked at which a new direction is chosen. This can cause that the object will move against a wall, however the next direction will at least allow one step (ignoring other objects). They further can have a minimum and maximum waiting time for each time they need to chose a new direction
- Region movement, similiar to pure random movement but if the object leaves the region because of random movement it will stop and the next random move must bring him back inside the region.
- No movement, the object it self will not move if left alone
- Guard, the object it self will not move if left alone and if for any reason it was forced to leave his spot, it will return to it's spot at the next occasion.
- Script based, a movement script is attached to the object.
Subtle object behaviour
"Subtle object behaviour" is more about how the object will behave when something unexpected happens for the actor. An example of an unexpected event for an actor is when he is blocked. Being unable to move is something that is not expected. There are various solutions and each object will handle them in the following order. The engine will notice the following "unexpected events":
- Unable to reach destination:
- Blocked, the current path is blocked from the current position to the end destination. This means there is however at least one alternative solustion given by the pathfinding AI.
- Cut off, all valid solustions provided by the AI are blocked.
- Lost, the pathfinding AI didn't provide a solustion. This should never happen.
- Interaction by another object:
- Being pushed, the current object is being pushed by another
- Pushing, the current object is pushing another object (this happens when another object is standing on the path. The path is not blocked)
For all of the above the following actions can be set
- Avoid, the the object will try to move out out of the way of the object that is the cause of the unexpected event. If the object he is pushing against is moving it will try move behind it's back.
- Attempt breakthrough, the object will try if it can move through by pushing the other object away. If this is not possible it will avoid or divert.
- Ignore, the object will just continue moving in that direction.
- Wait, stop moving and wait for the route to become available again.
- Divert, the object will caculate an alternative route and take that. If no alternative route can be found it will try to get close and wait untill a route is available.
- Get Close, Try as close as possible to the destination as possible but do not push.
- Error, the application will throw an error. This is usefull when you want to test if something is lost.
- Script, a special script will be called.
The engine will assume that the collision regions of two objects will never overlap. Pushing an object for example will be simulated (as in a object keeps pushing after which the pushed object learns he is being pushed, looks up who is pushing him and then decides to move as well). The engine does not allow that objects will move in another objects collision region, this is however only if the object moves.
However there are three situations in which an object doesn't move:
- During the loading of a map, the initial placement is a not a move
- Teleporting, The object is placed at the new location, ignoring movement and the rules applied to movement. This is likely to happen when switching from context.
- Spawning, an object is spawned on the map. This is similair to loading of a map, but than when the map is already loaded.
For all the above the following issues the following solustion is applied: Collision detection will ignore the collision algorithm with objects whose collision regions overlap.
- Objects who have collision regions overlap with each other on the same context will ignore each other.
- The collision algorithm does not allow objects to enter each others collsion region except:
- during loading
Map and scripts
A script is the same as a lua script and will there for have the same advantages and disadvantages as a lua script.
On the map a script can be called by the following triggers:
- used to teleport to another context
- The player attempts to leave the city, but is tehn reminded by the NPC he still has to do something.
- Opening a chest
- Talking to NPCs
- Reading a sign
- The player tries to walk in some guards
- the player runs through a crowded city and collides with an NPC who will then tell him to be more careful.
- Rocks are coming down the mountain and each time the player is hit a random character in the party gets hurt.
- The player is pushing a rock out of the way (box push puzzles)
- Each tick that the player is inside a poisinous region he will be damaged.
Further a script can be added for the following:
- Script based movement
- When something is colored green and underlined it will mean that this is an example and might not be found back in the game itself. Anything else however is part of the final game.
Combat is an essential part of the game. The majority of the game time will come from combat.
Original idea behind combat
"Require a high level of strategic thinking and planning from the player, and less mindless "button mashing" found in many RPGs."
When a combat is started the players party will appear on the left, while the enemies will be on the right. At the bottom the user can view what the status is of each of the currently fighting characters. On the right side you can see the stamina bar which is divided in three parts:
- Recovery (aka idle), in this part the combatent is preparing it self to attack. It's like catching your breath.
- Warmup, the combatant has chosen an attack but this requires some preparations before it can be executed
- Cooldown, the combatant has executed it's attack but the attack requires some more time to finish. You're trying to recover from the attack.
Though the bar is the same length for every combatant on the field, the duration for each part is different. It is just to visualize how long it has to wait in percentage. This means that a combatant can overtake another combatant during the idle-phase, but in turn can be overtaken in the warmup-phase.
Each skill requires a warm-up and cooldown-phase, they may require 0. After a skill is executed and the cooldown-phase has passed the combatant has to recover. The length of the idle-phase is decided by the stamina the character has. The more stamina the faster it will go through the stamina bar.
- Calucalte the total amount of active combatants
- Calculate the total amount of stamina of active combatants
- For each combatant divide the total amount though combatants stamina
- multiply that value with the a pivot value (like 5 seconds)
MinimuSecondsWaitingInIdle = 5; // The minimum amount a character has to wait CharA.Stamina = 100; CharB.Stamina = 10; // CharB is ten times slower than CharA TotalStamina = CharA.Stamina + CharB.Stamina; // result is 110 CharA.StaminaTimeRecovery = 110 / CharA.Stamina; // this 110 / 100 = 1.1 CharB.StaminaTimeRecovery = 110 / CharB.Stamina; // this is 110 / 10 = 11 CharA.ActualTimeWaiting = 1.1 * MinimuSecondsWaitingInIdle; // Idle section takes 5.5 seconds CharB.ActualTimeWaiting = 11 * MinimuSecondsWaitingInIdle; // Idle section takes 55 seconds
The above system has one disadvantage: Speed characters require huger increases in stamina with each level to maintain there "speed"
The combat ends when all combatents on one side are unable to continue combat. If the users party is unable to continue a game over screen will be displayed else a combat result screen will be displayed. A combatant is unable to continue when:
- He is unable to participate in combat and is unable to recieve recovery from the currently active combatants on his side.
- He is knocked out (death)
Each combatant has the following basic properties:
|Short name||Complete name||Descripition|
|Name||Name||The name of the combatant. Enemies often have there type, while players have their own name|
|HP||Current Health Points||The current health of the character|
|MaxHP||Maximum Health Points||The maximum health each character can have|
|SP||Current Skill Points||The current amount of skill points|
|MaxSP||Maximum Skill points||The maximum amount of skill points|
|STR||Strength||The amount of strenght he can use, often for physical attacks|
|DEF||Fortitude||The amount of fortitude the character has. Often used for defensing and reducing physical damage|
|VIG||Vigor||Represent the amount of metaphysical (elemental) damage it can use in offense|
|RES||Resistance||Represent the amount of metaphysical (elemental) damage it can use in defense. Often used to reduce metaphysical damage|
|STA||Stamina||The amount of stamina|
|AGI||Agility||The amount of agily a character has. It is often used for evasion of attacks but it does not have affect on stamina recovering.|
Further each combatant has four physical elements and the four metaphysical elements.Still need some thinking about this
Saving and Loading
A game can be saved at any time when the player is on the map and no cutscenes is running. Upon loading a save game the player will be set in the closest city that he has at least visited once.
The game will support four save games.
Complete save game
End of module
End of game
Game engine (Art section)
Art = Audio & Graphics
Since art is a broad term we will limit it to audio and graphics. Story elements for example won’t be discussed here.
Modules in general are supposed to be stand-alone modules and unable to share resources but since this has many down sides to it
Basic module information
Basic map information
- Map Name (name of the map, acts as ID)
- Map Title Image (this is the image shown when you enter the map)
- Map Dimensions (height x width)
- Free running (this is a flag that tells if running is free)
Lower Layer designer
Middle Layer designer
Upper Layer designer
Entity Layer designer
Save game data format
Module data format
Sprite data format
Keep in mind that animation sets are looped and will be restarted if and only if another animation set is started. Scripts can adjust the variables.
Sprite definition format
- Sprite file
- Dimensions Sprite (H x W)
- Dimension of Collision Region in the dimensions of a sprite (TopOffset x LeftOffset, Height x Width)
- Not mandatory, if they are missing the sprite is a ghost (meaning no collision)
- The region must fit inside the dimensions of a sprite
- Animation sets (at least one which must be “standing”, the order here is also the order in which they are stored in the file)
- Animation Set Name (for example: “standing”, “walking”, “running”, “pushing”)
- Amount of frames for each facing (must be 1 or bigger)
- Time for each frame in the animation
The following animation sets can be used in the engine:
- Standing (required at all times, this is a default sprite)
If the engine grabs an animation set by default (for example it tries running) and that one is not available than it will use the “standing” one.
Sprite image format
A sprite image must be of the type PNG. Transparency will be taken in account when the image is loaded. When a sprite image is loaded it will be parsed from left to right, from top to bottom. If it encounters the right side of the image it will try to load the next row. See the example if two animation sets both of 7 frames you can get something like this
But you could also load it like this (I have left out a few frames, so just imagine that those two frames are actually 7 frames, they would all be on the same row).
Map data format
Default function each map has to have: