Advanced Team Features (mostly done)

[joda.bot]

hi

I have spend the weekend finishing my port of my old team code.
It is now ported to the current 2.8.0 cvs state.
The features:

• Display current Team and Next Team in Team Selection Menu
• Player settable Teamname either set a custom teamname (with menu) , let the server assign a color teamname or the default teamname.
  Note: Requires protocol addition
• Removed Teamname voting (oldest player sets teamname)
• Rewrote probalistic team balancing to determistic:
  1) Adjust Teams to min_team, max_team values
  2) Adjust number of players per team (team_min_players, team_max_players)
  3) If there are not enough players spread them equally among as many teams as possible (until min_team is reached)
• The configuration will be interpreted as strict as possible.
  (currently imbalances are not yet respected)
• Score for team kills can be configured.
  This allows positive or negative scores for both players involved.
  Seems to be broken right now, but should be fixed soon.

  Code: Select all

  # config descriptions / english text might be worse (not sure)
  score_die_help				Amount of points you lose for being killed
  score_kill_help				Amount of points you gain for killing someone
  score_die_teammate_help		Amount of points you get for being killed by a teammate
  score_kill_teammate_help	Amount of points you get for killing a teammate
  
  score_suicide_help			Amount of points you get for stupidly dying
  score_win_help				Amount of points your team gets for winning a round
  score_deathzone_help		Amount of points you get for hitting the Death Zone
  # additional text messages
  player_win_teamfrag			\1 core dumped it's own TEAM MATE \3 for \2 points.\n
  player_punish_teamfrag		\1 lost \2 points as punishment for killing it's TEAM MATE \3 !\n
  player_win_teamfrag_ai		\1 got \2 points for core dumping a TEAM MATE AI player.\n
  player_punish_teamfrag_ai	\1 lost \2 points for core dumping a TEAM MATE AI player.\n
  player_lose_teamfrag		\1 lost \2 points since it was killed by it's own TEAM MATE.\n
  player_luckyloser_teamfrag	\1 gained \2 points since it was killed by it's own TEAM MATE.\n
  
  

Todo:

• Add deterministic bot balancing
• Should single player bots be balanced like players ?
  e.g. Each bot has it's own player-joinable team and the team
  will be strictly configured. This would improve bot teams, but might prevent dynamically adjusting the AI for single.
• Remove STL code blocks ??!?!
• What happens if teams_max=2 team_max_players=2, but the 5th player joined the server. Proposal: Add a feature for tournament "mode"
  by having more than 2 teams on the server but just setting two teams to alive. (Should be possible?)

I found a typo bug in the current 2.8.0_beta2 ... I've already reported it to tank.
My code uses STL is this ok ? I tried to use tList/tArray but I could not sort the list then.

Tried to make it short ... but it was long winded again .

joda.bot

[Tank Program]

Sounds cool, I'm sure z-man will be interested when he gets back. (Has he already left?)

[Z-Man]

My code uses STL is this ok ?

Sure. A lot of my code uses it now, too. tList is quite special purpose anyway since it is invasive, and I'm thinking about deriving tString from std::string. Mmm, that may also be the perfect moment to switch to unicode internally.
The protocol change is just the client sending additional information to the server that will get ignored by older servers, right? Then it's no problem.

[joda.bot]

z-man wrote:

Sure. A lot of my code uses it now, too. tList is quite special purpose anyway since it is invasive, and I'm thinking about deriving tString from std::string. Mmm, that may also be the perfect moment to switch to unicode internally.

Cool, then I will try to finish my TODOs.

z-man wrote:

The protocol change is just the client sending additional information to the server that will get ignored by older servers, right? Then it's no problem.

Yes, it adds the teamname field to the ePlayerNetID, and transmits it, which is optionally parsed by the clients. To allow older clients to change the teamname they can just say "/team .bot clan" to change their teamname to ".bot clan".

Some questions:

