Easy wrote:Continued development on ZunTzu is great news. I use ZunTzu for rapid prototyping and playtesting. I am currently working on a 10 player card game with simultaneous turns. Here's my input...
1) Allow players to independently [zoom], [pan] and [view board].
This is the most frequent issue we encounter during playtests. Players cannot zoom in to read card text without disrupting everyone else, accidental pans and zooms regularly disrupt the game and I cannot make use of tabs for players to study and manipulate private or other information without disrupting the other players. I cannot stress this one enough, it would solve SO many other little issues and headaches.
I fear this is going to be a major change to the program. I haven't delved far enough into the code to be sure, but I think this will have to involved a decoupling of the "world" data from a view's data, and it'll be non-trivial (but certainly doable).
A workaround I have in mind for the time being would be a "pass the control baton" system where only one person has control of the view at a time, and he passes that control to the next player in turn when his turn is up. It de facto allows observer players, as they'd simply be connected players who were never handed the baton. I'd probably allow this to be disabled for backwards compatibility (a "free for all" mode like we have now).
Another easy change would be to have hover over an item display that item magnified in a corner of the screen (this would be user-preference controllable). It breaks the zen, so I need feedback from Jerome and others to be sure that one's a good idea. I guess I could have the "magnifier" follow the mouse around, so it's more real life accurate. The idea would be that when you don't have control, you could hover over items to see them magnified. You'd still have trouble if the controller panned away from what you wanted to peek at, but it's an amelioration step for now.
2) Eliminate black bars.
This would likely work best with a solution to item 1 above. I have a lot of players with a lot of game pieces on the board and screenspace is at a premium. On my netbook my resolution is 1366x768 which leaves black bars of unused space on the left and right of the screen, even with [widescreen] checked in display settings. Letting the gameboard fill all available screenspace regardless of each user's resolution and aspect ratio would be great.
Being the cynic I am about Microsoft and their practices, this might have been a necessary evil. Will look into it.
3) Private information.
This is a complicated issue with a multitude of different ways it could be approached, so let me simply describe a specific use case: My players collect resources, of which I want both the AMOUNT and TYPE to be kept private. They also have a hand of cards of which the TYPE needs to be private while the AMOUNT is public. The hand is easy: players can place cards in their [hand], the cards can then be privately inspected and the size of the hand is displayed publicly. The resources are problematic however, since putting them a player's [hand] now reveals information about the amount of resources while obscuring the amount of cards also in the [hand]. Ideally, the resources also need to passed from player to player privately.
There is a [hide board] feature which currently isn't very useful to us, since it's impractical to wait for 10 players to inspect their private tabs one at a time. Even if players could view different tabs independently, I'm not sure how useful this would be given the amount of back and forth to the main board that would be required.
One thought I had about this was to maybe add a private side board for storing things that are private, but not in the hand. This really addresses the symptoms rather than tackling the problem holistically, so it would probably just be a step in the process (I do think this is a good thing to have across lots of games, so it's not a total hack).
An off the wall approach: Allow players to set a flag on a piece of terrain to hide all pieces placed ON TOP of it from everyone but the "owning" player. I already use terrain-based 'player mats' to organize the tabletop, something like this would add a lot of power. Players could easily drop items onto another player's private supply, they can manipulate items in their private space while still seeing the rest of the table and items can be easily shifted from private to public simply by moving them off the space.
Long term, I want to make hierarchies of objects into a concept in ZT. If you have a map, with terrain, with counters, and you move the map, everything else moves relative to it, as you'd expect in real life (I'd leave out momentum and things falling over from real life though
). When I add hierarchies, then ownership would definitely be an attribute of a hierarchy, and how ownership affects visibility and adjustability of objects within the hierarchy. Making that work from a software engineering perspective is fairly straightforward, making sure it's "invisible" to the user (it needs to be intuitive and "just work and make sense" to users) is the important and could-be-tricky part. Let me underscore that this is a LONG TERM goal, and shouldn't be counted on any time soon.
A) Above all, I want a stable platform.
The existing version has been quite stable (outside of the spacebar crash) and recovers gracefully from any crash I've had thus far. If updates are made to the game, can I continue to test with my players on an old (known to be stable) version, or will the auto updater force us to install the latest version?
This really should have been at the top. I have a new codebase to work through [side note: Jerome is one of the cleanest coders I've ever run across, especially for someone who built this code by himself, it's cleaner than, say, NetHack looks -- other side note that Joshua was a member of the NetHack dev team in the past, if anyone cares], and some learning to do.
My greatest concern is that I not break the world with auto-updates on my first patch. That's why it will be small and of the safer, straightforward variety. Then I'll build from there.
I need to ask Jerome exactly what the issues are. I THINK I could just take a 1.3.1 version out of circulation, and it would back-patch everyone to 1.2; but I need to make sure I could do that if needed.
I also believe there's a way to launch ZunTzu without the auto-patch step; but I have to investigate that too.
Best answer is, I'll be focusing very closely on this issue for my first releases to make sure everything moves forward only.
Easy wrote:Thanks for your efforts, I look forward to seeing how ZunTzu evolves!
Yeah, me too.