Need design help for a boardgame port please

Newbie & Debugging Questions
#1

Hi,

I am currently working on a port of a boardgame into Java.

My problem is now how to really program the game.

It is not a typical boardgame with fields I could store in an array but a tabletop game where the models could be everywhere on the board.

I thought about doing it like the following but maybe you can give me a better/easier solution.

  • create a class for a model storing the coordinates and the values (e.g. lifepoints,movement range and so on)
  • create a class for the graphics of the models extending JPanel so that i can use a mouselistener to check if someone clicked on the model and returning some info to an infofield.
    -create a class for the board extending JComponent loading the background image
    -create a modellist class storing all the graphical models in a list to keep track of them (a vector as a linear list)

And in the board class i would change the paintComponent to something like that:

//only pseudo code, i know that a vector is not accessable like an array
public void paintComponent(Graphics g)
{
this.drawBoard(g);
for (i=0;i<modelList.getCount();++i)
{
modelList[i].drawModel(g);
}
}

Is that the right approach to that?

It is not real time so i would repaint the battlefield everytime the active player interacted with a model.

Are my thoughts ok like that?

There will no be drag and drop but if a model was clicked and it belongs to the active player he should get a popup dialog offering him choices depending on the phase he is in (movement, shooting, closecombat).

Can I also implement something like that only the units having a boolean value as true to be enabled to click on?

And how can I implement a collision detection? I thought about using sprites is that the correct way or is there a better one?

Thanks in advance

#2

your plan looks plausible. You should be drawing to an offscreen bitmap, then draw the
completed bitmap to the real screen in one swell foop.

Depending on the number of models, update rate, and the overall complexity, you might need to
segregate the models into a background layer for relatively static elements, so your draw loop
would become { draw_background(); draw_foreground(); draw_on_real_screen(); }

#3

Most tabletop games have a manageable number of entities. Say 50 units each side, making it 100 for 2 players. You can store this in a list or maybe optimised data structure.

You can still use tiles, but make them greater. Its rather using sectors. Each sector has a size of 200 x 200 pixels or anything that fits good. Store all things within that sector there. You then have an array of sectors, each sector having a list of a few entites.

I would say, give it a try. Developers sometimes tend to worry about performance, where there is no problem. Processing a list of 100 entries can be pretty fast. Other parts of the game like AI or graphics might impact performance far more. I once read “write first, optimise then”. You can only spot performance bottlenecks, when you made it. I always wonder about A*. Pathinfind can take quite a lot of iterations, and it runs fast on most games I know.

And when its not realtime, it really reduces the permament computation. You dont need to compute AI, collisions or damage or such permanently. It saves a lot of processing power.

-JAW