Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

AHK Programming Arena suggestions, questions and bug reports


  • Please log in to reply
91 replies to this topic
LiquidGravity
  • Members
  • 156 posts
  • Last active: Oct 11 2014 04:11 PM
  • Joined: 26 Jan 2009
After looking into it I don't think that would be too hard. I'll share what I come up with.

LiquidGravity
  • Members
  • 156 posts
  • Last active: Oct 11 2014 04:11 PM
  • Joined: 26 Jan 2009
Ok made a work-around for the dynamic include problem and have fixed the name issue as well. It involved adding a few placeholder includes some file copy/rename and also passing some variables and restarting the script. Files are Here. I tried to keep the format the same everywhere I could. Hope you guys/gals like and will consider adding it to the official code.

I also fixed a small bug with the display of the totals. The 4 lines in different places of the code for displaying player2's stats have a 1 instead of a 2.

I didn't mess with the who goes first issue but since any script could be loaded as player1 or player2 you could manually run it 10 times and then swap them and run it again 10 times and average. I also didn't get into running the same script against its self as that was very messy.

tidbit
  • Administrators
  • 2709 posts
  • Hates playing Janitor
  • Last active: Jan 15 2016 11:37 PM
  • Joined: 09 Mar 2008
Seeing all these sudden changes/fixes, should I hold off making a bot until a ready/stable version is out?

I also think this topic should have a new title. this could be the improvement/bug/fixes/idea thread.

Then we can also make a competition-only thread (when ready) where players post there bot. As well as keeping stats, scores, competitions, etc. in the first post or 2.

rawr. be very afraid
*poke*
. Populate the AutoHotkey city. Pointless but somewhat fun. .


lagomorph
  • Members
  • 403 posts
  • Last active: May 15 2014 03:41 PM
  • Joined: 02 Apr 2010
Wow! So much excellent stuff here! Great thing to come home to on a Saturday night ^_^

Liquid, very happy to see you on board and contributing ideas and code!

I'm about to go to bed after a long day, but you can expect responses and updates from me very soon regarding the recent activity here.

And tidbit, the changes being discussed (who goes first, and how to most easily select/include player scripts) will not affect the coding of player scripts, so feel free to build your bot now!

IsNull
  • Moderators
  • 990 posts
  • Last active: May 15 2014 11:56 AM
  • Joined: 10 May 2007
I like the idea really :)

I offer to rewrite the Client- Game Server interface, to have the client and the game server really splitted up.

As far as I can see, endless Loops (or simply to long bot execution time) is not controlled by the game server?

So it would make sense to have a IPC Interface with WM_MESSAGES to allow better controlling? This way, also the text file could be omitted and cheating would be hard.

LiquidGravity
  • Members
  • 156 posts
  • Last active: Oct 11 2014 04:11 PM
  • Joined: 26 Jan 2009
It would be a cool improvement but at this point I'm not sure there would be any real advantage to that. Cheating could easily be caught by looking through the code.

A bug/feature I noticed missing is a decrease in class counts after a unit dies. For example in the Morpha and Lagos scripts it checks if there are more then 5 workers and makes an attacker. If a worker dies that number should decrease and the next unit should be a worker correct?

MasterFocus
  • Moderators
  • 4323 posts
  • Last active: Jan 28 2016 01:38 AM
  • Joined: 08 Apr 2009
As I may have already stated to lagomorph, I'll have a lot of tests (and another show!) this month so I won't be able to help by now, but I'm working on my own AI. :)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Antonio França -- git.io -- github.com -- ahk4.net -- sites.google.com -- ahkscript.org

Member of the AHK community since 08/Apr/2009. Moderator since mid-2012.


lagomorph
  • Members
  • 403 posts
  • Last active: May 15 2014 03:41 PM
  • Joined: 02 Apr 2010

Bug:
Player 1 always goes first which may be an advantage or a disadvantage.

This is true. I have implemented a change: At the beginning of each game a random player will be chosen to go first.

does the following variable reset/update after moves/deaths/other?

1_1_1_visible: 0 Whether the unit has been scanned or not

A unit begins the game "invisible (visible = 0). Once it has been scanned by an enemy unit, its stat becomes 1 for the rest of the game. The visible variable updates as soon as it is scanned by an enemy unit.

If you need assistance coding any of these ideas I'll gladly help.

Thank you! Very glad to have you helping!!

lagomorph
  • Members
  • 403 posts
  • Last active: May 15 2014 03:41 PM
  • Joined: 02 Apr 2010

Ok made a work-around for the dynamic include problem and have fixed the name issue as well. It involved adding a few placeholder includes some file copy/rename and also passing some variables and restarting the script. Files are Here. I tried to keep the format the same everywhere I could. Hope you guys/gals like and will consider adding it to the official code.

Wow, great work! I have tested this out and made a couple minor changes - and you no longer need "dummy" scripts along with the game client as I added the *i option to our #include line.