1. Which requirements must be met for the team features to be added the cvs?
   Otherwise I'd have to merge my changes again from time to time.
2. Is there list of all tasks currently being worked on?
   I guess there might be some other ppl working on the same files
   or code places, for example if philippeqc works on team spawn points?
3. I'd like to display the player's current and next team in the team selection menu, is there a simple way to put those lines there ?
   My current solution is to use menu entries that can not be edited.
4. How to check if my changes break important gameplay features?
   e.g. I'd break some admins team settings configuration, but I never
   thought of this case (and removed it).
5. Should permantly added AIs be handled like usual players ?
   AFAIK num_ais adds a permanent amount of AI players.

Also the single player autobalancing shouldn't be a big problem, I'll just have to add the new bots to the AI team before removing the old ones (if any).
Would it be possible to just change the bot name and it's logic ?
Idea: "Latex changed it's name to Excel and is easier to kill now."

[joda.bot]

I read up a lot of the forums concerning python and scripting after talking to philippeqc (thx for answering all my questions, philippe ).

@Z-man: About the python bindings:
a) Should I try to combine the player//bot spawning and balancing in one space ?
Method Proposal:

• RoundInit: calling BalanceTeams, SpawnPlayers
• BalanceTeams: Determines the team layout (for bots and players alike)
• SpawnPlayes: Spawns players and bots if neccessary change botAIs (Single Player), add missing BalanceWithAI Bots

b) Should I only improve the logic without changing it's structure ?

Has anyone thought about which parts of the server shall be scripted?

Perhaps a team feature survey would be good ?

[Z-Man]

Some questions:
[*] Which requirements must be met for the team features to be added the cvs?

It needs to work. And it must not turn a well designed system into one huge cluster of hacks. A hack here and there is fine; I occasionally feel the urge to refactor and after I'm done, not much visible similarity to the original code is left (Lucifer was the main victim of that, I guess).

Is there list of all tasks currently being worked on?

We have the trackers on SourceForge, and some developers have their todo list in CVS. The overall picture is that right now, we're bugfixing for the final 0.2.8 release and not much implementation work is going on.

I guess there might be some other ppl working on the same files
or code places, for example if philippeqc works on team spawn points?

So far, CVS has handled such cases without problems. As long as you're not working on exactly the same functions, it merges quite well.

I'd like to display the player's current and next team in the team selection menu, is there a simple way to put those lines there ?
My current solution is to use menu entries that can not be edited.

If the stuff is to be displayed on top, that's an acceptable solution. You can also display that information below; copy the code of ArmageTron_color_menuitem or ArmageTron_color_menuitem from gMenus.cpp for that. I actually forgot what the uMenu::RequestSpaceBelow() and the SpaceRight() virtual in uMenuItem do exactly.

How to check if my changes break important gameplay features?

The short answer is: you don't. Of course you're supposed to run some basic tests, but you're not supposed to think about all possible uses. Once scripting is there, we may have a set of unit tests to run (and you'll be encouraged to write new tests), but right now, we have to rely on the continuous testers (mostly the other developers and some daring users running current CVS) to notice it.

e.g. I'd break some admins team settings configuration, but I never
thought of this case (and removed it).

I would not worry about that. Most servers use the more or less standard "Single player against three AIs, but no AIs as soon as a second player joins" setup. The others can adapt.

Should permantly added AIs be handled like usual players ?
AFAIK num_ais adds a permanent amount of AI players.

I'm not sure about that. num_ais is mostly designed for the single player mode; the AIs added by it get their IQ from the current IQ setting and are all in one team so that their scores don't get lost as they join and leave due to the auto adjustments. If you find a better way to make the single player mode work, that's fine too. What exactly do you mean by "handled like usual players""?

Also the single player autobalancing shouldn't be a big problem, I'll just have to add the new bots to the AI team before removing the old ones (if any).
Would it be possible to just change the bot name and it's logic ?
Idea: "Latex changed it's name to Excel and is easier to kill now."

