1
\$\begingroup\$

I'm designing a board game (Settler of Catan) in which you should be able to use resources to build constructions like roads, settlements, etc.

I have a View in which i draw my map on, also a button Build. If a player wants to build something, he/she should click it and should be able to choose which tile he/she wants to build it on.

The thing is i'm wondering if i should start a new Activity just for this Build -Action or should i implement a methode that runs a while- loop until the user has chosen in which tile he/she wants to build the thing on.

In my mind, a while-loop has never been a good way because the programm has to check the condition almost always -> maybe a problem of performance.

I'm thankful for any suggestion to solve this problem.

\$\endgroup\$
  • \$\begingroup\$ You should only need to test if the player is currently picking where to build once per frame (if doing it inside your game loop), or once per action (if reacting to an input event), either of which would be dirt cheap. It sounds like you might want to read up on managing game states for handling modal actions like this. \$\endgroup\$ – DMGregory Jun 11 '17 at 22:39
0
\$\begingroup\$

The software architecture pattern you are looking for is a state machine.

Your user interface should have different modes (or "states") in which it shows different UI elements and reacts differently to user input.

When the user clicks on "Build", your UI should switch to the "select build tile" state where the tiles where the user can build are highlighted. When the user clicks a tile, switch to the "Select building" state. In that state the selected tile gets highlighted, no other tile can be selected, but the player can select what to build. When the player selected the build option, apply it and return back to the default UI state. Each of these modes should also have some way to navigate back to the previous state, in case the player changes their mind or selected the wrong tile.

There are different ways to implement this architecture-wise.

A common one is to implement each state with an own class. Have all the state-classes implement an interface with a method enter (which shows all state-specific UI elements and sets up their event handlers) and leave (which hides everything state-specific and deactivates the event-handlers). Your main UI handling class should have a public method switchState(state) which leaves the current state and enters the new one.

When developing native Android applications, you might be able to get away with implementing each state with nothing but a different View. Put the code for entering or leaving a view into the onAttachedToWindow() and onDetachedFromWindow() event handlers. Have the main UI handler detach the current view and attach the new one.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.