4:20am - Well I'm out at the McDonalds again. I haven't had much luck here the last few times, but tonight I was able to read the book I had been struggling with. It turned out the book didn't have anything I didn't already know, but it was nice to get back into that headspace. Then I re-watched a video I've seen a few times now, on using ScriptableObjects for Unity Architecture, and I feel like I might be able to continue with my game again. ^.^
But first breakky.
4:42am - Breakky done! Now let's see...
Right, I was stalling on the event architecture. I had forgotten how to do it and was trying to figure it out again. Well, I did that earlier tonight, so I guess I've got a head start.
Right, I described what I was doing before roughly. I'll copy that here.
Game Start;
Load Town Map;
Wait for Player Input;
Resolve Player Input;
Cycle through Turn List and Resolve each Unit's actions;
Loop from Player Input until exit;
The turn list is a ScriptableObject that manages the turn-based nature of the game. It contains a list of all the objects in the scene, including the player, and cycles through them each to poll them for their action that turn.
The first thing that happens when a scene is opened is that the SceneInitializer script on the Camera goes off. This script initializes the TurnList in its awake event handler and starts the game in its start event handler.
So, the game starts pretty quickly with that design. I want to have the map and everything that goes on it in place before the gameplay starts. I'm thinking that since each scene is going to be an individual thing, that instead of loading maps from files into a scene, I'll prebuild some scenes in the editor, and have another scene that randomly generates a level when it's loaded.
That means that for some maps, everything will already be in place at the start, and for others, there will be a generation phase before the game starts. In either case, for the TurnList, it's important that the first thing in the list be the player.
But hang on, I just thought of something. If the TurnList is initialized on the SceneInitializer's awake phase, it's too fast. The Maps and NPCs won't be placed yet. I'll have to do both the Initialization and BeginGame in the Start handler, right after one another. That should work.
Alright. So, when the scene is loaded, the map has to be setup. For the pregenerated scenes this will already be done, but for the dungeon levels have to be generated first. I think I know where to do that too; I'll make a script later that goes on the TileGrid object of the dungeon scene, that randomly generates a dungeon in the awake handler.
So the map is setup, then the turn order is set up. Now what about getting the player to the front of the turn order?
Hmm... Ahh, that's right. The TurnList doesn't automatically poll for the NPCs/Monsters, they add themselves to the TurnList. I got confused about how it worked and moved the initialization out of the awake function. It's fine to have the initialization there, because the TurnList needs to be initialized before the NPCs/etc can add themselves to it.
So, the scene is loaded, the map is there already, the SceneInitializer runs its awake handler and initializes the TurnList. But then, the actors will need to add themselves to the list between the awake and start functions. Hmm...
What I need is more events. And I'm in luck, because there's a handy event handling solution in the video I mentioned earlier, that uses a scriptable object instead of a singleton. So I'll implement that. Then when the SceneInitializer initializes the TurnList it can release an event to all of the actors, who will be event listeners, and they'll add themselves to the TurnList.
I want the TurnList to work like an initiative order though, so that complicates things.
I figure I'll modify the TurnList's add method to place new actors in order of their initiative or speed. Then I'll have a list of who goes first. Then I could either cycle it around so that it's the player's turn, or move the player to the very fastest on the list. The former would make those slower than the player go first... Yeah I don't see a problem with the latter, as long as I can handle cases where an actor goes multiple times before the player.
Rather than being a strict cycle order, as an initaitive or speed order, actors that finish their turn should be put back in the list based on their initiative or speed, rather than at the end.
I'm tossing around ideas in my head for how it should work.
6:06am - Having trouble with that, I decided to go looking for how other games/roguelikes in particular handle it. So I'm reading an article with an interesting solution.
6:27am - The most promising time handling system isn't well documented and is written in turbo pascal so I don't think I can figure it out. ^.^;;
6:30am - According to this article ( http://www.roguebasin.com/index.php?title=Time_Systems ) it explains how Dwarf Fortress' ticks work, and I kind of like it. So I'll try that.
Basically, everything is put in order based on their speed, then if they have any energy they take whatever action they want to, and that action decreases their energy, and they decrease their energy until they don't have enough to do their next action, and the next entity goes.
Ahh, I have to use the washroom. I'll continue after that.
6:41am - Hokay. So the SceneInitializer initializes the TurnList in its awake phase, and then during the start phase an event goes out telling all of the actors to add themselves to the TurnList. After the event, the game begins and the turnlist moves the player to the bottom of the order. The player takes their turn, and are deducted energy for their action, and then the turn order circulates with each actor losing energy for doing an action. When the loop circles back to the start, everybody gets a little energy back, but the turn order skips anyone who is at negative energy from their last action.
That should work. ^.^
Okay, now let's see if I can put it into words for my GDD.
7:10am - Okay that's enough GDD for now. I want to get back to actually making the game!
8:18am - Well it's rapidly becoming evident that I've lost all my concentration. Now I'm not sure what to do. I could stay here at the McDonalds playing video games for three hours in order to use my coupon for a $3 burger that expires today, or I could go home and play different video games...
Tough call.
Well if I go home there's a good chance I won't be awake still in three hours...
Oh yeah, Robbo wanted to do groceries today. I should go home and come out again to do them after he gets up.
Yeah, goin' home now. Oh and I got the event system in though I haven't tested it yet.
But first breakky.
4:42am - Breakky done! Now let's see...
Right, I was stalling on the event architecture. I had forgotten how to do it and was trying to figure it out again. Well, I did that earlier tonight, so I guess I've got a head start.
Right, I described what I was doing before roughly. I'll copy that here.
Game Start;
Load Town Map;
Wait for Player Input;
Resolve Player Input;
Cycle through Turn List and Resolve each Unit's actions;
Loop from Player Input until exit;
The turn list is a ScriptableObject that manages the turn-based nature of the game. It contains a list of all the objects in the scene, including the player, and cycles through them each to poll them for their action that turn.
The first thing that happens when a scene is opened is that the SceneInitializer script on the Camera goes off. This script initializes the TurnList in its awake event handler and starts the game in its start event handler.
So, the game starts pretty quickly with that design. I want to have the map and everything that goes on it in place before the gameplay starts. I'm thinking that since each scene is going to be an individual thing, that instead of loading maps from files into a scene, I'll prebuild some scenes in the editor, and have another scene that randomly generates a level when it's loaded.
That means that for some maps, everything will already be in place at the start, and for others, there will be a generation phase before the game starts. In either case, for the TurnList, it's important that the first thing in the list be the player.
But hang on, I just thought of something. If the TurnList is initialized on the SceneInitializer's awake phase, it's too fast. The Maps and NPCs won't be placed yet. I'll have to do both the Initialization and BeginGame in the Start handler, right after one another. That should work.
Alright. So, when the scene is loaded, the map has to be setup. For the pregenerated scenes this will already be done, but for the dungeon levels have to be generated first. I think I know where to do that too; I'll make a script later that goes on the TileGrid object of the dungeon scene, that randomly generates a dungeon in the awake handler.
So the map is setup, then the turn order is set up. Now what about getting the player to the front of the turn order?
Hmm... Ahh, that's right. The TurnList doesn't automatically poll for the NPCs/Monsters, they add themselves to the TurnList. I got confused about how it worked and moved the initialization out of the awake function. It's fine to have the initialization there, because the TurnList needs to be initialized before the NPCs/etc can add themselves to it.
So, the scene is loaded, the map is there already, the SceneInitializer runs its awake handler and initializes the TurnList. But then, the actors will need to add themselves to the list between the awake and start functions. Hmm...
What I need is more events. And I'm in luck, because there's a handy event handling solution in the video I mentioned earlier, that uses a scriptable object instead of a singleton. So I'll implement that. Then when the SceneInitializer initializes the TurnList it can release an event to all of the actors, who will be event listeners, and they'll add themselves to the TurnList.
I want the TurnList to work like an initiative order though, so that complicates things.
I figure I'll modify the TurnList's add method to place new actors in order of their initiative or speed. Then I'll have a list of who goes first. Then I could either cycle it around so that it's the player's turn, or move the player to the very fastest on the list. The former would make those slower than the player go first... Yeah I don't see a problem with the latter, as long as I can handle cases where an actor goes multiple times before the player.
Rather than being a strict cycle order, as an initaitive or speed order, actors that finish their turn should be put back in the list based on their initiative or speed, rather than at the end.
I'm tossing around ideas in my head for how it should work.
6:06am - Having trouble with that, I decided to go looking for how other games/roguelikes in particular handle it. So I'm reading an article with an interesting solution.
6:27am - The most promising time handling system isn't well documented and is written in turbo pascal so I don't think I can figure it out. ^.^;;
6:30am - According to this article ( http://www.roguebasin.com/index.php?title=Time_Systems ) it explains how Dwarf Fortress' ticks work, and I kind of like it. So I'll try that.
Basically, everything is put in order based on their speed, then if they have any energy they take whatever action they want to, and that action decreases their energy, and they decrease their energy until they don't have enough to do their next action, and the next entity goes.
Ahh, I have to use the washroom. I'll continue after that.
6:41am - Hokay. So the SceneInitializer initializes the TurnList in its awake phase, and then during the start phase an event goes out telling all of the actors to add themselves to the TurnList. After the event, the game begins and the turnlist moves the player to the bottom of the order. The player takes their turn, and are deducted energy for their action, and then the turn order circulates with each actor losing energy for doing an action. When the loop circles back to the start, everybody gets a little energy back, but the turn order skips anyone who is at negative energy from their last action.
That should work. ^.^
Okay, now let's see if I can put it into words for my GDD.
7:10am - Okay that's enough GDD for now. I want to get back to actually making the game!
8:18am - Well it's rapidly becoming evident that I've lost all my concentration. Now I'm not sure what to do. I could stay here at the McDonalds playing video games for three hours in order to use my coupon for a $3 burger that expires today, or I could go home and play different video games...
Tough call.
Well if I go home there's a good chance I won't be awake still in three hours...
Oh yeah, Robbo wanted to do groceries today. I should go home and come out again to do them after he gets up.
Yeah, goin' home now. Oh and I got the event system in though I haven't tested it yet.