As you can see from the above GIF, I definitely was able to get something done these past few days. And luckly for me, they were more or less the things I outlined in my last post as things I wanted to work on next.
TILE DATA CLASS
This class encapsulates all known data about a specific tile. More specifically, it currently contains:
- Terrain Name
- Is Walkable
- Defense Modifier
- Dodge Modiifier
- Accuracy Modifier
- Movement Modifier
Mountains aren’t walkable, the desert has a movement modifier of -2, grass doesn’t alter any of these attributes, etc. You guys get the idea, not doing anything revolutionary here.
So now, when I’m loading my TileMapData class with the 2D array of tiles, instead of just passing a range of 0-3 for each tile (which used to just represent which graphic to show), it’s now replaced with an instance of TileData.
In fact, here’s a rudimentary understanding of how everything works together thus far. Maybe I’ll get fancy and start using real flow charts and whatnot:
- There is a data file that contains all the tilemap information for a particular area of the game. For simplicities sake, we’ll call it VeronaForest_1.json.
- TileMapDataLoader loads VeronaForest_1.json, and begins to parse each tile attribute.
- Each parsed out tile attribute will become an instance of TileData.
- Each instance of TileData is stored in an internal 2D array, which is contained within a TileMapData class.
It should be noted that all of these clases are Engine agnostic. They’re simple C# classes that don’t know anything about how to render, draw, etc. They’re just filled with data, data that can be passed to any system. So while this is being done in Unity, it could easily be ported to something else.
But I am using Unity, so, to continue to the pipeline:
- TileMap (Unity class) has a referfence to TileMapData, and can iterate over it in order to draw the actual tile map. Now, being a Unity class, it does have to know about TileMapData. However, the way things are split up, if I need to change how everything is drawn, say, I’m moving from top down to isometric, the only class that needs to know about that is TileMap. TileMapData can stay as it is.
TILE SELECTOR ICON
This was pretty easy, as it was more or less implemented during quill18’s tutorial. Unity has a fairly easy to use event system with regards to mouse movement, and it was pretty easy to override the Update() function, which runs every frame, and do the following:
Check the position of the mouse.
See which tile coordinate it is in.
Move the tile selector icon, which is really just a flattened 3D cube, to said tile.
Make the movements snap into place by moving a distance equal to the width/height of the tile.
So yeah, nothing special here.
Ah, Unity UI. Released maybe 2 years ago, I think? It’s supposed to make rendering all sorts of UI easier, and give better performance. Whereas with the old system, it was pretty much all scripting based, this time around, you gave actual gameobjects you can create within the editor. Once you create a UI you are happy with, you can create a prefab of it, and then use it anywhere in your game.
The biggest thing I dealt with was how to utilize them. Sometimes, I don’t think people appreciate how much work goes into actually designing a system that is robust, less prone to errors, and highly performant.
In my case, I did a lot of research into the pros and cons of dynamically loading the UI prefabs when I need them (caching them, of course, once loaded), or just including a reference to each one I need wherever it’s needed.
After a lot of soul searching, I am going to go with the latter solution, and see how that pans out. I’m think some sort of UI Manager/Controller is in my future. Main issues with loading assets at runtime is that I’m already going to be doing a lot of that as it is. So the less strain I put on the system, the better.
In terms of getting the values to change on the tile terrain details panel, that was pretty easy. As I already have a rerference to that UI gameobject, in the code where I move the tile selector icon around, I get a reference to the TileData object that represents the tile that is seletced. Then, I just grab the important data, set some text values, and I’m good to go.
THOUGHTS ON PROTOTYPING IN GENERAL
So in general, things are going quite well. I technically had most of these things done days ago, I just ended up getting pretty busy with work, and not having time to write this blog. So if I take that into account, I’m really doing good.
Also, I’m a firm believer that during this prototyping phase, the “look” of things does not matter. I know that most blogs want to show things off looking as good as possible. However, with this blog, I’ve always wanted it to be a catalog of true history. No revisionists history here. I absolutely love going back to old blog entries, to see how shitty my games have looked, and then look at the final product. I also think it’s good to show people the real side of game development, as much as I can. And that way of blogging isn’t going to change.
On the other hand, even though I’m prototyping, from a coding perspective, I’m definitely striving to make all the right decisions up front. Coding standards, best practices, that sort of thing. Sure, I’ve been a software engineer for 12 years, but when people say, “Oh, picking up another language is just syntax”, it goes deeper than that. You must really learn the guts of the language if you want to write some as complex as a game.
Performance is the first thing on my mind in every decision I make. So even though I’m prototyping, I’m still trying to keep things respectable 🙂