I also fixed a small bug with the display of the totals. The 4 lines in different places of the code for displaying player2's stats have a 1 instead of a 2.

good catch.

lagomorph
  • Members
  • 403 posts
  • Last active: May 15 2014 03:41 PM
  • Joined: 02 Apr 2010

A bug/feature I noticed missing is a decrease in class counts after a unit dies.

good catch, thanks. Fixed.

lagomorph
  • Members
  • 403 posts
  • Last active: May 15 2014 03:41 PM
  • Joined: 02 Apr 2010

I like the idea really :)

Thanks! I hope to see you on the battlefield soon!

I offer to rewrite the Client- Game Server interface, to have the client and the game server really splitted up.

Great! This may be something we have to do down the road depending on how big the game gets. I will definitely keep you in mind as someone to do this for us if this turns out to be something we need.

I also think this topic should have a new title. this could be the improvement/bug/fixes/idea thread.Then we can also make a competition-only thread (when ready) where players post there bot. As well as keeping stats, scores, competitions, etc. in the first post or 2.

Good idea. I'll do this once we get some player script submissions.

lagomorph
  • Members
  • 403 posts
  • Last active: May 15 2014 03:41 PM
  • Joined: 02 Apr 2010
Version 1.1 Released!

Please update your game files!

Game Files

Thanks to LiquidGravity for the new script-loading code and everybody else for their continued suggestions and help!

Version changes:

* The game files required to play have been changed. Place your player’s scripts into the game directory with the following naming convention: player_playername.ahk – For example, if the player’s name is tidbit, his script would be named player_tidbit.ahk. Inside his script, his main function will be called TidbitScript().
* At the beginning of each game a random player is selected to go first.
* Some bug fixes, of course!
* The sample scripts now only build 4 workers before building attackers (down from 6), making the games finish faster.

LiquidGravity
  • Members
  • 156 posts
  • Last active: Oct 11 2014 04:11 PM
  • Joined: 26 Jan 2009
I propose some more slight modifications.

Allow up to 8 stat points to be used when building a unit. Perhaps with a maximum of 4 per function module. The amount of stat points used would directly reduce the resources collected and also directly increase the cooldown count. This would allow for a much larger variety of units. Anything from archers to harvester ants to walls. Currently if you want it to do one thing your severely limited from doing another.

Similarly I also suggest raising the stats of the commander to make it more defensive. Something like 20 (or any multiple of 4 to match the current animations) for the hp function module. This would stop an enemy from being able to kill it so fast.

Another thing I was wondering about is the uniqueness of variables since the player functions are global. Is there a plan for this yet? I noticed too late that the samples used 1 and 2 to distinguish between the two. Should we use a playername_variablename OR playernamevariablename format?

lagomorph
  • Members
  • 403 posts
  • Last active: May 15 2014 03:41 PM
  • Joined: 02 Apr 2010

I propose some more slight modifications.

Allow up to 8 stat points to be used when building a unit.

Similarly I also suggest raising the stats of the commander to make it more defensive.

I would like to see how the current balance of the game works out before making any changes like those you propose, and if I did make changes they would be in much smaller increments (unless something is TOTALLY broken). The 4 module limit was not an arbitrary decision, the development process lasted a while and the number and type of modules went through many revisions before I found a balance and variety I was happy with.

I'm definitely open to tweaking the numbers and mechanics (and expanding them in due time), but I want to see some solid testing first and see what players can do with the current system.

Another thing I was wondering about is the uniqueness of variables since the player functions are global.

If you're worried about your variables conflicting with another players', it certainly would be smart to make your variables unique in some way by prefixing it with your player name. This, however, is not going to be "required." In the samples, I'm not even sure it would make a difference if they used the same variable names or not, I just differentiated them during debugging to limit the number of potential places to look to fix things.

Carcophan
  • Members
  • 1578 posts
  • Last active: Nov 27 2013 06:46 PM
  • Joined: 24 Dec 2008
Idea, though I do not know its 'benifit' so I am just floating it out there...


Is their any intersest in parsing the gatherer harvest time/rate, or the attack v attacker battles?

Imagine a 1 player game, with a set of random nodes and locations etc. When the moch-match starts, start a timer and track the number of moves and turns taken to harvest all available nodes.

Possibly add a 'number of nodes' variable, so you force 8 or 10 or 15 to spawn so you can corolate the number of gatherers, node spawns, total moves, total turns, node size and all that fun stuff.

I imagine the information is only valuable when you compare 2 'similar' maps, to help see if their may be an issue with movement or scanning.

The same can be done for battles, just attacker vs attacker without nodes or gatherers, and parse just the battles themselves too.


I have no reason for this suggestion, but the more data something creates the more you can analyze. Too much data can bog you down though, so I fully admit this is not 'needed'.

Opinions?