Yes, that would be possible; you just need to change it's character. It's a pointer to the personality data structure, and they are always loaded into memory. However, I think I would not like it. It's really more like one bot leaves and another one enters, just imagine we let the bots use custom taunt chat lines.

a) Should I try to combine the player//bot spawning and balancing in one space ?

The proposal sounds solid, so yes. At least the calls to the functions that do the real work should be close together. The actual work and function definitions can be separate (and I think they should here, on account of the spawning code not needing to know who is a bot).

b) Should I only improve the logic without changing it's structure ?

What suits you better. If you also do the work of improving the structure, I won't object. But know that gGame.cpp is one of my hot candidates for a complete makeover anyway, so whatever you do on a small scale with the spawning code will probably be reworked and not recognizable afterwards.

Has anyone thought about which parts of the server shall be scripted?

Certainly the game rules logic: when rounds end, when matches end, scorekeeping and spawning. Those are the areas that don't get executed often, and where more flexibility would benefit us most. Note that "scripted" does not mean there is no fallback C++ code for it, it just means that it is overridable by a script.

Perhaps a team feature survey would be good ?

If that's "Ask around whether it's wanteded before implementing it", that may be a good idea.

[joda.bot]

I occasionally feel the urge to refactor and after I'm done, not much visible similarity to the original code is left (Lucifer was the main victim of that, I guess).

Cool, I guess a bit of refactoring won't hurt
Did anyone design/plan a desireable structure ? Probably not - just asking if anyone did

I'm not sure about that. num_ais is mostly designed for the single player mode; the AIs added by it get their IQ from the current IQ setting and are all in one team so that their scores don't get lost as they join and leave due to the auto adjustments. If you find a better way to make the single player mode work, that's fine too. What exactly do you mean by "handled like usual players""?

AIs currently have their own team class implementation, but can be added to normal eTeams to balance them, I though about removing the duplicate AI team implementation, not sure how complicated that is. Afterwards there would be no difference between most bots and human players,
except that bots will be removed if neccessary, to make room for players.

Idea: "Latex changed it's name to Excel and is easier to kill now."

Yes, that would be possible; you just need to change it's character. It's a pointer to the personality data structure, and they are always loaded into memory. However, I think I would not like it. It's really more like one bot leaves and another one enters, just imagine we let the bots use custom taunt chat lines.

ok, the one arguments in favor of my idea is, that it would work well
with the kill based scoring system, as the number of kills won't be reset.
The AI just adopts it's skill and to indicate that, it also changes it's name.
That's the way a good player would do it, to help a beginner to learn.
The other way would be to copy the bots score (only if it is an auto_ai).

Spawn and Balance should go into which file ?
keep spawn in gGame and balance in eTeam ?

If that's "Ask around whether it's wanteded before implementing it", that may be a good idea.

I guess it's rather what they want...I tried to PM some ppl and posted on the new clan site, to get some feed back or ideas I did not consider. Clans will have a use for this code, and I used it a year ago for our own clanwars.

good night, no code done today just talked and learned from you all

[Lucifer]

Here's what I've been thinking for script support.

in-game scripting:
You have an event system. You also have a regular update method for each object. The event system passes things like "player dead", "object dead", "new object" and so forth. Other things like certain time intervals, round start, round end, match start, match end. Each game object would then register what events its interested in receiving, and each timestep should see each object doing some/all of its own event-pumping.

Each game object would be called with a certain API from the game itself, during its loop or during other event processing. You would have to override those calls to provide the features and stuff you're providing in your object. But you can have your own helper methods, and importantly, since each game object should be able to iterate through the list of all other game objects, you can provide your own API for other objects of your making to use. So if you write a new AI team object, you can have team members pass each other information or commands through your own API.

