Implementing a clickable roullete betting grid

Hi,

I am new to unity2d and need some advice about the following. :slight_smile:
I am trying to create a roullete game where the players can use the grid (See attached photo) to place their bets. Following are the ways the players can place bets :

  • Click on the cells
  • Click on line intersections to place bets covering multiple cells
  • Click on lines between two cells

I want to be able to scale the cell and maybe add some effects to make the hovered over cell or line intersection pop out before the user clicks on it. Once the user clicks they will be presented with a UI slider to place their bet amount.
I am trying to figure out the least resource intensive (in terms of CPU and memory) way to implement the mouse events and cell behavior in case of hover, click, exit etc.

  • Should I create each interactable element as its own GameObject or button?
  • This will introduce ~100 objects for the grid itself. Is this acceptable ?
    • Should I overlay the sprite with custom grids (One for the cells and maybe another one for the lines) and then calculate mouse positions and clicks in the script ?

Any tips/tricks/pointers/design ideas greatly appreciated!

8735421--1182636--roullete_grid.JPG

?!!!?! Why on earth do you care!? One image and a few chips?! Don’t worry, Unity is a beast!

Drag a roulette table graphic in as a UI Image, then go drop invisible buttons at each of the spots. Make it so you click the button it adds a chip, right click it clears a chip. One script to hold them all.

Then write the game. Roulette is one of the simplest possible games to do. Graph out the sequence of interactions, animations for payout, loss, etc.

I would configure the corners with a payout script that is configured with numbers telling what all it pays out as, what rates it pays, etc., the usual pay table.

Don’t get hung up on performance before you have a game!!

DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window → Analysis → Profiler

Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

https://discussions.unity.com/t/841163/2

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Notes on optimizing UnityEngine.UI setups:

https://discussions.unity.com/t/846847/2

At a minimum you want to clearly understand what performance issues you are having:

  • running too slowly?
  • loading too slowly?
  • using too much runtime memory?
  • final bundle too large?
  • too much network traffic?
  • something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

1 Like

Thanks Kurt-Dekker. Thats great practical advice and I needed it! Coming from a software engineering background I tend to overthink problems before implementing.
Going to go the button route and check performance stats :slight_smile:

You really have two options, either you do everything as UI elements or what you described, i.e. game objects with triggers and a click handler script.

Both ways use a different way of handling the mouse, the UI uses events, standard game objects and triggers use some colliders (OnMouseDown for example).
.