One thing that comes to my mind right now is that we have to be able to easily split/join groups. I see several situations where transferring only part of a group to the control of a different group AI would be useful.

good call gabba, i never really considered that. though, with the add/remove feature for the group ai that the global ai would have access to, it would be easy for the ai programmer to do that him/herself

Exactly, plus certain units need individual control specifications, such as Nukes, and Berthas. The former, because if it's part of a mobile unit attack command, you're going kill your own units. The latter, because of it's inaccuracy, and the fact that it requires usually multiple batteries firing from different directions to be effective.

What about a group priority? Perhaps one group should have a higher priority than another when they're both dealing witht he same unit, which can happen at times, rather than simply giving total control to a single group.

that can be left to the AI programmer... the group and global AIs will have access to a memory where they can be read and written from. they can do that sort of communication there, but it sounds like that would be a pretty complicated thing to do

Now that I think about it it isnt really needed, just requires a little bit of imagination to make it simple todo.

Hi There,

Wow you guys have been busy. I disappear from TA for a couple o' years and you go all 3D on me - brillant!

On the "Global API", I think you're missing something. Wthout any AI Players (APs), you have this:



I don't know how you've structured the code internally, but the calls from the UI to the game engine must already be there.

The point is that from the game engine's point of view, it doesn't care whether you're a human or an AP, you're just another player. So just use the same player API for the AP as you do for the UI.

Does that mak sense? What do you think?

Munch

that's kind of the idea already... the ui is linked to the game execution through the same types of commands sent over the network. so, the ai player will be sending these commands as well to take control of a player. however, the code base at the moment is set up for access to only one player... so changes need to be made so multiple players can be manipulated by a single machine.

OK cool =)

As an idle thought, has the possibility of splitting the executable been considered? I.e. instead of the UI/GameEngine comms being method calls within a single executable, you could separate it into a game engine executable and a (number of) player executables, which communicate over a network. This is probably a nicety which would be pointless in reality, but it would give you:

A. total independence between the engine and the players (meaning you could have as many different AIs and human players as you liked running off of a single engine)

B. The ability to run your game engine, UI and APs on separate boxes if you wanted (meaning you can have really beefy APs, really beefy game AI, and really whizzy graphics, without them interfering with each other).

I guess in pratice most people (like me) have just the one decent machine at home so it probably wouldn't help much for the effort it would take.

Just a thought.

Cheers

Munch

True, though for net games, having the UI run from the server side would eliminate part of the lag problems. Assuming every one is running on the same speed connection, then having that on server side, it means that everyone's commands are processed there with the rest of the game, rather than being routed there after execution to be relayed back to the opponent. In this manner, there's only two streams going each way. It's not ideal, but it could solve some of the problem.

I don't quite understand what you're saying. Do you mean having just a single game engine running instead of one at each player's machine? - that's a great idea! So, like in OTA you have this:



But you're saying we could do this?



Wow that really would get rid of most lag related probems (assuming they basically come from the different game engines on the different computers having a slightly different idea of what is going on - that's always been my guess).

The only downside I can see is that the player running the engine has zero lag, however they do have the overhead of running the engine on their machine, which is going to slow things up a little anyway. I guess if it became a problem you could always add "fake lag" in for that player (or any others with much lower lag - e.g. who are on the same LAN), but I don't think it would be a problem.

I wish I'd thought of that!

Munch

Right, and if it's a more massive game, say four players, then the game is run on the server connecting them all, and the interfaces are present on each machine, all relaying to the central server.

And don't worry, I think in somewhat different terms than the rest of reality. At least that's what the nice men with the jacket tell me. </JK>[/code]

So, Juoninkomiko, any ideas on when those functions in your global interface will be ready?
Maybe release just the main functions for globalAI to make a basic single AI without the AI communication functions and all the other complicated stuff.
This would give other people something to work with for now,
Ofcourse I know you have lots of other things todo but anyway,
Thanks,
Alik.

I find it appalling that some of you have the notion to develop projects for spring, and yet keep the source closed. Thankfully not everyone has that same mentality, or TA Spring would not even exist.

I find it palling tht you are calling my efforts closed source, I am following in the SY's example exept anyone who asks to be a part can be, but I find you very insulting and condescending, and most of all with great lack of understanding on your behalf.

Afterrall what have you contributed openly?

Anyways the SY's kept it closed source till the release date, as will I.

*what he said*
do the SYs tell you exactly what they are doing with the code? do they give you updates on which parts they are editing?
Please leave alantai alone. If you want to help he needs BOs for the first 2-5 mins for both ARM/CORE utilizing Solars/Wind Gens/Tidals dependant on the level so the AI can follow a simple BO and not stall for at least the first couple of minutes when the AI is finished dibsy extensively testing it! when i have it beat i'm gonna spam posts everywhere like 'woot!!!' and when ppl ask me to do it again i'll just arrogently smirk knowing full well that it fluke! :) mmm AIige

=.

no really read the topic before you post.

Oh min3mat these people havent a clue what point I'm at so dont get their hopes up too much or they'll harass me if I release anything.

Agreed. For the time being Min3mat, just sit on your hands about the AI.

*in that sitting on one's hands, prevents typing*

*unless of course one has a long, pointy nose with which to press keys*

Now really long pointy noses arent that bad unless your names pinochio

You need to relax, mate. My post was not intended as a direct attack against anyone; but rather against a concept that I've seen in a few posts. I just don't see what there is to accomplish by not developing any projects for Spring in a _totally_ opensource fashion (and the arguements I have read are not convincing). Furthermore, if I were to develop something it would definitely be open source.