This leads logically to a master game object that controls a certain amount of game logic. It would also receive events and have a regular update just like the others, but it would have certain special traits. For example, it can only be created once, there can be no additional instances of it (like a cycle object can have as many additional instances). The default version of this object will be the C++ one we already have that handles round/match logic.

gui:
The entire GUI should be scripted. In my not-so-humble opinion, the GUI should be written in python completely with not necessarily even a default C++ implementation.

file access:
All file access should be scripted through callbacks. The C++ implementation should be used when no scripted callback functions are made, and should be available as a DB2-compliant api. And all calls to this API need to be made like you would use any other db2 api. This allows file objects to be scripted that provide access to specific databases. Maybe I'm on crack on this one, but the fundamental point here is that file access should be scripted to allow server admins to store stats in an arbitrary location and file format, to allow logging to any arbitrary location and file format, and so forth.

animation:
Animation should be scripted too. This isn't that hard, but it's the most controversial suggestion I've made along these lines, since animation is performance-intensive. All the standard objects should be implemented in C++ with no scripting used for animation, but the system should be available to 3rd-party extenders so they can easily animate their creations. Otherwise we have to second-guess how many different ways a person will want to animate their models.

I think that covers most of it, at least. I can write up a big fancy formal document, is that really needed? (It might be weeks/months before I find time to write it)

[joda.bot]

Here's what I've been thinking for script support.

in-game scripting:
You have an event system. You also have a regular update method for each object. The event system passes things like "player dead", "object dead", "new object" [..] time intervals, round start, round end, match start, match end. Each game object would then register what events its interested in receiving, and each timestep should see each object doing some/all of its own event-pumping.

Each game object would be called with a certain API from the game itself, during its loop or during other event processing.

I have seen and used EventQueues in Java, and they - well - tend to bloat the code.
My idea is to use KISS (Keep It Simple, Stupid) and provide access to the basic game entities (player, team), but only allow scripts to modify them, at hardcoded times. But this will perhaps be impossible once you try to go for something like capture the flag, where you need to check at which time a player picked up or captured a flag. Hardcoded times could be round start, player death, zone, round end.

Which game concepts require scripting ?

• maze would require a abstracted zone concept, but that should be enough.
• capture the flag should be possible to implement with zones too
  (with the restriction that the player who enters the own teams zone get the flag and if the player is killed the flag zone for that team returns).

Are there players interested in playing this ?

gui:
The entire GUI should be scripted.

Ok,now, I am sure you want a python port
Can't think of a feature requiring a scripted GUI.
But a mouse steerable GUI might be good.

file access:
All file access should be scripted through callbacks. [...] Maybe I'm on crack on this one, but the fundamental point here is that file access should be scripted to allow server admins to store stats in an arbitrary location and file format, to allow logging to any arbitrary location and file format, and so forth.

This is abit too arbitrary for my taste, I used to go for these kind of ideas and I can tell you it usually is not worth the trouble.
Essential features (IMHO):

• database support (optional)
  scores and if required logs (but logs are fine as text usually)
• gobal database (optional, authentification)

Maps, models and all the other stuff, should be cached and perhaps uploaded to the server.
Server accepting model uploads has to store // recognize models but that can be done using MD5 and files.
I assume a database would just complicate this.

animation:
Animation should be scripted too. This isn't that hard, but it's the most controversial suggestion I've made along these lines, since animation is performance-intensive. All the standard objects should be implemented in C++ with no scripting used for animation, but the system should be available to 3rd-party extenders so they can easily animate their creations. Otherwise we have to second-guess how many different ways a person will want to animate their models.

