java - Identifying threads in game (TCP related also) -

java - Identifying threads in game (TCP related also) -

this school project, please not provide code, looking hints guide me in right direction.

write , test game server clients subscribe to. 1 time subscribed, client receives list of games (the same game, different 'instances' of it) in play. client may elect bring together game or start new one. game must have @ to the lowest degree 2 players before starting. scheme must back upwards multiple clients playing 1 game, or multiple clients playing multiple games.

the objective of project gain experience in java, tcp, , threading.

my current design , implementation has 2 files: server.java , client.java

the server file has 3 classes: server, lobby , game the client file has 1 class: client.

the implementation of "game" trivial, fine that.

currently, server class establishes tcp connection client class. each time client instantiated, socket accepted in server class, , programme continues.

continuing on, server class creates lobby class.

the lobby class having trouble with. default, creating 1 "game" object, , passing in clientsocket:

game g = new game(clientsocket, playerid); g.start();

the game class extends thread, think right way of doing it. each "game" separate thread, speak, players , b can share 1 thread, , players c , d can start new game thread.

i new threads, best implementation think of. ruled out having multiple threads lobby's, since doesn't create sense, , multiple threads clients pointless too, think multi-threading games class ideal.

right now, when create 2 instances of client, both joining same 'thread' (they both in same game , can talk each other).

how supposed that, new player can type "new" or whatever in lobby , create new "game", it's new thread.

i'm sure mis-understood parts threading or whatnot, appreciate help.

firstly, suggest read on multiplayer game development , networking in java (udp/tcp). no game-developer happenned take java networking course of study in college , had similar project (a networked game).

secondly, dealing multiple threads proportional complexity. want minimize complexity. suggest abandon "i have find place utilize threads" mentality. (don't forcefulness square peg in round hole ;))

continuing, next through requirements:

write , test game server clients subscribe to.

iirc, straightforward (and you're past part).

once subscribed, client receives list of games (the same game, different 'instances' of it) in play

this should straightforward since tcp connection between server , client have been established already.

however, there couple of things understand @ point. important, perhaps, there single central server hold info on connected clients , existing games. consequently means has 1 deal state of scheme (e.g. tracking existing gamerooms), client requests (to create/join gamerooms), updating clients relevant info on system's state (e.g. created/closed gamerooms).

another consideration @ point scope of client's functionality in system. typical implementation fat-server, thin-client architecture. basically, means client no real processing of info (from user input) , instead relies on server. of time, then, client waiting input user or response server. on otherhand, server deals processing of info clients, updating scheme state (including individual game states), , notifying concerned client of relevant changes in system/game state.

the client may elect bring together game or start new one

what happens here client sending info "i elect bring together game" or "i elect create game" server. server acts on , notifies concerned clients (i concerned , not all since clients perchance playing , not need know whether new games have spawned).

a game must have @ to the lowest degree 2 players before starting.

-

the scheme must back upwards multiple clients playing 1 game, or multiple clients playing multiple games.

again depending on client-server architecture, either server doing processing (fat-server, thin-client) or clients (thin-server, fat-client) processing while server serves relay point other clients. have no definite (or confident) suggestion on this, however, overwhelmed sheer number of possible implementations , consequences. thus, can't encourage plenty read more on networking , game development. individually, 2 topics incredibly vast, much more when combined.

lastly, regards utilize of threads. iirc, dispatching separate threads opened sockets useful in preventing application getting blocked waiting input. don't agree thought of "hosting" game in thread since you're in school can admire trying things out.

this may help further: lesson: sockets. , might perhaps interested in udp.

java multithreading tcp gaming