GameDev: Project Alpha - Tile generation 01
So here we are with the first actual devlog were I will be able to show some progress.
Starting the development of the game I'm making a list of all the ideas that are coming and already some sound too unreal, meanwhile I am keeping a physical book where all the problems are written and were solutions are searched it also serves as documentation, since this project is going to get big.
The first thing that I'm focusing on is creating the "board": basiccaly a tile map where the action will take place. As of now I am able to create e board completely from code and with some degree of randomness, all procedurally generated, so it is different everytime.
Since the design behind the creation of the board is quite interesting (in the opinion of a code-loving guy) I'll be sharing some parts of it. But first of all, this is the current result:
The Board
We went for a (hopefully) rather smart approach, we've separated the logics of the board to the actual drawing and interaction part. So we ended up having a class "Board" that basically holds all the information abount every single cell in the map, but here we got even more smart, instead of having a single class to represent our cells we instead use an interface "IBoardCell", this let us have a single way of accessing those objects but inderneath those could be really different, right now we have standard wlakable cells, obstacles that are not walkable and walls that delimit the play area.
In the future this will let us add a lot more tile types without the need to change anything inside the board.
Drawing the Board
The next problem is how are we going to draw the board, because we now have a beautifult board but no game-objects are associated to the cells of the board and we don't want to just add more data to the cell because we would like to keep things separate.
So we created a wrapper class called "BoardTile" that has a reference to the Board, but extends it's functionality in this case we add the actual game-objects to the game. Since we already knew that there would be more levels of objects inside a single tile and also entities (player or enemies) could enter those tiles, we would have to keep things separate and elegantly organized.
We created 4 more matrices each going to represent a level to be drawn and instantiated in the game world, from bottom to top:
- Ground tiles: the actual tiles that create the walking ground (dirt, grass, stone, wood ...)
- Ground features: the features that a tile can have (flowers, bushes, grass ...)
- Objects: obstacles or other interactable objects
- Entities: all the moving parts (players, enemies ...)
In this way each level can be organized to be drawn on top of the level before so everything is kept organized.
Isometric world
Since our game has an isometric camera we haveto handle things in a bit of a particular way: with an isometric camera we have a 2.5D game and we will have to draw objects that higher on the Y axis further away than objects that are lower on the axis.
In the research of a neat way to do this, since we didn't like just haveing to read the Y value of every object in the screen, we realized a cool rule by looking at the notes we took:
as you can see from the image we have a quick schematic representation of the actual playing grid of the game.
We noticed (RED) that by adding the X and Y value of each horizontal row (not the logical row) we would alway get the same number in each cell we were of that row, for example, the first row only has one cell [0, 0] = 0, the second row has 2 cells [1,0] and [0,1] that both sum to 1, the fourth row has 4 cells [3.0], [2,1], [1,2] and [0,3] that all sums to 3. Following that rule we see that the highers the row the bigger the sum we have and this can be used to determine the z position of the tile, in fact the higher that value gets the closer the row is to the camera.
Then (GREEN) we had to find a clever way for deciding the Y position of a cell, again, we noticed that if we were to sum the ROW and COLUMN value we would get a progressive number indicating the Y position on the game world.
Finally for deciding the X value we find out that if we do COLUMN - ROW we can get the right position of our tile, for example the tile on the fourth row [1,2] = 2-1 => 1 so that tile is "one step" to the right of the middle, the tile [3, 0], of the same row = 0-3 => -3, so it is "three steps" on the left of the middle.
So, to wrap things up, we now have a fully customizable board that is procedurally generated and a flexible architecture that will let us do many things and a lot of customization in the future.
cya next time.
Project Alpha
The first QubitArt RPG Dice based game
Status | Prototype |
Author | QubitArt |
Genre | Role Playing, Adventure, Strategy, Survival |
Tags | 2D, Dice, Exploration, Roguelike, Singleplayer, Tilemap |
Languages | English |
More posts
- DevLog: ProjectAlpha - BiomesDec 08, 2018
- DevLog: ProjectAlpha - attack animationsDec 02, 2018
- DevLog: ProjectAlpha - How the enemies move - quick tutorialNov 28, 2018
- DevLog: Project Alpha - Brain! (AI)Nov 25, 2018
- DevLog: Project Alpha - Basic basic mechanics 02Nov 21, 2018
- Devlog: Project AlphaNov 15, 2018
Leave a comment
Log in with itch.io to leave a comment.