Well, I think this is a solution and meets quite some needs.
(Animators don't want to code C++).
I bet there are quite some C++ Animation APIs out there,
perhaps it's possible to use something like that.
I'd prefer a client without scripting. With or without scripting
the types of animation should be limited.
(e.g. only constant number of animation states, perhaps paths)
Has anyone looked into this and found out how other games do it?
GL Tron perhaps ?

I think that covers most of it, at least. I can write up a big fancy formal document, is that really needed? (It might be weeks/months before I find time to write it)

No need for a fancy formal document...
Lucifer, you are in love with Python
I don't think ArmagetronAd should script more than needed to get some flexibility for example for game modes or perhaps animation.

[Lucifer]

I am in love with Python, no disagreement there.

I've considered other options, the advantages to the event queue outweigh the disadvantages. The only disadvantage is bloat, but we don't need a full-featured wx-style event queue, either. Without an event queue, every game object has to poll and check for states. This will not only make game objects more complicated to write (and at the expense of doing this checking in the scripted language, compared to event polling in C++), but it also makes them not just difficult to debug but performance-intensive. Needlessly performance-intensive. (Yeah, I know, event queues are notorious for being slow, but they can be fast, especially when stripped to basics)

We need a way for scripted objects to be notified of things that happen on the grid. Callbacks in place of event queues would work. Since a callback interface is at the heart of an event queue, I don't see a difference between the two, except that event passing is easier for me to visualize.

Game concepts that require scripting:
Tournaments
Kick players who have been logged in to a loaded server for too long (to give other players a chance at it, and there is disagreement on this, but personally I'd just as soon do it, and I'll probably lose players when I do, but I really want everyone to have a reasonable chance at playing, and "I was here first" strikes me as sooo...kindergartner).
Changing game rules at various arbitrary intervals (such as to have an olympic-style server)
Kill players that suck. More specifically, a death-match where each round you prevent from spawning the lowest-scored player, with each round incrementing the number of players left out until there's only two left to fight the last round. Then take the winner of this round as the match winner, regardless of score.
Custom victory conditions.
Custom score conditions (pass an event "high speed exceeded", in your callback give that player a point, or whatever)
Integrating with other software, such as having a web server to control the tournament.

The advantage to a scripted GUI is to ease development, but also to allow third-parties to extend the GUI. Using a scripting language for that means their extensions are cross-platform, so they're not required to test their extensions all over the place (where if we used loadable C++ modules, they'd have the same testing headaches we already have). What kind of additions might a third party want to add?

View website for server
View high score list for server (served from a webserver)
Player links
Player browser (based on information stored on a webserver)
Game network (show other games on a given network, such as freeciv games or whatever)
MP3 player

For file access, while the options can be boiled down to a few basics that server admins can use and build on, it would really rock if we could extend it from there. Custom ladder sorting (that falls outside the range available in config items), even custom ladder creation. Ladder syndication (the only realtime way to handle it is to push to syndicates directly from the game server). Player score logs (for clan sites and other things). Also, a server admin who has none of the databases we may support by default could modify his system to use any other database simply. Perhaps he wants LDAP integration in the authentication system, maybe he's got Oracle and 3000 players but we only support MySQL.

The way I understand it, most (read: all until proven otherwise) modern commercial games use a scripting language for animation. There's a page on the pygame website where one of the DnD games used python specifically to script animations. I've heard that NWN uses python, but don't know it for a fact. Whether they use python or not, they *are* using a scripting language of some sort, usually an in-house proprietary language.

I'm certainly not opposed to keeping the default installation free from animation scripts, but I'm also opposed to trying to keep the scripting language out of the default installation. Strip it down if you need it, but there will be far too many advantages to having it to make it worth trying too hard to keep it out of an installation.

[joda.bot]

The *updated* features:

• Display current Team and Next Team in Team Selection Menu
  Allows immdeatly rejoining your current team
  Allows joining the empty team ? (Security Issue ?)
• Player settable Teamname either set a custom teamname (with menu) , let the server assign a color teamname or the default teamname.
  Note: Requires protocol addition
• Removed Teamname voting (oldest player sets teamname)
• Rewrote probalistic team balancing to determistic.
• Added Message to saying "PlayerA wants to join TeamB for next round"
• The configuration will be interpreted as strict as possible.
  (currently imbalances are not yet respected)
