PBEM vs. the PC

Longshot · Post by **Longshot** » Tue Sep 10, 2002 2:32 am

/me is proud of PH

AI is not my knowledge at all and i guess you know what you 're doing.
And dont forget that if it is not perfect at the first time, it is not a prob

I hope you will succeed in this project (with some help i believe).
I will not tell you what to do, but only one word for all the next versions of the game you will do: diversity. (teams, level of tactics,leagues....).
Good luck and good work .

SkiJunkie · Post by **SkiJunkie** » Tue Sep 10, 2002 3:57 am

Continuing on the board is fine. However you write the dll I am most likely going to have to add a plain C wrapper to it. Java talks to dlls written in C through a process called JNI (Java Native <something>). From my experience with doing other things in C++ I've had to write a C wrapper. Java calls into the c code which would take the java variable types and convert them into whatever your code needed. So the interface you choose isn't a real big issue as I'll have to be writing this wrapper anyway.

Af far as the game state data why don't we start by listing out exactly what your AI will need. Som quick things off the top of my head

-Each player, their stats, their skills, their current status (prone, stunned, etc).

-ball location

-current turn

-igmeoy, get the ref, score, num rerolls left

Add more...

Post by **DoubleSkulls** » Tue Sep 10, 2002 8:34 am

What you are really talking about is a generic BB engine that client apps can plug into to provide a UI and/or comms. That could be really useful to a whole variety of BB apps.

That may actually be the obvious first step. A program that understands the game mechanics (player movement, turns rolling dice etc) and then build an AI module that plugs into it in the same way a client would.

An issue is that any system would have to either support plug & play rulesets or have hard coded implementation of the rules. In the latter case this increases the maintenance burden quite significantly.

As for JNI (java native interface) its got high performance overhead per call, which isn't going to be much of a problem on a client but you'd need to be aware of the design of reducing the number of calls across the JNI boundary.

Ian

SkiJunkie · Post by **SkiJunkie** » Tue Sep 10, 2002 1:26 pm

>That may actually be the obvious first step. A program that
>understands the game mechanics (player movement, turns
>rolling dice etc) and then build an AI module that plugs into it
>in the same way a client would.

Well there are several of these already (unless you mean some sort of business rules module that different UI modules can plug into and use). I'm just waiting for the AI module to plug mine into.

>As for JNI (java native interface) its got high performance
>overhead per call, which isn't going to be much of a problem
>on a client but you'd need to be aware of the design of reducing
>the number of calls across the JNI boundary.

The overhead is there but still measured in miliseconds. Even calling across JNI for every action and every square moved will still be faster than waiting for a human opponent to decide what to do. Besides, if there was no delay you might have to introduce artificial delay just so the players don't zoom around too quickly for the human player to follow.

Pink Horror · Post by **Pink Horror** » Tue Sep 10, 2002 1:44 pm

ianwilliams wrote:An issue is that any system would have to either support plug & play rulesets or have hard coded implementation of the rules. In the latter case this increases the maintenance burden quite significantly.

I think the AI module should be separate from any game module, so I don't think that my system has to be as generic as you're suggesting. For an AI to support possible rulesets unknown to the programmer, I'd have to write a set of functions that analyse rules under the set of functions that analyse the game situation. That's not impossible, but any game rules would have to then be written in machine-interpretable code, and I wouldn't be able to use my own knowledge of the game as fully as I could with hard-coding. I want to rely on the client application as little as possible, so I'm not going to force it to send over any rules. I will probably include, in the future, a means customization based on popular house rules through an INI file, but that's the limit for now. I don't want to get in over my head. I'm going to start small and work from there.

If you want to program a Blood Bowl rules-handling module, go ahead. Then people with graphics talent would only have to be concerned with the graphics.

Pink Horror

Pink Horror · Post by **Pink Horror** » Tue Sep 10, 2002 2:32 pm

SkiJunkie wrote:As far as the game state data why don't we start by listing out exactly what your AI will need.

Here's what I think the AI would need at the beginning of a turn:

A) Game State
_1) Football Location (there should be a value for not placed)
_2) Current Turn (and is it a normal turn, or Blitz, or setting up...)
_3) Ref Flags (IGMEOY, Get the Ref, handicap, etc.)
_4) Score, us & them
_5) Re-rolls, us & them
_6) Weather
_7) 32 bit flag variable to be defined later

