TDD
Level Editor
2D Gridsystem
Visualize Grid
Visualising the grid using a queue/list of vertLines and horLines which get put on the respectively other side if the grid moves out of sight.
In the Queue/List the first element is the top/left line and the last is the bottom/right element.
Grid Data
The Grid will need to save data of all objects within the Grid, since the 2D Grid will be used for pathfinding calculations, movement, checking for obstacles, etc.
- All viable standing locations
- For every tile:
- All directions to move to
- All special actions which are viable (e.g. buttons, keys, etc.)
- What Entity is on that tile (e.g. Player, Enemies, etc.) {Vector 3} (The Entities will save this value and only check it on the GridSystem)
=> Maybe as a big matrix with each element being tile or edge and tiles know they can traverse to the next tile if the element in that direction is empty. So if tile(2,2) wants to go to tile(2,4) it check's edge(2,3) if it's empty or not
=>=> a Object[,] (2 or 3 Dimensional Array) Objects can be Edges or Tiles => Need to be able to be handled using a single Type since handling two different 3dimensional Arrays would be an absolute pain in the arse and I dont want to need to scan every wall into each tile, because that sounds like a lot of work and a lot of overhead calculations I don't want to need to do. (Especially since reconstructing the Level from just tile information will be very annoying)
Placing Edges
Edges will only be placed in straight lines.
LeftClick on an empty Grid-Edge will place a Edge
Hold LeftClick will place Edges as far as the mouse is dragged in the according direction.
Placing Tiles
Tiles will be placed in squares,
LeftClick on an empty Grid-Tile will place a Tile.
Hold LeftClick will place Tiles in a square according to the new mouse pos. So clicking on (1,1) and dragging to (2,3) will attempt to place Tiles on all 6 tiles between them.
Game Systems
The very foundation of the game.
Game Manager
Needs to accessible from everywhere at any time while the Game is running.
Keeps track of all persistent data. (And all data which needs to be saved)
- Main State Machine (Menu State, Combat State, Exploration State, etc.) {Enum}
- Keeps the other Managers in check
- Player Party {Party Object}
- General Progress
Dungeon Manager
Needs to be accessible by everything on the Grid during Exploration. (So as long as the Player is in a Dungeon)
Keeps track of all dungeon data.
- Dungeon Information {Dungeon Object?}
- Dungeon Name
- Anything else a Dungeon needs to know
- Handles the Grid System {Most Likely a 3 Dimensional Array or a GridSystem Wrapper Object}
- Position of everything on the Grid
- Tick-Based Movement
Combat Manager
Needs to be accessible by all combatants during Combat. (Only as long as combat is happening)
Keeps track of all combat data.
- Enemy Party {Party Object}
- Player Party {Party Object} ? Redundancy from GM ?
- Turn order {Character[] which can loop trough}
- Any "Field Effects" or similar (if they exist)
Party System
(Player) Party:
- Characters [] (with their position in the array according to the formation)
- Inventory (Scriptable Object containing Item[] and search functions, etc.)
Character
- Name {String}
- HP / MP {int}
- Stats (Maybe also as Dictionary?) {int}
Item System
Items will need to be accessible from everywhere using only an ID.
-> Have them saved in a big Array?
-> Save that Array in a xml?
Every Item is a Scriptable Object.
Equipment, Key Items, etc. are children of "Item"
Somewhat similar to https://github.com/sniffle6/Scriptable-Object-Inventory Implementation as reference if stuck.
!!! Stats must somehow be accessible from the parent since saving won't work otherwise !!! (3 or 4 are probably the best options)
1 => Nested Scriptable Objects (which is a pain in the arse)
2 => Everything is in the main Item but things will be ignored if the type isn't correct?
3 => Do Clever things with dictionaries so everything "can" be everything without obsolete data, but have sort of prefab Scriptable Objects which already have the needed Dictionary Entries for the according Type filled in OR have the required Dictionary Entires be filled in as soon as an Item-Type Enum has been assigned in the Editor window.
4 => Have 3 Completly Seperate Inventories for Equipment, DungeonItems and KeyItems? => But would also require extra Databases to save them, instead of having just one for everything. Each would have a Seperate ID-Space, so several Items could have ID 1.
!!! Decide this when more Info about what the different requirements for Equipment,DungeonItems and KeyItems exist. !!!
Item
- ID {int}
- Icon {Sprite}
- ItemType {Enum}
- Description {String}
EquipmentItem
- Equipment Type {Enum}
- Stats (as Dictionary(str,int) so Armor can have different Stats than Weapons, etc.)
DungeonItem
- ???
KeyItem
- ???