I put in some time refactoring my program to make some of the prototype elements work in a more "real" fashion. The code ballooned from 500 to 800 SLOC in the process, which makes me a little nervous. This is code with a lot of threading to handle the network management and I'm also terrified of deadlocks.
The characters visible on the main screen are now actual custom G3D::Entity subclasses, not just visual placeholders. The NPCs are Characters and the PCs are PlayerCharacters. A PlayerCharacter is created automatically when a new client connects. The PlayerCharacter has a hand of Cards that are shown on the private display and a portrait shown on the main display.
Next implementation steps:
- Draw the PlayerCharacters from a queue--right now everyone is the same character!
- Put actions on cards.
- Track game sessions and automatically restart the client when it connects to a new one.
- Put cards into the room.
The gameplay is evolving towards real-time board game play, which is neat. This encourages sneaky actions, too--everything plays out on the main screen in public view, but if you do something during a distracting moment, others might not notice. Design challenges:
- I need to keep most important stats and outcomes on the main screen. Otherwise everyone would just look at their own screen, which would thwart the shared experience.
- When a character takes an action, he/she goes into cooldown mode. How should this be presented in a real-time game to avoid it feeling frustrating, like you're just locked out?
- Cooldown times need to be long enough to encourage deliberate, tactical play, but short enough that everyone isn't sitting around waiting at the same time. I want an asynchronous turn based feel.
- AI, my Achilles' Heel in every jam!
That is an excellent photo of a sick man. I wish I had a photo like that when I was pulling a "me".
ReplyDelete