B) Players
_1) Stats & Skills
__a. MV/ST/AG/AV/NG
__b. Skill array - numbers represent skills
__c. SPPs (for SPP-based decisions)
_2) Location on Pitch (there should be a value or values for off the board)
_3) Status (prone, stunned, no tackle zone, KO, etc.)
_4) 32 bit flag variable to be defined later

I've got to check to see how much we need to know for the DLL. I think I'll make a test program that loads a mock DLL to see how it'll work.

Pink Horror

Post by **DoubleSkulls** » Tue Sep 10, 2002 3:05 pm

SkiJunkie wrote:The overhead is there but still measured in miliseconds. Even calling across JNI for every action and every square moved will still be faster than waiting for a human opponent to decide what to do. Besides, if there was no delay you might have to introduce artificial delay just so the players don't zoom around too quickly for the human player to follow.

You are right. I was just pointing it out since you don't want to end up in a position where it becomes a problem and you have to re-architect the design when you've nearly finished.

Ian

Guest · Post by **Guest** » Tue Sep 10, 2002 3:48 pm

B) Players
_1) Stats & Skills
__a. MV/ST/AG/AV/NG
__b. Skill array - numbers represent skills
__c. SPPs (for SPP-based decisions)
_2) Location on Pitch (there should be a value or values for off the board)
_3) Status (prone, stunned, no tackle zone, KO, etc.)
_4) 32 bit flag variable to be defined later

_5) team, us/them

Does the AI really need to know about players in the dugout? It's not a problem to include them, but if the AI is just going to ignore reserves, ko, bh, si, and rip why send them over. Or are there other off pitch players that could change the AI I'm not thinking of? I dunno though, maybe they would be useful.

SkiJunkie · Post by **SkiJunkie** » Tue Sep 10, 2002 4:07 pm

Uhh that's me above again. I keep doing that.

Post by **DoubleSkulls** » Tue Sep 10, 2002 4:14 pm

The number of opponents in the dugout certainly effects the way I play the game.

If they've got lots of reserves then its probably less value trying to whittle down the numbers in the long game (i.e. don't bother with strategic fouling).

If there are lots of KO's awaiting to come back I may delay scoring if its at the end of the 1st half.

If I've only got 1 cas and its getting towards the end of the game I may foul just in the hope of getting the +1 for FF roll.

Ian

Pink Horror · Post by **Pink Horror** » Tue Sep 10, 2002 6:52 pm

I don't think players need a team tag. Which team a player is on will be known by the array its stored in. I should have said they're be two player arrays.

As ianwilliams points out, the dugout matters. Some people play differently depending on the dugout situation. Also, what would the computer make its defense setup plans from if it doesn't know who's in the dugout?

I don't want to leave anything out. A lot of information would go unused at first, but changing the variables later could be messy.

By the way, that other flag variable needs to keep track of the apothecaries, head coaches, and wizards. Or, maybe that can be packed into weather. I like being frugal when I can.

Pink Horror

Moonsong · Post by **Moonsong** » Wed Sep 11, 2002 1:09 am

Boys am I excited!

You mean my little, humble post made you decide to REALLY write this long-waited for AI? Well, you're making me the happiest man on earth.
You know, too much spare time, friends always seem to have something else to do (like livin' a real life

), etc. I don't know a bit about programming, but should you need anything, ask me and I'll be more than willing to help.

Moonsong

Pink Horror · Post by **Pink Horror** » Fri Sep 13, 2002 4:20 pm

Moonsong, I must agree that your humble little post helped me get involved in something that I was only wondering about. I've spent the last several days working on the second version of my team analysis spreadsheet, so I haven't started working on the AI yet, but I will soon.

Pink Horror

Guest · Post by **Guest** » Mon Sep 16, 2002 8:49 pm

Hi, I'm part of the TBT (http://toweld.free.fr/towbowltactics/index_en.html) development team. And we would really be glad if we could be part of this AI project.

As all of you know, AI is one of the most difficult issues to come up with when writing a game. And although this is not the main goal of TBT, it would be a great feature to add.

The way you're putting it, we would only have to code an interface so that the AI would plug to the game. So we would be happy if you were willing to share your system with us and let our game use it.

Also, if we can help anyhow for coding the system, just let us know.

Jem ( jem64130@yahoo.fr )

Exer · Post by **Exer** » Fri Sep 20, 2002 4:38 pm

This is good, more people are interested in that AI.

Can't wait to see the results!!

-T