You can use an atom's screen_loc var to position it and then add it to a client's screen var to create a HUD.

However, it won't be processed on the client's end. Everything is still done on the server as far as I know.

Deadron wrote:

You want client screen objects...check out:

Nadrew's Hud Demo

Raekwon's Hud demo

And I believe Flick's masterpiece:

F_color_selection is built on client screen objects.

In the F1 reference, check out:

- screen var (client)
- screen_loc var (movable atoms)

Also, while client screen objects are a convenient way to display information on the map to only one player, they aren't required to make this work: DragonSnot displays a unique set of trenches to each player, and was done before screen objects (using images sent to players).

Whatever approach you take, it's really nice in board games and the like if all the pieces are handled on the map, so you don't have to divide your attention between map and statpanels.

It's also nice if you use drag and drop for moving pieces...

dramstud wrote:

I was considering changing the player's icon from the yellow square outline to match the actual piece they have just drawn in Medieval Conquest. If they rotate the piece, their mob icon would rotate as well. This would eliminate the need for the Tile panel.

In a board game, it would be unusual to have the player mob play any visual part in the game -- you'd normally want to have objects the player controls and can move around without changing their view of the board.

Any comments on pros/cons of this method vs. using a client screen object w/ drag 'n drop?

Here are the things to think about:

- If only the player should see something, then use client screen objects if you can (in Poker, for example, the cards in their hand would be screen objects). If the player collects pieces that others aren't allowed to see until they choose to play (I forget for the moment which way it works in Medieval Conquest), then you'd want to use screen objects for those. When the player actually places a piece, you'd switch it from being a screen object to being displayed on the map (by removing it from the player's client screen list and giving it a loc on the map/board).

- If everyone should see something, then just use normal objects on the map. (Much more flexible and less hassle-prone than using the player mob for this...though of course you should experiment with any approach that you think might be useful.)

- If people are moving things around on the map/board, then if at all possible you want to use drag and drop. This really enhances the player experience. Players experience a bit of cognitive dissonence when they have to click an object, then click the destination...there's always that split second where you aren't quite sure what you are doing or whether you selected the right thing or what...drag and drop just plain fixes this.

Whatever approach you take, in my personal opinion, if you can get rid of all statpanels without harming the quality of the game, you absolutely should. Statpanels are wonderful things in games where they belong (RPGs, text games, that sort of thing), and they are great for developing the game, before you have all the UI in place. But in any game where your attention is primarily focussed on the map/board, they tend to be a distraction, and the player is constantly having to choose whether to look at the statpanels or the board, making a mental context switch, and often missing things as a result. It drives me batty in card games especially, where a scrolling list of cards just doesn't match my decades long habit of holding cards in a row in my hand.