![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee5:22pm - Well I'm down at the McDonalds tonight to work on my game dev projects again. I'm going to try doing what I was going to do last night, only this time during the... well it's not day, but it's a heck of a lot earlier than two or three am.
Basically what I plan to do is go over the Game Programming Patterns book and try to redesign my current project based on what I come up with so it's a little less spaghetti.
5:50pm - First things first, since I'm making major changes to a mostly working system, I'm making a git repo of the original and branching it, so I can go back if my changes are too crazy or don't work or something.
That's done now, so I'm going to move on to Game Development Patterns and see what I can do.
5:55pm - The first pattern covered in Game Development Patterns is the Command Pattern from the original Design Patterns. The first few patterns are revisits so I won't say that for the rest of them, just saying it now.
The use that the author suggests for the Command Pattern first is making it so you can change up the input. Unity does that already with its button system, though. If you don't know, in Unity you can take direct key input or you can take input from 'buttons' which can be input from many different keys and you can change what keys activate which 'button' and thus what button responders recieve its presses.
Now, that's not all for the Command pattern, though. He also goes on to suggest that it could be used to make a log of all commands that have been entered by the user, to implement things like undo and replay. Undo could be useful since most games, including RPGs which is technically what I'm working on now, let you go back to the previous menu with a cancel button press.
6:12pm - Power On! The fella who was sitting at the table with the power outlet got up to go, or seemed to at least, so I took his spot. Oddly he came back and is standing nearby. I'm not sure if he changed his mind or what; he had put his gloves on and taken all his stuff. Anyway I don't think he minds me taking the spot with the outlet he wasn't using.
Back to the Command Pattern. Another thing he reccomends it for is decoupling commands from your actors, so you can control any character in the game, or have the AI use the command pattern to control the other actors. I'll have to consider that. Though, I'm also considering sticking close to the Component pattern that Unity is designed around. I'll talk about that more when I get that far in the book.
6:34pm - Next up is the Flyweight pattern. I don't remember the details of this one from when I read the original Design Patterns or my previous read of Game Design Patterns so this'll be either interesting or I'll find out why I forgot about it. Heh.
7:05pm - I got distracted because the Flyweight pattern is BORING! Okay not really, actually it's more for rendering issues than other game development concerns, so far, so I guess I wasn't too interested. Then I ended up going to Discord and I found myself inspired with a question.
If you happen to have read this far into my Work Post then maybe you'll find this question interesting too?
When we're all data and able to swap bodies freely, but can also live in VR all the time, will you host your mind in a server and live and work in VR as much as possible, or will you focus on the physical world, despite having physical limitations on your body? (Not going to go into the physical limitations of a VR body taking up too many numbers just now)
Anyways back to the Flyweight pattern I guess...
7:24pm - Alright, the Flyweight chapter was also a Flyweight. I think the reason I don't remember the Flyweight pattern is that I don't grok it entirely. It's pretty cerebral and since it's not used for things I would do (yet) it's hard to lock in the concept.
Anyways moving on, next is... THE BATHROOM!
8:28pm - I'm reading about the Observer pattern right now, and one of the first things he says is that C# has it rolled right into the language with the Event keyword. I only know a bit about that, so I should probably do more research on it myself.
But the idea of the Observer Pattern is that anything can send out a message into the void, and anything can listen for messages from whoever, and they're not directly connected.
9:01pm - Alright, Observer is read and considered and I still have to do more research on C# events... And it's already past 9:00pm. I've been working almost four hours, and the McDonalds is only open until midnight. I'm not sure how much more I have in me but I'm going to keep going for now.
9:06pm - Okay, that's a five minute refresher on C# Events and I think I can see how it relates to the Observer pattern. Interesting stuff.
9:12pm - The Prototype pattern is pretty straightforward and basically what Prefabs are for in Unity. So that's covered.
I also read the next chapter in detail the other night, Singleton. It's mostly a chapter about why you shouldn't use Singletons and part of the inspiration of why I'm trying to get rid of mine.
The chapter after that is State which I also read the other night. But it's a bit more important, since I'm probably going to use it. The State pattern is mostly useful for making Finite State Macines but it's also explained in Game Development Patterns that it can be used for Concurrent State Machines and Heirarchical State Machines.
It's hard to define how I'm going to use it though, now that I'm at the point where I'm supposed to do that.
I'm probably going to turn the Dialogue Engine and Input Manager into state machines. But I'm still fuzzy on the details.
9:25pm - I'm going to skip over the Sequencing Patterns for now, since they're lower level than where I'm working right now.
9:29pm - And I think that's it for me, I'm not able to think straight about the next chapter of the book. So, I'm going to head home.
Ask me about my Jupiter Brain game design idea.
Basically what I plan to do is go over the Game Programming Patterns book and try to redesign my current project based on what I come up with so it's a little less spaghetti.
5:50pm - First things first, since I'm making major changes to a mostly working system, I'm making a git repo of the original and branching it, so I can go back if my changes are too crazy or don't work or something.
That's done now, so I'm going to move on to Game Development Patterns and see what I can do.
5:55pm - The first pattern covered in Game Development Patterns is the Command Pattern from the original Design Patterns. The first few patterns are revisits so I won't say that for the rest of them, just saying it now.
The use that the author suggests for the Command Pattern first is making it so you can change up the input. Unity does that already with its button system, though. If you don't know, in Unity you can take direct key input or you can take input from 'buttons' which can be input from many different keys and you can change what keys activate which 'button' and thus what button responders recieve its presses.
Now, that's not all for the Command pattern, though. He also goes on to suggest that it could be used to make a log of all commands that have been entered by the user, to implement things like undo and replay. Undo could be useful since most games, including RPGs which is technically what I'm working on now, let you go back to the previous menu with a cancel button press.
6:12pm - Power On! The fella who was sitting at the table with the power outlet got up to go, or seemed to at least, so I took his spot. Oddly he came back and is standing nearby. I'm not sure if he changed his mind or what; he had put his gloves on and taken all his stuff. Anyway I don't think he minds me taking the spot with the outlet he wasn't using.
Back to the Command Pattern. Another thing he reccomends it for is decoupling commands from your actors, so you can control any character in the game, or have the AI use the command pattern to control the other actors. I'll have to consider that. Though, I'm also considering sticking close to the Component pattern that Unity is designed around. I'll talk about that more when I get that far in the book.
6:34pm - Next up is the Flyweight pattern. I don't remember the details of this one from when I read the original Design Patterns or my previous read of Game Design Patterns so this'll be either interesting or I'll find out why I forgot about it. Heh.
7:05pm - I got distracted because the Flyweight pattern is BORING! Okay not really, actually it's more for rendering issues than other game development concerns, so far, so I guess I wasn't too interested. Then I ended up going to Discord and I found myself inspired with a question.
If you happen to have read this far into my Work Post then maybe you'll find this question interesting too?
When we're all data and able to swap bodies freely, but can also live in VR all the time, will you host your mind in a server and live and work in VR as much as possible, or will you focus on the physical world, despite having physical limitations on your body? (Not going to go into the physical limitations of a VR body taking up too many numbers just now)
Anyways back to the Flyweight pattern I guess...
7:24pm - Alright, the Flyweight chapter was also a Flyweight. I think the reason I don't remember the Flyweight pattern is that I don't grok it entirely. It's pretty cerebral and since it's not used for things I would do (yet) it's hard to lock in the concept.
Anyways moving on, next is... THE BATHROOM!
8:28pm - I'm reading about the Observer pattern right now, and one of the first things he says is that C# has it rolled right into the language with the Event keyword. I only know a bit about that, so I should probably do more research on it myself.
But the idea of the Observer Pattern is that anything can send out a message into the void, and anything can listen for messages from whoever, and they're not directly connected.
9:01pm - Alright, Observer is read and considered and I still have to do more research on C# events... And it's already past 9:00pm. I've been working almost four hours, and the McDonalds is only open until midnight. I'm not sure how much more I have in me but I'm going to keep going for now.
9:06pm - Okay, that's a five minute refresher on C# Events and I think I can see how it relates to the Observer pattern. Interesting stuff.
9:12pm - The Prototype pattern is pretty straightforward and basically what Prefabs are for in Unity. So that's covered.
I also read the next chapter in detail the other night, Singleton. It's mostly a chapter about why you shouldn't use Singletons and part of the inspiration of why I'm trying to get rid of mine.
The chapter after that is State which I also read the other night. But it's a bit more important, since I'm probably going to use it. The State pattern is mostly useful for making Finite State Macines but it's also explained in Game Development Patterns that it can be used for Concurrent State Machines and Heirarchical State Machines.
It's hard to define how I'm going to use it though, now that I'm at the point where I'm supposed to do that.
I'm probably going to turn the Dialogue Engine and Input Manager into state machines. But I'm still fuzzy on the details.
9:25pm - I'm going to skip over the Sequencing Patterns for now, since they're lower level than where I'm working right now.
9:29pm - And I think that's it for me, I'm not able to think straight about the next chapter of the book. So, I'm going to head home.
Ask me about my Jupiter Brain game design idea.
