Free Allegiance Forums

Jimen


Sorry, dude, you earned that.

raumvogel wrote:QUOTE (raumvogel @ May 28 2011, 08:49 PM) Sorry, dude, you earned that.

Oh, so FreeAllegiance suddenly decided to trust Imago enough to allow him anywhere near your oh-so-precious code again? I thought he'd been blackballed 4 lyfe after his last troll explosion, but it's good to see that driven and motivated players are still allowed to make a difference even when people don't personally like them.

Out of the hundreds of commits to your precious code I've made, not one of them causes any trust issue. Jimen you have 0 commits. now gtfo out of my topic or get on it.

Sure thing! Just teach me C++, DirectX, and whatever other system APIs that Alleg uses! Anything that needs to be compiled before it can be run is way outside of my area of expertise, but I'll gladly learn it from you!

I feel like advocating the traditional AI approach.
Can I suggest that the first step is to setup event monitoring of games (similar to the efforts of datamine, but not as detailed), record the commands the commanders of the teams issue (both orders to drones and 'insert to accept' orders to players/groups and chat the comms type), also record what types of objects were where when the order was issued and what investments were present the "state" of the game. Similar story for investment when the comm makes an investment record the "state" of the game.

Leave the logging running and eventually you will build a sizeable dataset of {[commander output],[game state]} pairs.
The [commander output] being order issued, chat emitted (and on what channel), tech investment action, money request approval, boot performed.
The [game state] information would be a list of game objects and their status (what ships, drones, probes, bases (for both teams) were where (their types identified by their ID number in the core currently in use), how much health, ammo etc they have, How much he3 rocks have, what sectors what tech rocks are in, how many normal rocks are in each sector and their distance to different alephs (this is more efficiently stored as storing the initial locations of all rocks and recording if they are still present).

You then have a dataset to train your AI (think how you would train a neural net with training data) with.
It should be possible for it to recognise patterns like 'command -go to- [bios bomber ship ID]' is often issued when a friendly ship with [bios bomber ship id] is in the same sector as the base it launched from, and it should be possible to temporally associate [commander output]s - the previous commander output ('command -go to- [bios bomber ship ID]') is often emitted by players in close temporal proximity to 'chat to -team- "need nans [sector name [ship with bios bomber ship ID] is in]'.
I.e. the AI would learn to ask for nans on the chat (and issue commands) when there is a ship with a certain type ID (a bomber) present.
Since the outcomes of the game are known you can have the AI prefer to emit [commander output]s which were emitted in similar situations ([game state]s) by commanders who won that game, and avoid ones done by ones who lost.

For more fun and games, keep a running log of the last N actions of each player and save it with the game state state when the commander emits the [boot player] output (i.e. save what the player did shortly before they were booted), have the AI boot players which perform similar actions.

Jimen wrote:QUOTE (Jimen @ May 28 2011, 10:53 PM) Sure thing! Just teach me C++, DirectX, and whatever other system APIs that Alleg uses! Anything that needs to be compiled before it can be run is way outside of my area of expertise, but I'll gladly learn it from you!

Start here: http://www.cplusplus.com/doc/tutorial/ Ask where to go next when you're finished (bonus marks if you can figure it out your self).

oh again the 'commander AI' topic, we got one every year...

It's already coded since 1999, it was never released to the public but it's part of the original MSR sources. tip: genus Sus.

Now have fun with your vaporware topic but those who have TIME and SKILL to do that (I see none in here) should really focus on something else like replacing ASGS or making a "script based training mission system." These will help the game more.

But I can understand that this topic can arouse the younger ones.

Well, the problem that brought this up is the long downtime between games, and not being able to get equal comms, correct?

"shut the $#@! up and play" doesn't work when nobody wants to comm, nobody can pull a team, or someone hostages/goes afk.
Neither does it help to only have the choices of being a 'stacker', joining a team that will clearly be no fun at all to play for, or sitting in noat for an hour.


Is there no other option to keep the ball rolling that doesn't involve some convoluted AI that will take months to program? There's just too many variables, and core changes may make the AI suddenly do things stupidly.

DonKarnage wrote:QUOTE (DonKarnage @ May 31 2011, 01:38 PM) Is there no other option to keep the ball rolling that doesn't involve some convoluted AI that will take months to program? There's just too many variables, and core changes may make the AI suddenly do things stupidly.

There is other options. it's called having a better CC team (taunt intended).

We have downtime between games because people want to play 'conquest type' games and not DM or CTF type.

Fine but to do so, they need a comm for each side and experienced & balanced comms preferably or game will sux or be stacked.

The solution is not to AI the comms. It's to change the core so the commander role is less important.
Current cores are all based on original Alleg core which relies too much on the commander (think of a slider between 'pure DM' and 'pure 1vs1 RTS' game, current cores are much closer to the right side).

You can keep current cores for SGs but for pickup games (and to help newbies), a simpler core which requires 'dumber' comms is what this game needs badly. A core where miners cost 0 for instance and take 10s to build. A core where money can come from stations (like giga spec mines). There are tons of ideas here, most of them already discussed for 10 years.

There is no coding involved, just 'coring'. so a lot more people around here can help with this.
Eventually we can also change some code to enhance miners AI or adding new ways of getting cash (each kill giving some money for instance): this is much simpler and faster to code than a complex comm AI.

so IMHO the answer is: lot of core changes + few code changes rather than a 'huge comm AI monster thing'.

a 'simple core', newby friendly, fast and fun to play (yeah i don't have time to wait 20 mins to play a 2 hours whore fest game, sorry). Something between a 'dumb' DM game and a full featured 'conquest' game. something that emphasis more what we like in Alleg and throw everything else.

But you need to let go of the 'original core' legacy and rethink every from scratch.

and that's the "6x1 initiative" i'm working on.

What if development off gave all tech maxxed, to be played in a bigger than usual map. So the commander only needs to mine to spam cons and caps.

It could be played with higher money settings or starting miners to offset the cheese.