Design Documents & Technical Specs
Anything I think is neat for keeping track of how the game works. Helps me reflect back and remember how things work as well.
2 topics in this forum
-
When you need to design a character for a story there is a simple pair of questions that'll help you out. The first questions is what does this character want? The second question is how far would they go to achieve that goal? I think you can take that same sort of logic and use it to layout design plans for a game as well. With that in mind lets talk about my plans for Moosecats in three phases. The short term, the mid term, and the long term. Some of these things should be accomplished within the next six months, some things within years, and others may never happen. The Goal I would like to create a game that marries a few concepts. The first is a sense of ir…
-
- 0 replies
- 108.5k views
-
-
I wish I could say that the title was my thought. It was actually something said to me at work by our Technical Artist. The more that I've applied this world view the happier I've been with my work. With that in mind I'm going to go over the naming conventions for the current Moosecats work. These are listed in no real particular order. Handlers Our different domains have shared handlers. At the base level our handler does two things. It listens for a client and the game state. The former of these processes needs to eventually be moved one layer higher to a "ChattyMoosecattyHandlerBase". This is because we don't actually care about the client in Fitty Moosekitty…
-
- 2 replies
- 5.8k views
-