• Score for team kills can be configured.
  This allows positive or negative scores for team death/kill. Working.
• Removed "static bool reduction" in ePlayer... now works without
  this construct.

Todo:

• Add deterministic bot balancing
• AutoAI: Either swap bots or change their AI / name.
• What happens if teams_max=2 team_max_players=2, but the 5th player joined the server. Proposal: Add a feature for tournament "mode"
  by having more than 2 teams on the server but just setting two teams to alive.

[philippeqc]

Have you had the chance to check the Spawn document? I'd like your input on that (apart that it is badly written), as it would be a good way to enable ownership for different game features.

Todo:

• What happens if teams_max=2 team_max_players=2, but the 5th player joined the server. Proposal: Add a feature for tournament "mode"
  by having more than 2 teams on the server but just setting two teams to alive.

This feels like some sort of tournament rules, in the context that tournament define who gets to play at any round and what constitute a "win", not just as a competition by elimination. We had a previous discussion about this. IIRC, it boils down to:
- Tournament rules are many,
- Which ever we implement, someone will request a new one, or different capacity on an existing one,
- Tournament decision are not in anyway performance critical,
- Implementation in the engine always come at a higher cost than through scripting.

The conclusion was:
Tournament logic is better served through scripts, except for a few ones already in the code.

I'm sorry to come like this and cut the grass under your feet, you really seem on a roll about all things team related, but implementing one more tournament rules would raise the complexity of an already way too complex bit of the program for nothing.

To keep on your roll, I'd suggest the following:
- Invent as many ideas of tournament as you can. Keep even the ones that you think are lame, boring or idiotic. Somebody else might not think they are.
- Once you have a big pool, try to generalise a bit,
- Identify the emerging factors,
- For each factor, try to find which are the possible values.

Once you have all your factors defined, try to describe each of ideas you made in the first step. If you hit some ideas that cant be described properly, maybe you need to go back, find new crazy ideas of tournament, and repeat the process.

Once this work is done, it will be extremely easy to identify the hook ups that are required for script to fully support nearly any idea of tournament.

Running this method on pizzas you could have:
No matter how many pizzas we put on our menu, someone could always come and request a new one.

idea part
- I want something hawain and cheezy tasting ,
- I want peperroni and stuff. I dont care much about stuff, but garlic on the bread could be good,
- I'm vegetarian, so I dont want any meat. A pizza should be really filling,

Generalisation
they all seem to talk about different toping, so that should be generalised. There are already some type of crusts: thin italian, pan pizza, american could be something in the middle. Maybe the filling aspect of the vegetarian could be interpreted as a pan pizza.

Factors:
- base crust: 3 choices: italian, american and pan
- rim filling: none, cheese.
- rim toping: none, garlic butter, cheese, oliv oil
- main topping: This should allow combinaison of regular food ingredients. The order specify how they are placed on the center of the crust: tomato sauce, cheese, peperoni, ham, pineapple, curry, pepper, mix vegetables.

Applying the factors to each idea is left to the reader.

Now with such a model, when someone come and should "no a pizza should also serve as a breakfast meal. My mom always made me bacon and egg and a peanut butter and jelly sandwich, so I want that, and I want the pb&j to be in the bread", then you can add 2 new topping ingredients, bacon and egg, and say "look I dont know what a pb&j sandwich would mean for a pizza, but i have this rim filling capacity, so we could make it a pb&j filling.".

Once your model is able to take in ideas that sound totally crazy, then chances are that you are onto something good.

-ph

sorry for the quite drifty post.

[joda.bot]

Have you had the chance to check the Spawn document? I'd like your input on that (apart that it is badly written), as it would be a good way to enable ownership for different game features.

I will check that ... (guess I missed it , if someone mentioned it).

Todo:

