Bygfoot Football Manager

I know it is an old discussion subject, but now, there are some new developpers who may want to talk about it.

The main idea is to split the game into two parts : a "server", and one or several "clients". Note that lots of network softwares, and especially games, are organized in this way. My main model is "freeciv" (www.freeciv.org).

This idea comes from the fact that there are not a lot of information exchanged between the interface and the core of the game :
* start a new week
* display the game result
* send the players who will play
* display the transfer list
etc.

The server knows how to play. Clients are just interfaces between the human and/or artificial players and the server. Imagine the consequences of a client/server architecture :

* you can imagine other clients : Qt clients, MSWindows clients, Tk clients for very poor people, etc. Each client can be developped independantly, provided it respects communication standards with the server.
* some clients can be not interfaces, but rather small programs, or scripts, which play AI teams. Then, everybody can develop its own AI player, and then compare the most efficient strategies, etc.
* client/server architecture will make the network game very easy

I don't want to tell "Bygfoot has to be a client/server software now". I just want to propose that this architecture can be "simulated", through interface functions which will be changed when the network game will be ready. For example, look at the following (fictive) example :

void ActionHandler(void) { DoAction(); }

interface.h:
void DoAction(void) { ActionOnBygfoot(); }

instead of

void ActionHandler(void) { ActionOnBygfoot(); }

This will lead to more flexibility, since the software will be splitted into two parts, communicating only through functions of "interface.h", for example.

Well, I hope I was clear... Have a good night!

yes I know what you mean

I recently went through this with a project of mine. PyPicn
I wont go into the details here as its not related but you can find it on my twiki (the multi access serial aspect)
http://mec-symonds.eng.monash.edu.au/cg ... ara/PyPicn

It was a big upheavel for me but wow it makes a big difference once its done.
It allowed me to write stimuli scripts for testing and debugging as well as its intended operation. Simultaneously too. I could actually get it to run a normal job script and then while it was doing that send it scripting to try and make it run "off the rails" (error).

Of course all mine was in python and i had help on the "important" parts so its not much good to you.

But yes i understand what your saying,,what your up against (work wise) and I fully agree and lend moral support to your quest

I bring your attention to this post also http://bygfoot.sourceforge.net/forum/viewtopic.php?t=86

my dear arnaud, you're really as unrelenting as a foxterrier. and you sure don't seem to want to have 1.9 out before 2010.

arnaudus wrote:I know it is an old discussion subject, but now, there are some new developpers who may want to talk about it.

who? developers? did i miss anyone?

The main idea is to split the game into two parts : a "server", and one or several "clients". Note that lots of network softwares, and especially games, are organized in this way. My main model is "freeciv" (www.freeciv.org).

you won't believe it, but you're beginning to persuade me. have a look at this library. this is what i'm going to use, i think.

The server knows how to play. Clients are just interfaces between the human and/or artificial players and the server.

the way i see it:

• the server generates the teams and fixtures; updates fixtures and tables; generates the transfer list; calculates match outcomes
• the client handles stadium affairs, user preferences and transfer offers (this has to be communicated to the server, of course)

.

* some clients can be not interfaces, but rather small programs, or scripts, which play AI teams. Then, everybody can develop its own AI player, and then compare the most efficient strategies, etc.

dunno, would have to be quite an intelligent script

* client/server architecture will make the network game very easy

and normal single-player play harder than it is now. besides, i'm quite sure that the first version of server/client architecture couldn't support real live games (where you can make subs etc.), only 'recorded' live games. currently the live game in the 1.9 branch is really live, but it could also get recorded quite easily. the server would send such a recording of the game to the client.

anyway. you've captured my imagination. i'm off studying GNet functions. see you in 2010...

gyözö