![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee6:52pm - Well I finally did it. I washed and trimmed my beard and got a haircut. It's amazing how difficult that was. I've been quietly trying to do it for about two weeks now. Now I've done it.
My hair, now that it's been cut, is lighter than ever. Mostly silver-grey instead of copper. It's strange to look at myself and realize 'That's me!'. Oh well. I'd colour it but that's too much work for someone who can barely get it washed and cut.
7:07pm - I'm actually still trying to figure out what I want to do now that I'm out here.
I think what I ought to do is codify how the systems work and will work together. I took a whack at that before so let's load up the GDD and see what's in there...
7:17pm - Yeah, there's some very general stuff in here... Really not much more than a do { game(); } while (!done) sort of thing.
The sticking point is input though. That's where I was stuck before. So how do I want the input system to work. I'm pretty sure I had a good idea for this but I don't think I wrote it down.
I think that, basically, there's going to be a pause in the turn list when it detects a GameObject with a PlayerBrain in its MobileController. The PlayerBrain will detect input by having the MobileController register inputs, and the PlayerBrain will use functions on the MobileController to see what the latest input was.
Personally I think this is a pretty dumb way to do it, I'm just shoehorning things in so they fit.
I think I should probably try to figure out another way to do it. I'm thinking about trying to do the whole project from scratch and use what I've learned to make it work the second time, but it's emotionally difficult and logically difficult both to simply put my work these past months away and do it all over again.
Still, that might be the right choice. I've read a lot about Roguelike Design and Development in the last few months and especially in the last couple weeks and I think that there were choices I made that could have been better.
My TileGrid is a List of Objects. I did that since I figured I'd need to store a lot of data in the tiles themselves, but I'm not so sure of that strategy anymore.
7:52pm - Well let's look at how I might do it differently. One thing is the tiles. A map could be optimized as an array of integers. For a traditional roguelike you can use an array of char but I'll probably have more than 256 different options since I'm using tiles.
Each cell in the map is an index to a type of tile, and that tile type will have static properties. Stone wall, stone floor, earth wall, earth floor, grass floor, etc.
Hmm... Doing that, though, makes it more difficult to author the maps in Unity, it would be more of a method for doing them from a file.
Hmmmmmmm...
I'm trying to think of ways I could build this sort of map in a Unity Scene.
The best I'm coming up with would be to make some kind of visualizer with Editor Scripting.
8:14pm - I was distracted for a little while by a lovely dog just outside the window, but it's gone now so I should be okay.
One of the things I'm considering is using a simpler model for the maps internally than I'm using to display them. Like, a line of walls would have endcaps added automatically. But then it's displaying different tiles than the ones listed, so that complicates things notably. If I don't do that, then things look weird if the type of cell is altered. There's also the trouble of things like layers, like a layer of blood spatter or a layer of water.
Maybe I was right in the first place to use GameObjects for tiles.
I could also mix them. Have the tiles reference an index to determine their base type, then add modifiers?
Another idea occurs to me; each Tile could be a Cell, and each Cell could have many sub objects layered on top of them. This would be even heavier than I was doing, but it bears consideration. A Cell could have a collection of Tiles that are displayed on top of eachother, giving me the Floor at least, and on top of it maybe a wall, maybe a spatter, maybe a layer of fluid, etc...
Another option would be to keep the cells as individual tiles, and have things like 'water pool' and 'fluid layer' be considered items.
8:34pm - Something that's been dancing around in the back of my head is tile deformability. Do I want that? I'm not sure I do. I mean, my inspiration draws more from the Ultima games than most Roguelikes, and you couldn't disintegrate the walls of Lord British's castle. In my game I want static areas and randomly generated areas. And I think the randomly generated areas should be static as well...
It's a tough call. I'm also taking some inspiration from the Mystery Dungeon series of Roguelikes, and in those there were static maps and dynamic maps. There were forests and rivers and mountains in the early part that were static and there were caves that were dynamic.
Mmm... I think... Static all the way. I want to have a dynamic story but that would be severely complicated by having the player burn down this or that area, or blow a hole where there should be no hole. That said, I want parts of the world to change based on player actions. However, I think I want them to change in a static way. Building up a town should always go the same way, or there might be a choice between two buildings but it's always the same two, that sort of thing.
8:48pm - Likewise I'm thinking I don't want to do a fully 3D world like Dwarf Fortress does. It'll be a level surface tile map. There will be buildings with second floors but those will be on another map. You won't be able to fire a bow out a window. Hopefully that doesn't break anybody's immersion.
I'm not sure if I want to deal with flows or not. I probably should, though. I mean, if I don't let the player smash a jug of water and have the water flow everywhere, that's okay, but if there's smoke or dust or something, they should flow to fill an area... Hmmm... But if everything's flat, they could just fill an area directly without the flow. It's pretty hard to represent flows without animation, also.
So, no flows.
Hmm... I'm thinking I should worry more about the structure of my maps. I'm going to do some more research on some other options. But for now it's...
9:05pm - And it takes me about a half hour to get home, so I should get going.
My hair, now that it's been cut, is lighter than ever. Mostly silver-grey instead of copper. It's strange to look at myself and realize 'That's me!'. Oh well. I'd colour it but that's too much work for someone who can barely get it washed and cut.
7:07pm - I'm actually still trying to figure out what I want to do now that I'm out here.
I think what I ought to do is codify how the systems work and will work together. I took a whack at that before so let's load up the GDD and see what's in there...
7:17pm - Yeah, there's some very general stuff in here... Really not much more than a do { game(); } while (!done) sort of thing.
The sticking point is input though. That's where I was stuck before. So how do I want the input system to work. I'm pretty sure I had a good idea for this but I don't think I wrote it down.
I think that, basically, there's going to be a pause in the turn list when it detects a GameObject with a PlayerBrain in its MobileController. The PlayerBrain will detect input by having the MobileController register inputs, and the PlayerBrain will use functions on the MobileController to see what the latest input was.
Personally I think this is a pretty dumb way to do it, I'm just shoehorning things in so they fit.
I think I should probably try to figure out another way to do it. I'm thinking about trying to do the whole project from scratch and use what I've learned to make it work the second time, but it's emotionally difficult and logically difficult both to simply put my work these past months away and do it all over again.
Still, that might be the right choice. I've read a lot about Roguelike Design and Development in the last few months and especially in the last couple weeks and I think that there were choices I made that could have been better.
My TileGrid is a List of Objects. I did that since I figured I'd need to store a lot of data in the tiles themselves, but I'm not so sure of that strategy anymore.
7:52pm - Well let's look at how I might do it differently. One thing is the tiles. A map could be optimized as an array of integers. For a traditional roguelike you can use an array of char but I'll probably have more than 256 different options since I'm using tiles.
Each cell in the map is an index to a type of tile, and that tile type will have static properties. Stone wall, stone floor, earth wall, earth floor, grass floor, etc.
Hmm... Doing that, though, makes it more difficult to author the maps in Unity, it would be more of a method for doing them from a file.
Hmmmmmmm...
I'm trying to think of ways I could build this sort of map in a Unity Scene.
The best I'm coming up with would be to make some kind of visualizer with Editor Scripting.
8:14pm - I was distracted for a little while by a lovely dog just outside the window, but it's gone now so I should be okay.
One of the things I'm considering is using a simpler model for the maps internally than I'm using to display them. Like, a line of walls would have endcaps added automatically. But then it's displaying different tiles than the ones listed, so that complicates things notably. If I don't do that, then things look weird if the type of cell is altered. There's also the trouble of things like layers, like a layer of blood spatter or a layer of water.
Maybe I was right in the first place to use GameObjects for tiles.
I could also mix them. Have the tiles reference an index to determine their base type, then add modifiers?
Another idea occurs to me; each Tile could be a Cell, and each Cell could have many sub objects layered on top of them. This would be even heavier than I was doing, but it bears consideration. A Cell could have a collection of Tiles that are displayed on top of eachother, giving me the Floor at least, and on top of it maybe a wall, maybe a spatter, maybe a layer of fluid, etc...
Another option would be to keep the cells as individual tiles, and have things like 'water pool' and 'fluid layer' be considered items.
8:34pm - Something that's been dancing around in the back of my head is tile deformability. Do I want that? I'm not sure I do. I mean, my inspiration draws more from the Ultima games than most Roguelikes, and you couldn't disintegrate the walls of Lord British's castle. In my game I want static areas and randomly generated areas. And I think the randomly generated areas should be static as well...
It's a tough call. I'm also taking some inspiration from the Mystery Dungeon series of Roguelikes, and in those there were static maps and dynamic maps. There were forests and rivers and mountains in the early part that were static and there were caves that were dynamic.
Mmm... I think... Static all the way. I want to have a dynamic story but that would be severely complicated by having the player burn down this or that area, or blow a hole where there should be no hole. That said, I want parts of the world to change based on player actions. However, I think I want them to change in a static way. Building up a town should always go the same way, or there might be a choice between two buildings but it's always the same two, that sort of thing.
8:48pm - Likewise I'm thinking I don't want to do a fully 3D world like Dwarf Fortress does. It'll be a level surface tile map. There will be buildings with second floors but those will be on another map. You won't be able to fire a bow out a window. Hopefully that doesn't break anybody's immersion.
I'm not sure if I want to deal with flows or not. I probably should, though. I mean, if I don't let the player smash a jug of water and have the water flow everywhere, that's okay, but if there's smoke or dust or something, they should flow to fill an area... Hmmm... But if everything's flat, they could just fill an area directly without the flow. It's pretty hard to represent flows without animation, also.
So, no flows.
Hmm... I'm thinking I should worry more about the structure of my maps. I'm going to do some more research on some other options. But for now it's...
9:05pm - And it takes me about a half hour to get home, so I should get going.