• What happens if teams_max=2 team_max_players=2, but the 5th player joined the server. Proposal: Add a feature for tournament "mode"
  by having more than 2 teams on the server but just setting two teams to alive.

This feels like some sort of tournament rules, in the context that tournament define who gets to play at any round and what constitute a "win", not just as a competition by elimination. We had a previous discussion about this. IIRC, it boils down to:
- Tournament rules are many,
- Which ever we implement, someone will request a new one, or different capacity on an existing one,
- Tournament decision are not in anyway performance critical,
- Implementation in the engine always come at a higher cost than through scripting.

right on all accounts, my intentions are two fold:

1. I want to experiment with it, and identify code parts that might need refactoring
2. Implementing the team balancing in a strict, deterministic way forced
   me to think about the problem. For example the server has a config like:

   Code: Select all

   max_clients 10
   team_max_players 2
   teams_max 2
   
   => team_max_players*teams_max = 4
   

   Question: What happens with the 6 players that can not be put into a team ?
   Idee: add them to "no team"(=null) or add them to teams that are not spawned.

The conclusion was:
Tournament logic is better served through scripts, except for a few ones already in the code.

Like the new Fortress mode ? (just teasing you)...

I'm sorry to come like this and cut the grass under your feet, you really seem on a roll about all things team related, but implementing one more tournament rules would raise the complexity of an already way too complex bit of the program for nothing.

Thanks for pointing out alll those problems . My initial intention was to
fix team balancing issues, I might have drifted off, but I still think
that providing the kind of "tournament mode" is a good test bed
(at least for experiments).

To keep on your roll, I'd suggest the following:
- Invent as many ideas of tournament as you can. Keep even the ones that you think are lame, boring or idiotic. Somebody else might not think they are.
- Once you have a big pool, try to generalise a bit,
- Identify the emerging factors,
- For each factor, try to find which are the possible values.

Once you have all your factors defined, try to describe each of ideas you made in the first step. If you hit some ideas that cant be described properly, maybe you need to go back, find new crazy ideas of tournament, and repeat the process.

Once this work is done, it will be extremely easy to identify the hook ups that are required for script to fully support nearly any idea of tournament.

Yes, thinking about all those (im)possible uses / game modes is required.
But I'd rather limited it to those that can be done without implementing a supernatural, arbitrary, fantastic and turing complete game engine and everybody just uses a very small feature set (for example current gameplay).

I like the idea of scripting, but I still prefer it to be an optional thing.
Scripting requires most game entities to be editable is a easy, comfortable way.
=> refactoring to get compact player/team/cycle objects
which are "only" manipulated/used by other classes/methods (IMHO)
The result is a strict hierachy and better to understand.
=> Events or game methods operate on the objects
instead of objects operating on themselves or siblings.

Once your model is able to take in ideas that sound totally crazy, then chances are that you are onto something good.

-ph

sorry for the quite drifty post.

No problem with the drift, I like pizza
I already started some inquires for team based stuff... I guess your approach is better. You get many, many ideas which are then abstracted or discarded (if too complicated).

Link:
Post on Armagetron Competitor's Club: Forums

Links:

• MicroBusCity Forums
• MicroBusCity Idea Poll (new)
• AramgetronAd Idea Poll (new)

TODO:
Add deterministic max_imbalance feature (perhaps someone else uses that) .

[joda.bot]

Current Snapshot ... This is a unified diff created with eclipse against the b0_2_8 branch.

I still have to finish the code for the bot balancing etc.
But you can test the new team joining menu... I really prefer it to the current version.

Any comments ?
I'm willing to create partial patches too, if you just want to the new code which removes "static bool recursion barrier" in ePlayer.cpp (for example).

ok, going to town now ... it's Honkey Tonk in Paderborn, so cheers
EDIT: forgot the attachment *doh*

[joda.bot]

Code upgraded to latest CVS (except if Z-Man coded fixes today).

Found another nasty bug, but it only happens with my changes to the code.

