Member Avatar for soapyillusion

Hello all,

I recently started working with java, and I have been in the process of creating a new game for use on Android operating systems.

I have at least 90 percent of the game fully conceptulized and at least 30 percent of it already in actual code.
However I have ran into a small snag. I want the game to be two players, And I want the game to be turn based. Im trying to figure out what would be the best way to do this.

Have each player be its own instance of the same class? Or would it be better to make each player its own class? Or should I go so far to make each player their own file in the applet? What would you guys here recomend. What would in the long haul give me smallest headache??

  • 2 Contributors
  • 2 Replies
  • 136 Views
  • 3 Hours Discussion Span
  • Latest Post Latest Post by soapyillusion

Dani AI

Generated

As noted, modeling a Player as a reusable class and instantiating it per participant is the right starting point. Expand that by separating responsibilities: keep player-specific state (id, name, score, inventory) inside a lightweight Player model; keep match-wide state (board, currentTurnIndex, matchId, version, history) in a GameState/Match object; put rules and validation in a GameEngine that updates GameState. That separation makes unit testing, persistence, and networking far simpler.

A minimal Player example (serializable to JSON for network/save) might look like this:

public class Player {
  public final String id;
  public String name;
  public int score;
  public boolean isLocal;

  public Player(String id) { this.id = id; }

  public JSONObject toJson() throws JSONException {
    JSONObject o = new JSONObject();
    o.put("id", id);
    o.put("name", name);
    o.put("score", score);
    o.put("isLocal", isLocal);
    return o;
  }

  public static Player fromJson(JSONObject o) throws JSONException {
    Player p = new Player(o.getString("id"));
    p.name = o.optString("name");
    p.score = o.optInt("score");
    p.isLocal = o.optBoolean("isLocal");
    return p;
  }
}

For online turn-taking, use a server-authoritative flow: clients submit a compact "move" + baseVersion, server validates and returns the new GameState (or rejects stale moves). Include a version or lastModified timestamp in GameState so stale updates are rejected. Notifications can be push (FCM) or WebSocket; polling is fine for a simple prototype. Allow local hotseat/pass-and-play first to exercise turn logic before adding networking.

Cautions and practical tips: do networking off the UI thread (Executors/Retrofit), persist GameState in onSaveInstanceState/onPause (Parcelable or JSON), avoid storing large objects in Bundles, and keep game logic free of Android framework classes so it’s testable. Server-side validation prevents cheating. Refer back to for lifecycle/persistence decisions once the model and turn flow are sketched out.

Recommended Answers

All 2 Replies

Member Avatar for JamesCherrill

You don't suppy a lot of info, but I'm 99% sure you should have a Player class with one instance for each player. Obe class per player misses the whole point of classes.

Member Avatar for soapyillusion

Thank you,
now I just have to figure out which variables will be global and how to make this online.... TO THE BATCAVE!!! urghh.. I mean Google.....

Edited by soapyillusion
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.