It somehow depends on my new team menu ... as it only will crash IF I enter the team menu and join NO team at all.

And it will crash only after I enter the menu a second time...

msvcr71d.dll!_CxxThrowException(void * pExceptionObject=0x0012f488, const _s__ThrowInfo * pThrowInfo=0x00580304) + 0x39 C++
armagetronad_debug.exe!st_PresentError(const char * caption=0x00562374, const char * message=0x016da028) Line 94 C++
armagetronad_debug.exe!tHeapBase::Remove(tHeapElement * e=0x015222c4) Line 145 + 0xeb C++
armagetronad_debug.exe!tHeap<eWallView>::Remove(eWallView * e=0x015222c4) Line 115 + 0x13 C++
> armagetronad_debug.exe!eWall::~eWall() Line 73 + 0x1f C++
armagetronad_debug.exe!gPlayerWall::~gPlayerWall() Line 575 + 0x2d C++
armagetronad_debug.exe!gPlayerWall::`scalar deleting destructor'() + 0xf C++
armagetronad_debug.exe!tReferencable<eWall>::Release() Line 453 + 0x58 C++
armagetronad_debug.exe!tControlledPTR<eWall>::Release() Line 190 C++
armagetronad_debug.exe!tControlledPTR<eWall>::~tControlledPTR<eWall>() Line 284 C++
armagetronad_debug.exe!eWallHolder::~eWallHolder() Line 298 + 0xf C++
armagetronad_debug.exe!eHalfEdge::~eHalfEdge() Line 152 + 0x93 C++
armagetronad_debug.exe!eHalfEdge::`scalar deleting destructor'() + 0xf C++
armagetronad_debug.exe!tReferencable<eHalfEdge>::Release() Line 453 + 0x57 C++
armagetronad_debug.exe!referencing::ReleaseReference(eHalfEdge * t=0x016da9d8) Line 56 + 0x147 C++
armagetronad_debug.exe!tReferencer<eHalfEdge>::ReleaseReference(eHalfEdge * t=0x016da9d8) Line 88 + 0x9 C++
armagetronad_debug.exe!tList<eHalfEdge,0,1>::Remove(eHalfEdge * t=0x016da9d8, int & idref=-1) Line 156 + 0x9 C++
armagetronad_debug.exe!eGrid::RemoveEdge(eHalfEdge * e=0x016da9d8) Line 2375 C++
armagetronad_debug.exe!eGrid::Clear() Line 2101 C++
armagetronad_debug.exe!exit_game_grid(eGrid * grid=0x0155f018) Line 1218 C++
armagetronad_debug.exe!exit_game_objects(eGrid * grid=0x0155f018) Line 1241 + 0x9 C++
armagetronad_debug.exe!gGame::~gGame() Line 2530 + 0x17 C++
armagetronad_debug.exe!gGame::`scalar deleting destructor'() + 0xf C++
armagetronad_debug.exe!nNetObject::Release() Line 529 + 0x34 C++
armagetronad_debug.exe!tControlledPTR<gGame>::Release() Line 190 C++
armagetronad_debug.exe!tControlledPTR<gGame>::~tControlledPTR<gGame>() Line 284 C++
armagetronad_debug.exe!$E225() + 0xd C++
msvcr71d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 376 C
msvcr71d.dll!exit(int code=0) Line 303 + 0xd C
armagetronad_debug.exe!main(int argc=1, char * * argv=0x0012fea4) Line 256 C
armagetronad_debug.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrev=0x00000000, char * szCmdLine=0x00133bc7, int sw=1) Line 361 + 0xd C
armagetronad_debug.exe!WinMainCRTStartup() Line 390 + 0x39 C
KERNEL32.DLL!77e98989()

I can generate a new patch... but the side effect is really strange and irritating.

(Build on Windows )
EDIT: Guess it's just a cleanup error and the real error happened earlier.