Author Topic: Annikk's Mechanics  (Read 177396 times)

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Annikk's Mechanics
« on: January 15, 2011, 02:49:11 AM »


A series of guides intended to help you install all the different engines into your level.

Free to use, copy and modify.




~



Contents


Thanks to CybeRogue for the banner.
« Last Edit: May 28, 2012, 09:41:38 PM by Eufloria Admin »

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Read this first
« Reply #1 on: January 15, 2011, 02:49:30 AM »
Read this first.

Hello.



I wrote all of the engines in this thread.  This series of guides assumes some very basic knowledge of map-making - I expect for example that you are aware how to make a While GameRunning() do loop, that you are comfortable with creating your own Asteroids in LevelSetup(), etc.  If you are a newcomer to level design please read the Beginner's Guide first and try all the examples there.  That combined with a couple hours of experimentation will bring you up to speed sufficiently to have a go at using some engines.

Attached to each guide you will find three files:
  • The first file is not a level - it's actually just the complete code for the engine, which you just copy and paste to the bottom of your level file, below absolutely everything else.
  • The second file is a simple playable map, the way I imagine your maps might look before you have any engines in them.  Think of it as a "before"...
  • The third file is the "after" version.  This is the exact same map but with the engine in question added.  This is so that you can compare the two to see the differences.

I have furnished each template with some default values, so installing the engine in your level is little more than a simple copy and paste affair, and the level will then load fine and you'll be able to see it doing something, at least.

However, only the Infected AI is intended to be used "as is".  The other engines all have variables that can and should be tweaked in order to get the particular functionality you are looking for.
It would be disappointing and extremely cheesy to see finished maps being released with these default values, especially when I have taken the trouble to explain the comparitively simple ins and outs of modifying them to your own design.
Therefore, if you use any of my engines other than the Infected AI, please ensure you alter the variables in such a way that it looks sufficiently different from the defaults.

I can't force you to do this.  The code is up here, freely available for all, and ultimately you can do what you want with it and there's nothing I or anyone can do to stop you.  However I wanted to make my personal wishes clear in the hope that they will be respected because - from my own experimentation - I know how much is actually possible with the code contained herein, and it would be a tragic waste if that potential was not exploited by the map-making community.

Furthermore, to my mind, tweaking variables is what is so much fun about these engines.  I encourage you to let your imagination go wild, and if you have any questions regarding any aspect of the engines or a query on how to implement a particular behaviour, please ask about it in this thread and I will do my best to respond.

Happy coding. :>


-Annikk.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Infected AI Engine
« Reply #2 on: January 15, 2011, 02:49:46 AM »


Difficulty: Easy
CPU Cost: Medium; intermittent bursts.



1.  Description

  • The Infected AI Engine is a scripted alternative to the normal, ingame AI.  It is designed as an "aggressive expansionist" and will use its seedlings very efficiently.
    It is designed to:
    i) target poorly defended asteroids when attacking
    ii) use large swarms effectively by splitting its attacks across multiple different points
    iii) not become traumatised by extensive damage to its empire
    iv) cope with having its empire split up into parts that cannot reach one another.

    If the AI's empire is reduced to a single asteroid, it will still (if subsequently left unchecked) come back to ultimately take over the entire galaxy and win.

  • The Infected AI engine is the easiest of all the engines to implement, because it doesn't require you to change any variables.  It will just automatically learn about your level and take control of the seedlings/trees/etc that you've added for Empires 2 and up.

  • The AI is equally at home on a static map as it is on a map with moving asteroids or maps where the numbers of asteroids in play changes over time.

  • It will automatically take control of any seedlings or asteroids that you assign to Empires 2 and up, and will cause them to efficiently colonise the galaxy around them, defending themselves if attacked, before ultimately aggressively attacking the player and each other.

  • You only need one copy of the engine to run as many different AI empires as you like.

  • The AI will not control Greys (Empire 0).  So you can still use greys as a passive buffer force to guard valuable asteroids.  The AI will generally avoid trying to colonise these asteroids unless it has a sufficient force to kill them all.

  • The AI knows how to use flowers to get Super Seedlings, but it doesn't know how to plant them on Defence Trees to make laser mines.  Perhaps a future update will introduce this functionality.  However, the AI does respond vigourously if the player attacks with a laser mine,  so feel free to allow the player to build mines in your level, should you deem it appropriate.

  • Finally, for the avoidance of any doubt, commands like "GetAI(2).Cowardice = 0.05" and "GetAI(2).MinExpansionForce = 10" do not affect the Infected AI in any way - so remove them if you don't want the extra clutter.  Those commands are for the default in-game AI, which the Infected AI automatically switches off for you when the engine initialises.



2.  Implementation

  • 1.  Download the file attached to this post called "Infected AI Engine.lua".
  • 2.  Open the file in notepad or whatever text editor you use.
  • 3.  Select all of the code and copy it to your clipboard.
  • 4.  Open your own level and scroll down to the very bottom, and paste the code in.  It is imperative that it appears below everything else - including the "end" from your function LevelLogic().  The code you are pasting is two entirely seperate functions so if you inadvertantly put it inside function LevelLogic() then the map won't work.
  • 5.  At the bottom of your function LevelSetup(), insert this command: AIinit()
  • 6.  In your function LevelLogic(), ensure you have a While GameRunning() do loop (or create one if you don't), then insert the following command anywhere in the loop: InfectedAIEngine()

Now the engine is implemented.  Save your level and try to play it.


That's all that is required to implement Infected AI.
The process for the other engines is exactly the same - the only thing that differs is the name of the functions.



3.  Variables

There are no variables to change in Infected AI.  Once you have completed the above steps, the AI will be in the level.  It will take control of any asteroids and seedlings that you create for Empires 2 and up.
« Last Edit: June 01, 2011, 07:37:12 PM by annikk.exe »

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Gravity/Collision Engine
« Reply #3 on: January 15, 2011, 02:50:02 AM »


Difficulty: Medium
CPU Cost: Low/medium - dependent on number of asteroids



1.  Description

  • The Gravity/Collision Engine allows you to designate certain asteroids (or all asteroids) as having gravitational properties.  It gives asteroids the ability to move around, bump into each other, and orbit each other in a realistic way.  The fact that it is based on real life physics (loosely - antigravity doesn't really exist as far as I know) makes it all the more interesting to play around with - and some surprising behaviours fall out of the equations naturally...

  • You can use this engine to make asteroids orbit each other in complex patterns.  You can make asteroids incredibly bouncy, or so non-bouncy that they stick together the moment they collide.  You can make asteroids that behave like balloons.  You can create asteroids that have antigravity.  There is a LOT you can do with this - it's extremely fun to sit around tweaking the settings to produce unlikely looking trajectories, and experiment with strange anomalies such as black holes.

  • The engine is quite forgiving for mistakes.  If you forget to specify variables for some of your asteroids, the level will still load - but those asteroids will not move or have any gravity.  Other asteroids will still be able to bounce off them, however.



2.  Implementation

  • 1.  Download the file attached to this post called "Gravity Engine.lua".
  • 2.  Open the file in notepad or whatever text editor you use.
  • 3.  Select all of the code and copy it to your clipboard.
  • 4.  Open your own level and scroll down to the very bottom, and paste the code in.  It is imperative that it appears below everything else - including the "end" from your function LevelLogic().  The code you are pasting is two entirely seperate functions so if you inadvertantly put it inside function LevelLogic() then the map won't work.
  • 5.  At the bottom of your function LevelSetup(), insert this command: GravityInit()
  • 6.  In your function LevelLogic(), ensure you have a While GameRunning() do loop (or create one if you don't), then insert the following command anywhere in the loop: GravityEngine()

Now the engine is implemented, but you will need to set some variables before it will do what you want it to do.



3.  Variables

In this engine there are several "global" variables which you only need to set once for the whole engine, and a handful of variables that you need to specify on a per-asteroid basis.
You can find the variables inside the "function GravityInit()" section in the code that you pasted in.  The variables are all initialised here, so this is where you change all the settings.


Global Variables

  • G - the overall force of gravity.  I'd suggest setting this to 1 to begin with.
  • bounce - how bouncy are asteroids?  A perfectly elastic collision (ie the most bouncy any real life object could possibly be) is 1.  I'd suggest trying 1.1 or 1.2 personally.  :>  It stops asteroids from clumping up together.
  • EmergencyBrakeThreshold, MidBrakeThreshold, LowBrakeThreshold - These are for slowing down asteroids that are moving too fast.  Set it to the speed an asteroid must be travelling to incur a slowing-down effect.
  • EmergencyBrakeFactor, MidBrakeFactor, LowBrakeFactor - When one of the above thresholds is reached, this is the value that the speed is multiplied by.  Setting a value of less than about 0.98 causes the asteroid to slow down like a balloon does in air.

The brakes aren't exactly very true to astrophysics, but it lets you simulate (somewhat crudely) things like the response to an atmosphere such as if you try to throw a balloon.  The balloon slows down very rapidly and doesn't go very far.

Brakes are necessary if you use a bounce factor greater than 1, because that will mean each collision adds energy to the system.  Without brakes, the asteroids will collide and collide, picking up more and more speed, until eventually they fly all over the screen at lightning speed colliding with each other dozens of times a second, and vanish.
This is certainly interesting but hardly makes for a productive level-making environment.  Hence, the brakes.


Per-Asteroid Variables

Just copy and paste these ready-made template examples for each asteroid you need to declare for.

Code: [Select]
-- Asteroid 1
-- This asteroid has gravity and moves around.  It is drifting northwest at game start.
roid = 1
hasgravity[roid] = true
canmove[roid] = true
MomentumX[roid] = -13.1
MomentumY[roid] = -9
density[roid] = 0.3


If you forget to set these attributes for one of your asteroids, some default settings will be used for it instead (the asteroid won't move and won't have gravity).


  • roid - Enter the ID of the asteroid you are setting properties for.
  • hasgravity - True or False.  If you set to true, the asteroid will contribute forces to the gravitational field around it.  If you set false, it won't produce any gravity or feel any gravity from others.
  • canmove - True or False.  Can the asteroid be moved (by gravity and from being struck by other asteroids), or is it static and unmoving?  Using different combinations of "hasgravity" and "canmove" is the one of the main methods of producing different asteroid behaviours.
  • density - how dense is the asteroid?  Asteroids with greater density have more gravity.  An asteroid made of metal (which has very high density, eg 10) would produce more gravity, and also take more force to get it moving, than an asteroid made of gas (which would have a density of about 0.1).
  • MomentumX and MometumY - This is the starting speed/direction for this asteroid.  For example, if you set the X to -3 and the Y to 0, the asteroid will start the game drifting gently west.


You can also change the properties of individual asteroids ingame whilst the simulation is in progress.  To do this, simply open the console and declare a new value for the variable in question.
For example, if I wanted to set the density of Asteroid 1 to 500 instead of 0.3, this is the command I would type into the console:

Code: [Select]
density[1] = 500
Asteroid 1 would then instantly have a gravitational field more than 1500 times stronger than before, and the asteroids would all behave differently as a result of the change.
This looks hilarious, by the way.  It's like someone just pulled a giant plug in space, and everything starts rushing towards it...
« Last Edit: January 15, 2011, 02:55:02 AM by annikk.exe »

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Parallax Scrolling Engine
« Reply #4 on: January 15, 2011, 02:50:26 AM »


Difficulty: Advanced
CPU Cost: High - dependent on number of asteroids and stars



1.  Description

  • The Parallax Scrolling Engine lets you create stars that float behind the asteroids in your level, giving a faux-3D effect.

  • This engine is the most difficult to understand and configure.  However, in its default form it is cut back a great deal.  You should be able to massively increase the number of stars that are displayed with some tweaking, especially if this is the only engine you are using in your level.

  • This version is designed to display stars, but you can also use it to display other things.  Lots of different visual effects are possible.  The engine is set up to use Sprite Index 0 which in my view is the most star-like, however you can also set it to display other sprite indexes.  Possibly with some interesting results.



2.  Implementation

  • 1.  Download the file attached to this post called "Parallax Engine.lua".
  • 2.  Open the file in notepad or whatever text editor you use.
  • 3.  Select all of the code and copy it to your clipboard.
  • 4.  Open your own level and scroll down to the very bottom, and paste the code in.  It is imperative that it appears below everything else - including the "end" from your function LevelLogic().  The code you are pasting is two entirely seperate functions so if you inadvertantly put it inside function LevelLogic() then the map won't work.
  • 5.  At the bottom of your function LevelSetup(), insert this command: ParallaxInit()
  • 6.  Insert a LevelDraw function in between your LevelSetup() and your LevelLogic() using this command: function LevelDraw()
  • 7.  Ensure that you place an "end" after it, to indicate where the code in that function stops.
  • 8.  Inside your LevelDraw, insert this command: ParallaxEngine()

Now the engine is implemented, and will work immedietely.  However, be sure to change the variables to your own design before releasing it.



3.  Variables

The Parallax Engine has a large number of variables.  Some of the variables are arrays, so you will need to set values for all of the arrays too.  Because some of the arrays can span hundreds of slots, you may wish to combine formulas and For loops in order to set all the values efficiently, without having to manually specify each one.

This engine is not nice and friendly like gravity.  If you forget to set one of the values, the level will probably not load.

The settings for the Parallax Engine all appear in the ParallaxInit() function that you pasted in.
The section marked "User-Changeable Variables" roughly marks out the bounds of which variables are designed to be modified easily.


Single Variables


These are just single values that you can specify to govern global properties of the engine.

  • numberofstars - The total number of stars in your level.  Be careful with setting this too high - stars require a lot of processing power, especially if you have a lot of asteroids in your level.
  • numberoflayers - How many Parallax layers are there?  The stars will be split equally among the layers, so if you have 50 stars and 10 layers, there will be 5 stars in each layer.  You can set some attributes per-star, and other attributes per-layer.
  • widthofstarfield, heightofstarfield - How large an area shall the starfield occupy?  Change this to be optimum for your size of map.  The engine always centres the starfield at coordinates 0,0.
  • starsize - How big should each star be?  200 is good for average sized stars.  Setting this value very high creates some interesting effects, but the higher the value, the greater the CPU cost.
  • stoprenderingbelow - When you zoom out, the engine will start to reduce the alpha of certain layers (exactly which layers is definable in the arrays section below).  When the alpha falls below a certain point, the engine will just stop rendering them completely, saving CPU.  Set that threshold here.  Allowed values 0-1.


Setup Arrays

This is where you specify the attributes for individual stars and layers.
All these arrays are required by the engine and their values must be specified by you.

Red, Green, Blue - How much of each colour in the star?  0,0,0 is black.  1,1,1 is white.

For example, if you have 3 stars:

Code: [Select]
red[0] = 1
green[0] = 0.2
blue[0] = 0.2

red[1] = 0.2
green[1] = 0.2
blue[1] = 1

red[2] = 1
green[2] = 1
blue[2] = 1
   
This code would make the first star red, the second star blue, and the third star white.
The number in square brackets refers to the individual star we are colouring.

If you have hundreds or thousands of stars, this method is not a good approach.  Instead, set the values with a formula.  For example, this formula would colour the stars different shades of grey:

Code: [Select]
for setcol = 0,numberofstars do
red[setcol] = math.sqrt(1 / numberofstars)
green[setcol] = math.sqrt(1 / numberofstars)
blue[setcol] = math.sqrt(1 / numberofstars)
end
   
How to make the right formula?
Well, first think of what sort of values you are going to need.  I know that for grey stars I need the values for red, green and blue to be the same for each star.  So the formula should be the same for each of them (which isn't always the case - it depends entirely on the effect you're trying to achieve).
Next, I know that the values should vary between 0 and 1.  I also know that the one thing that I can rely on changing between one star and another, is its ID number.  So we can use that as the seed of difference for our formula.
"setcol" is going to vary between 1 and however many stars we have.  Say it was 50.  What could we do with the number 50 to get a value between 0 and 1?
One answer is to divide 1 by that 50, and use the result.  But that's only 0.02 - if we have 100 stars then it means most of them will basically be black.
We need to find a way to increase the result we get, without making it stray above 1.
An ideal way to do this is to take the square root.  The square root of 0.02 for the 50th star would be around 0.14, so its r, g and b values would be at 14%.  That's a dark grey, but not black.  The 10th star would be the square root of 0.1, which is about 32% - a gunmetal grey.  So it looks like this formula would work well for creating stars with different shades of grey.

It's up to you to develop your own methods for setting the colours of these arrays.  Lets move onto the next array.



threshold - How zoomed out do we have to be before each layer starts to fade out/disappear?

This is useful for keeping lots of detail when zoomed in, but only displaying a certain amount of stars when zoomed out so that the FPS doesn't suffer.
You need to specify a value for each layer.  Unlike stars, the numbering of layers always starts on 1, NOT 0.

You can specify values manually:

Code: [Select]
threshold[1] = 0.3
threshold[2] = 0.2
threshold[3] = 0.1
threshold[4] = 0.07
threshold[5] = 0.04

Or you can do it with some formula that you invent:

Code: [Select]
for setthresh = 1, numberoflayers do
threshold[setthresh] = 1 / setthresh
end



zdepth - How far away does this layer look?

This should normally be a value greater than 1.  The higher the value, the closer the stars look.
If the value is equal to 1, the stars will look like they are so far away that they don't move with the camera at all.
If the value is less than 1, the stars will move backwards!
If the value is 0, the stars will not be rendered.
If the value is less than 0, the stars will seem to be in the foreground - in front of the asteroids (but they will still disappear when they actually move in front of one)

In the template, the line looks like this:

Code: [Select]
zdepth[numberoflayers - lnumber + 1] = 1 + (5 * (1 / lnumber))
You can replace the bit after the = and write your own formula, or you can replace that line entirely and specify the z-depths for all the layers manually:

Code: [Select]
zdepth[1] = 1.1
zdepth[2] = 1.4
zdepth[3] = 1.8
zdepth[4] = 2.5

...or with any other method of your choosing.




Additional Arrays

As well as the arrays that are required for startup, there are also two others that you may be interested in using.

They are SetStarX and SetStarY.  These are the "given" positions of stars.  The engine generates these automatically at the start of the level but there is no reason why you couldn't refer to it and change it during play using some code in your function LevelLogic().
For example, if I want to make a star (lets say star number 50) move from side to side, I can do it with this:


Code: [Select]
function LevelLogic()
While GameRunning() do
SetStarX[50] = 1000 * math.sin(GetGameTime())

coroutine.yield()
end
end

That would cause star number 50 to drift left and right.
Using this, it's possible to make some - or all - of the stars move.  You could move lots of them at once by employing a for loop.




You can do a similar thing with the other variables and arrays.  You could have stars that flash/twinkle, or pulsate, or anything you like.  You can even have stars that come closer or move further away!  (by changing the zdepth of their layer..)
« Last Edit: January 15, 2011, 03:10:52 AM by annikk.exe »

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #5 on: January 15, 2011, 02:53:43 AM »
Questions below, please.  Don't make a new thread.  :>

Also, can I get this stickied perhaps?

AWS

  • Achiever
  • Arboreal Being
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 275
Re: Annikk's Mechanics
« Reply #6 on: January 15, 2011, 07:05:05 AM »
Bravo!!!
the time has come i see, to release these beasts into the wild...

10,000 thank you's, annikk, for making this game exceptional and for being the first port of call when people express an interest in making levels.

im sure this will provide the foundation for many more levels to come as well as provoke a million more questions...
;D

nice...

AWS

Bonobo

  • Achiever
  • Old Oak
  • ****
  • Thank You
  • -Given: 139
  • -Receive: 12
  • Posts: 670
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #7 on: January 15, 2011, 07:30:49 AM »
Yes, BRAVO and THANKS to you, Annikk! I’m anything but a coder, and when I look at any levels it's mostly lorem ipsum for me (though, being (not only) a media designer and having learnt Latin in school, lorem ipsum tells me more than code, and I can tell it is NOT proper Latin), but I can imagine these "Mechannikks" will propel design of levels in many ways. I just hope that my Parallels Virtual Machine w/ Vista running on an iMac will still be able to handle those future levels, performance-wise.

Rudolf

  • Administrator
  • Old Oak
  • *****
  • Thank You
  • -Given: 5
  • -Receive: 13
  • Posts: 669
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #8 on: January 15, 2011, 07:02:21 PM »
Questions below, please.  Don't make a new thread.  :>

Also, can I get this stickied perhaps?

Done!

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #9 on: January 23, 2011, 08:03:01 PM »
Is there any way of making the IAI not work on a certain empire? Like say I wanted all of the AIs to be infected apart from 0, 2 and 3, because they were to be used as easier, start-of-the-level empires? And can you change the behaviour of an IAI-controlled AI?

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #10 on: January 23, 2011, 11:06:28 PM »
There aren't really any settings to change for Infected AI at all I'm afraid.  I've thought about implementing "ignore this empire's asteroids" type things before, that would open the way to having different AI's compete against each other.  But currently you cannot do this unless you dive into the engine itself and change it (which you are of course welcome to do, if you have the time/inclination)

The only Empires IAI won't control are 0 and 1.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #11 on: January 23, 2011, 11:54:11 PM »
On second thoughts, it might not be that hard..


1)  Open "Infected AI Engine.lua"
2)  Lines 45 - 48 are as follows:

Code: [Select]
for iterations = 0,numberofiterations do

-- Select an asteroid for checking.
checkedroid = GetAsteroid(math.random(0,numberofasteroids))

3)  Add code as indicated below:

Code: [Select]
for iterations = 0,numberofiterations do

-- Select an asteroid for checking.
checkedroid = GetAsteroid(math.random(0,numberofasteroids))


for i = 0,numberofasteroids do
if GetAsteroid(i).owner == 2 or GetAsteroid(i).owner == 3 then
GetAsteroid(i):SetGraceTime(0)
else
GetAsteroid(i):SetGraceTime(99999)
end
end
if checkedroid.owner == 2 or checkedroid.owner == 3 then
break
end

This code selectively disables any cycles of the AI engine that happen to select an asteroid belonging to empire's 2 or 3.
It also switches on the default AI for any asteroids owned by those empires.
« Last Edit: January 24, 2011, 12:01:58 AM by annikk.exe »

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #12 on: January 24, 2011, 12:04:57 AM »
Quote
And can you change the behaviour of an IAI-controlled AI?

Only by changing the environmental factors of the level.  EG, the number of asteroids, their treecap, starting seedlings for the empire, plus nearby constraints such as greys present on all the asteroids, the presence of other nearby empires... these factors all influence how the AI will proceed.

It might be possible to manually set the metric for a given asteroid or something like that, to influence what the AI chooses to do.  If you can give more information about the type of behaviour you are looking for, I can probably help better.. :>
« Last Edit: January 24, 2011, 12:09:47 AM by annikk.exe »

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #13 on: January 25, 2011, 01:33:31 AM »
Thanks for that. I wanted to make it possible to have different types of empire (default, custom, IAI) in a level made with EUCLiD - to pre-empt requests for it. If it wasn't possible, I wanted to be able to say that too.

As for behaviour, I was just wondering how much you can do with it, or if it was, for want of a better word, static. Nothing specific.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #14 on: January 25, 2011, 02:12:45 AM »
It's pretty much automatic. It was designed to be that way - I wanted it to be very very transportable :>

V3 might include user-changeable variables by design, but I haven't really thought that far yet. Right now my focus is on preparing for a potential influx of new designers when eufloria hits the psn and potentially the iPhone and iPad. Speaking of which, any feedback on that intermediate guide? :>

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #15 on: January 27, 2011, 05:33:45 PM »
I was examining the parallax engine today and noticed that colours are currently done per-layer, rather than per-star.  I'll need to modify the guide to make note of that at some point.

Actually I'm thinking of modifying the whole engine.  I want to introduce sizes per star, rather than 1 size for all stars.  That will enable twinkling.  :>  Also I think I might make some slightly more n00b-friendly default values....
I'm working on a new level right now which will use the parallax engine (hopefully).

AWS

  • Achiever
  • Arboreal Being
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 275
Re: Annikk's Mechanics
« Reply #16 on: February 02, 2011, 03:05:29 AM »
I was examining the parallax engine today and noticed that colours are currently done per-layer, rather than per-star.  I'll need to modify the guide to make note of that at some point.

Actually I'm thinking of modifying the whole engine.  I want to introduce sizes per star, rather than 1 size for all stars.  That will enable twinkling. ...

hows this improving going?
got it twinkling yet?
im most interested as i want to use this for my next effort...
:D


annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #17 on: February 02, 2011, 03:15:10 AM »
If all goes well, the Parallax engine will be rendered totally obsolete within a few weeks.


See this thread for details.

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #18 on: February 02, 2011, 03:17:58 AM »
C'mon, at least let us get used to the old stuff before releasing new ones!

You don't work for Apple really do you?

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #19 on: February 02, 2011, 03:25:36 AM »
Crappy parallax engine.  It's so complicated to configure!
Trust me, you guys are not going to want to go back.  The new one will be simpler to understand, and it looks sooo much better.  It's only the engine that got more complicated; the Init section is easier.


Also, the concept of "parallax layers" specifically has been deprecated entirely.  That concept doesn't exist in the new engine.  Instead, depth is derived literally from a Z-coordinate.  So when you make a star in the StarfieldInit() function, you set it's X position, its Y position, and its Z position.  Everything you need to specify in setup is now either a global value (eg numberofstars = 200) or it's specific to individual stars (eg SetStarX[0] = -2000)
I think that is much more intuitive than layers.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #20 on: February 16, 2011, 03:28:57 AM »
RIP Parallax Engine.


EDIT - This is a demo only, NOT A TEMPLATE.
« Last Edit: February 27, 2011, 06:59:35 PM by annikk.exe »

AWS

  • Achiever
  • Arboreal Being
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 275
Re: Annikk's Mechanics
« Reply #21 on: February 17, 2011, 04:25:54 AM »

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #22 on: February 17, 2011, 06:23:41 AM »
That's a playable level file, by the way.
Just some fireworks I threw together with the new engine.  Go ahead and load it up - it's freaking awesome!  And then you'll understand why this signifies the end of Parallax and the start of 2.5D.  :>


Expect a 2.5D Engine Template to appear shortly..... or eventually...

AWS

  • Achiever
  • Arboreal Being
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 275
Re: Annikk's Mechanics
« Reply #23 on: February 18, 2011, 07:36:45 AM »
hey annikk, are you adding the 3D engine to this thread and keeping the parallax stuff? deprecating it?
whats the deal, yo?

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #24 on: February 18, 2011, 07:41:36 AM »
Still trying to decide.  I am temped to just keep Parallax for the time being due to the better performance, and hold off releasing 2.5D until I hear if A&R might be able to add the DrawSpriteBehind command I requested the "I want to but I can't" thread.. :>

threephi

  • Sapling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 63
Bug workaround for Infected AI
« Reply #25 on: June 01, 2011, 01:58:54 PM »
Hey Annikk, I've been playing the EXTREME PWN LAZ0RZ!!12 level (I love that name btw ;)) quite a bit lately, and thus running into that mixed tree bug that I posted about several times in that thread.  It was bothering me so I decided to do something about it.

Today I took a long look at the Infected AI code, and did a lot of testing, and I fixed it ;D

The bug actually stems from a flaw in the PlantDysonTree(faction) function in the game engine. This function will plant a tree of the designated faction on any asteroid so long as that asteroid has an available planting slot and the requisite number of that faction's seedlings, even if the asteroid already belongs to another faction and has existing trees growing there (which should make it unplantable by anyone else).  The result is trees belonging to different factions growing on the same asteroid.  This bug probably also exists in PlantDefenseTree but I didn't test it.

The formulas in the Infected AI that determine the asteroid metric values do allow for conditions where this bug is possible (for those reading along, in a nutshell it has to do with not having enough seedlings on an enemy asteroid to count as an attack, yet enough to plant a tree, and there is an open tree slot).  I didn't want to mess with how you have the metrics balanced, and figured it would be best to fix it at the planting stage, not the filtering stage.  This makes a sort of secondary metric 100 condition where an enemy asteroid has open tree slots but can't be planted yet; maybe it's a good thing since the low metric will encourage that AI faction to send seedlings towards it anyway, and soon enough tip the balance towards metric 0 and full attack... blood in the water if you will ;)

Without further ado, here is the relevant section from the Infected AI code, with the workaround included.  Essentially it performs the check that the function is supposed to, but doesn't.  The altered code is enclosed with the comment "bug workaround".

Code: [Select]
-- Actions

-- There are 3 different action types.  We must make sure not to use any actions for players 0 and 1!
-- 1.  Plant trees

-- trap for player 0, exclude player 1
if checkedroid.owner == 0 or checkedroid.owner > 1 then
-- so plant one :>
for i = 2,10 do

if metric[checkedroid.id] == 100 and (checkedroid:GetNumSeedlings() - checkedroid:GetNumSeedlings(i)) < 5 and checkedroid:GetNumSeedlings(i) > 9 then
-- this asteroid isn't owned by greys or player, the enemy only has a bit of seedlings here
-- its metric is 100
-- and it has enough seedlings belonging to the asteroid's empire to plant a tree
-- bug workaround: and there are zero growing trees on the asteroid, or the faction with enough seeds to plant actually owns the asteroid
-- this is necessary as PlantDysonTree() will plant a foreign tree on another faction's asteroid even if trees are already present
if checkedroid:IsBarren() or checkedroid.owner == i then
a = checkedroid:PlantDysonTree(i)
end
-- bug workaround end
end
end
end

-- 2.  Send seedlings to the next lowest metric

After spending about three hours today poring over the Infected AI code, I want to once again tip my hat to you for how smart that code is, and thank you especially for the copious comments that made figuring it out a LOT easier!

I made several attempts before settling on the above fix (which happily is quite small!).  The secret sauce is the IsBarren() function, which does two magical things at once: it traps for an asteroid with zero trees no matter who owns it, and it also, unlike any other function I could find, distinguishes between a fully planted root and one that hasn't finished planting yet.

I hope you will consider adding this fix into the main code and updating it since IMO the impact of this bug can be rather serious, and make a level unwinnable.

If anyone wants to see the bug in action, I made a test level (attached to this post) based on the the example Infected AI where I tried to set the preconditions that would automatically trigger the bug, but found that a bit daunting.  There seems to be an additional required element I haven't figured out yet.  But you can use this test level to very easily and clearly show the bug in the PlantDysonTree function:

N.B. the Infected AI in this test level does not include the workaround for this bug.

1) Load the level.
2) Immediately upon loading, hit esc and ` to pause the game and open the lua console.
3) Enter the following in the console:
Code: [Select]
GetAsteroid(0):PlantDysonTree(3)4) Unpause, and you will have an asteroid with trees belonging to two different factions.
« Last Edit: June 01, 2011, 02:29:40 PM by threephi »

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #26 on: June 01, 2011, 06:05:38 PM »
I followed your instructions and was able to recreate (in your test level) an asteroid belonging to 2 different factions.  :>

Going to theorycraft my way through the engine now to see if I can visualise how it might occur "in the wild" so to speak.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #27 on: June 01, 2011, 06:37:10 PM »
Well, I've thought about it, and I think your assertions about the engine and analysis of the bug are spot on.  I can visualise certain situations where a multi-owner asteroid might occur.

I tried to think of a good test to see if checking IsBarren() would prevent the bug from occuring.  I settled on trying the following line in the console immediately after entering your test level:

if checkedroid:IsBarren() or checkedroid.owner == i then a = checkedroid:PlantDysonTree(i) end

As I'd hoped, a tree did not plant.  The asteroid was only owned by one empire.


I am satisfied that you have proved the existence of the problem and developed a good fix for it.  Congratulations and thankyou very much.  :>  I will now edit EXTREME PWN LAZ0RZ!!12 and the AI engine template to include your bug fix, and will credit you with finding and fixing the bug.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #28 on: June 01, 2011, 07:39:03 PM »
EXTREME PWN LAZ0RZ!!12 and the AI engine template and "after" file have all been updated with the fix.

threephi

  • Sapling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 63
Re: Annikk's Mechanics
« Reply #29 on: June 04, 2011, 02:30:37 AM »
I posted about the bug in the support forum, and in formulating that post I realized there's a shortcoming to using IsBarren() since it will return true for an asteroid with TreeCap = 0 :-[  It doesn't affect the infected code, since you won't get to the planting code unless you have metric 100, which in turn means there is an open tree slot on the asteroid, but it's not the most elegant or transparent solution.

After thinking it over a little more, a more complete test for plantability is as follows:

(assuming the correct number of seedlings is present)
checkedroid:AvailableStructureSpace() and (checkedroid.IsBarren() or checkedroid.owner == i)

Lost Seedling

  • Shrub
  • ***
  • Thank You
  • -Given: 9
  • -Receive: 30
  • Posts: 205
Re: Annikk's Mechanics
« Reply #30 on: July 08, 2011, 08:10:47 PM »
I am trying to incorporate the AI engine into my map. I followed your implementation instructions as far as I can tell but on starting the map I get an error code "attempt to call global 'AIinit' (a nil value)" in the LevelSetup() section. I haven't been able to find another map that follows your instructions for comparison. Any ideas as to the problem?

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #31 on: July 08, 2011, 10:04:56 PM »
It's common that either you don't have the () or that you haven't implented the function or that the function runner is written wrong.

This should be added to common error messages Topic, when made :)

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #32 on: July 08, 2011, 10:33:00 PM »
Yeah sounds to me as if you've forgotten the brackets. Also did you see the Before and After level files I attached to the post?

Lost Seedling

  • Shrub
  • ***
  • Thank You
  • -Given: 9
  • -Receive: 30
  • Posts: 205
Re: Annikk's Mechanics
« Reply #33 on: July 09, 2011, 06:34:19 AM »
Working now. Thanks! The problem was not my typing but that I didn't get the initialization function from the original file, so there was no init function to call at the init command. 

 

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #34 on: July 09, 2011, 04:57:50 PM »
Annikk, could the AI be split into it's own file, with only a few function calls in the map? It might make it easier to incorporate, and you wanted to condense it a bit.

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #35 on: July 09, 2011, 08:59:22 PM »
Pilchard, that should work if you can map the whole AI from the file to the map :)

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #36 on: July 09, 2011, 11:04:07 PM »
Yeah, not too hard.

Add dofile(path to Infected AI Engine file) as the first line of your LevelSetup(). You can then call any functions from Infected AI Engine.lua in your level with impunity. The path section may/will need updating, depending on where you save the AI, but that is all.

And example level may say:
function LevelSetup()
    dofile("C:/Infected AI Engine.lua")
    {[add roids here]}
    AIinit()
end
function LevelLogic()
    {[blahblahblahblah]}
    InfectedAIEngine()
end


It's a lot simpler to look at, you know from the code it uses IAI and you don't need to copy the engine across. It could do with a little tweaking to prevent problems like the filepath being incorrect, but that can be fixed by changing the path...

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #37 on: July 09, 2011, 11:44:26 PM »
you can use dofile?? Dx

Thanks Pilchard, you now just let my pressure on the Adveture code by 10000 times :D

Now I can load codes externaly, like loading maps externaly I guess :D

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #38 on: July 09, 2011, 11:49:11 PM »
Wait, so I can store dofile(path) as a var and then run everything in it? It doesn't run when you do the dofile code??

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #39 on: July 09, 2011, 11:56:33 PM »
It runs when you call dofile(path). However, since the only thing in IAI.lua is function definitions nothing really happens. The functions are defined and stored as if they were declared in the same file as the level.

However, the code in path is all compiled each time dofile(path) is run. To use external functions more than one, use loadfile(path).
function foo = loadfile(path) This will compile only once, and save the contained code as the function foo.

Read this for a better explanation: http://www.lua.org/pil/8.html

kmercy

  • Seedling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 34
Re: Annikk's Mechanics
« Reply #40 on: July 10, 2011, 01:14:10 AM »
Yes yes i know im back

This is what i use if i want to take seedlings from one map to the next really simple actually check it for yourself:
Code: [Select]
-- kmercy Reinforcements code V1
rein = GetEmpire(1).NumSeedlings / 10
os.execute("mkdir " .. "C:\\Rein\\")
io.output(io.open("C:\\Rein\\" .. "Rein","w"))
meh = "-- Reinforcements v1\n\n"
meh = meh .. "\tReinforcements = " .. rein .. "\n\n"
meh = meh .. "-- Reinforcements v1 END"
io.write(meh)
io.close()
-- kmercy Reinforcements code V1 END

can be used in other maps like so:
dofile("C:/Rein/Rein")
a:AddSeedlings(Reinforcements)

Remember there was discussion about reinforcements so got me thinking ;p
« Last Edit: July 10, 2011, 01:20:36 AM by kmercy »

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #41 on: July 10, 2011, 01:19:41 AM »
I've fixed that ages ago, but not in the same way as you have :P

I didn't know of dofile, so I did it so much more complicated D:

kmercy

  • Seedling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 34
Re: Annikk's Mechanics
« Reply #42 on: July 10, 2011, 01:21:34 AM »
Didn't know you needed it but anyway its just there for anyone wanting to know how to do anything like that or exactly that :P

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #43 on: July 10, 2011, 01:38:31 AM »
You gave me the information I needed for simplifying, yet making my map harder to install xD

kmercy

  • Seedling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 34
Re: Annikk's Mechanics
« Reply #44 on: July 10, 2011, 04:34:25 AM »
well enjoy haha :P

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #45 on: July 11, 2011, 02:46:55 PM »
I still think splitting the code into different files is a flawed idea.  It may make the main code file shorter, but it's less convenient for the players to download a level and 20 function files, and get them all in the correct folder... and account for different installation paths for the game...  I think it's much better to just have a single level file and use a text editor that lets you minimize the functions when you're not using them.

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #46 on: July 11, 2011, 09:13:35 PM »
May be true, but if you got around 60(I don't have 60 yet, but I'm having a target for it :P) levels extra, each taking up 50-100 lines and the code running them is alreadt 2.5k lines long... wouldn't that be very frustrating?

And you can use archivers, and most people have some sort of arvhiver to fix them... Then you just tell them which path they must go to install them(Adventure does that the first time you try to play it) and then you just extract all the files from the archive to the folder...

Bonobo

  • Achiever
  • Old Oak
  • ****
  • Thank You
  • -Given: 139
  • -Receive: 12
  • Posts: 670
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #47 on: July 11, 2011, 10:13:55 PM »
Since the official distribution has a ZIP file for levels (or WAS it that way?), perhaps you could also use ZIP so it’s just ONE file to place in that folder?

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #48 on: July 11, 2011, 10:51:42 PM »
The problem with that Bonobo, is that you'll have to install this then: http://www.keplerproject.org/luazip/ and we can tell that as almost the same thing :P

Unless I am wrong and there is a way to see inside zip files, I'm not totally sure :/

AWS

  • Achiever
  • Arboreal Being
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 275
Re: Annikk's Mechanics
« Reply #49 on: July 12, 2011, 12:29:08 PM »
need your opinions - annikk and aino - on the updated custom level thread at the bottom.

i know that youve since made the 3d starfield annikk, but at the top of this mechancis thread, you still have the parallax as a heading, so tahts what ive put in the levels thread. shall i also include the 3d there as well, or what would you prefer?

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #50 on: July 12, 2011, 04:13:48 PM »
The links at the bottom don't work, the URL is wrong.

AWS

  • Achiever
  • Arboreal Being
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 275
Re: Annikk's Mechanics
« Reply #51 on: July 12, 2011, 10:05:18 PM »
The links at the bottom don't work, the URL is wrong.

not sure what happened there. but its fixed now.
 ;)

Lost Seedling

  • Shrub
  • ***
  • Thank You
  • -Given: 9
  • -Receive: 30
  • Posts: 205
Re: Annikk's Mechanics
« Reply #52 on: July 18, 2011, 03:18:11 PM »
Why is it imperative that the AI engine be placed below everything else? One of my functions is longer and will only run once, so it seems more logical to me to place it below the AI Engine - which runs continuously (or in my situation, intermittently).

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #53 on: July 18, 2011, 05:09:37 PM »
It has to be seperate to everything else because you need to tell Eufloria that the AI code is a seperate function, and not part of function LevelLogic()

Then you put the command "InfectedAIEngine()" in a loop that runs repeatedly.  Every time that command is run, it runs all of the code you pasted at the bottom.

Make sure you follow the step-by-step implementation instructions closely - they are quite specific.  :>

For more information about this method of calling functions from within other functions, see the final part of the Intermediate Guide.


Lost Seedling

  • Shrub
  • ***
  • Thank You
  • -Given: 9
  • -Receive: 30
  • Posts: 205
Re: Annikk's Mechanics
« Reply #54 on: July 18, 2011, 05:55:27 PM »
I understand that. What I'm asking is is it necessary for any reason that the AI ENGINE function itself (not the function call) must be placed below everything else - at the bottom of the lines of code. In your installation instructions, you said it must be placed there. I thought perhaps your reasoning was that since the engine was a rather large piece of code, it would be better at the bottom, out of the way as you wrote the rest of your code. If that is the only reason, I was thinking I should put my larger function, that only runs once at initialization, at the bottom. I thought perhaps I could save a few microseconds of processor time by putting it down there rather than in the middle somewhere. I just didn't understand why it was" imperative" that it be placed at the bottom. My understanding of the processor times involved in running various functions and code efficiency in general is so limited that I may be fretting over a few microseconds for nothing.

I'm not sure if I'm stating this any clearer or not.

I took your Intermediate Guide to heart, by the way, and have about 45 functions so far in my map code. It works quite nicely and makes things so much easier to access and work with.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #55 on: July 18, 2011, 06:26:53 PM »
Ah I see, in that case, no you don't necessarily have to have it at the bottom.  You can stick it anywhere you like.  :> I simply meant don't stick the AI Engine function, inside another function.  :P
I don't think it makes any performance difference to put the functions in different orders, so feel free to put it wherever.

Lost Seedling

  • Shrub
  • ***
  • Thank You
  • -Given: 9
  • -Receive: 30
  • Posts: 205
Re: Annikk's Mechanics
« Reply #56 on: July 18, 2011, 06:38:59 PM »
Oops! Well, that's exactly what I did- put it in another function. That engine was like a wild horse, and the seedlings couldn't be corralled as I wanted. So, I made an On/Off switch, and only run the engine when appropriate. It's fun to watch it "engage". I'd swear my lights dim a little whenever it gets activated.

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #57 on: July 18, 2011, 06:41:52 PM »
hehe... sounds cool!

AWS

  • Achiever
  • Arboreal Being
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 275
Re: Annikk's Mechanics
« Reply #58 on: July 30, 2011, 08:08:47 AM »
forgive me if this has been covered already but has this - The AI knows how to use flowers to get Super Seedlings, but it doesn't know how to plant them on Defence Trees to make laser mines.  Perhaps a future update will introduce this functionality - been addressd yet??
just a curiosity i had ;D

aws

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #59 on: July 30, 2011, 08:23:18 AM »
Nope.  I would need to figure out how the AI will decide whether to make Super Seedlings or a mine.  I could just make it random I suppose..

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #60 on: July 30, 2011, 08:33:04 AM »
Maybe Attribs and the apperance of Defense Trees can play in a role, meaning that high strength(which is what I've learned determines the most part of the mine) compared to the two others will trigger a mine if a defense tree is at availability :)

AWS

  • Achiever
  • Arboreal Being
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 2
  • Posts: 275
Re: Annikk's Mechanics
« Reply #61 on: July 31, 2011, 08:36:11 AM »
Nope.  I would need to figure out how the AI will decide whether to make Super Seedlings or a mine.  I could just make it random I suppose..
random seems good and fair to me...

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #62 on: July 31, 2011, 09:15:34 AM »
But... But! Random is so RANDOM D:

And random would significally decrease the danger the AI gives, for example, lets say random is 50/50, then tharmy would in theory become half of the normal size! Meaning the player can actually stand a fair chance without getting any powerboosts(events?) or making two AI's crush eachothers forces before cutting in!

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #63 on: August 15, 2011, 10:00:02 PM »
Annikk, have you any way of testing the speed that your AI runs in? I've had an idea for speeding it up...

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #64 on: August 15, 2011, 10:05:54 PM »
Annikks AI runs each tick, 60 times a second :)

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #65 on: August 15, 2011, 10:22:02 PM »
Oh yeah, so it does... I suppose it might be loocked to that then, unless I can fit in a workaround to my idea...

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #66 on: August 15, 2011, 10:24:34 PM »
do a for loop before selecting an asteroid, the loop will be extra "iterations" which will give more speed to the AI :)

annikk.exe

  • Achiever
  • Ent
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 1,809
Re: Annikk's Mechanics
« Reply #67 on: August 16, 2011, 02:40:10 AM »
By default, IAI selects one asteroid for checking per "cycle" of the while GameRunning() loop.  On a large map with 60 asteroids, this means by the law of averages each asteroid should be checked roughly once per second.

In AIinit() there is an inbuilt "iterations" variable.  It is set to 1 by default, meaning "check one asteroid per cycle".  If you wish you can increase this, which will have the effect of making IAI react faster, at the cost of CPU time.

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #68 on: August 16, 2011, 02:43:28 AM »
I think you explained it better than me :P Although, it's your AI :)

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #69 on: August 16, 2011, 04:53:28 AM »
Hm. Oh well, nevermind what I said before then. On reflection, it wouldn't have worked anyway...

Try reading PiL Chapter 9, you may be able to do something with that to make it more efficient. At the very least, it explains what coroutine.yield() means.

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #70 on: August 16, 2011, 04:56:46 AM »
Whats PiL? o.O

Never heard of it... BTW, I'm probably going to update my AI in a few days, I got no idea how I'm going to implent it, but thats why you got backups riiight? :D

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #71 on: August 16, 2011, 05:04:09 AM »
Programming in Lua. Pretty much the first go-to for Lua stuff. The first edition is free online, but the second edition you have to buy. First edition was written for Lua v5.0, second for 5.1, though first edition is basically all usable still. The second edition is bigger and more up to date, but like I said, you have to buy it. Link below explains it all much better, also gives you the first edition contents page.


http://www.lua.org/pil/

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #72 on: August 16, 2011, 05:11:43 AM »
Ohh, that page, I've used that for all my basic lua problems(lua-only related) to solve them...

Shortcuts 4 names...

BC wins

  • Seedling
  • **
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 39
Re: Annikk's Mechanics
« Reply #73 on: August 17, 2011, 03:37:42 AM »
By default, IAI selects one asteroid for checking per "cycle" of the while GameRunning() loop.  On a large map with 60 asteroids, this means by the law of averages each asteroid should be checked roughly once per second.

In AIinit() there is an inbuilt "iterations" variable.  It is set to 1 by default, meaning "check one asteroid per cycle".  If you wish you can increase this, which will have the effect of making IAI react faster, at the cost of CPU time.


not i didnt know this but its weird huh, I mean in all games AIs are always so much faster then a human player, yet u can always beat them with ease :P

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #74 on: August 17, 2011, 04:45:54 AM »
Handicaps and their thinking is so much shorter than a humans, so they suck more than the player, though the Handicaps disappears the harder the difficulty is, the thinking usually stays the same.

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #75 on: August 17, 2011, 05:32:25 AM »
Huh?

IDK if this is what you just said, but humans can multi-task better, have better spatial awareness, aren't limited by the programer's skill (or lack of it) and are actually intelligent. Game "AI" engines aren't really much more than clever-looking automatons. They may be able to calculate faster than humans and know how to play the game from the start, but the often have to resort to some form of "cheating" to be any threat.

I give you the following, spoilered to protect your productivity. The links below go to TVTropes. You have been warned.

Lost Seedling

  • Shrub
  • ***
  • Thank You
  • -Given: 9
  • -Receive: 30
  • Posts: 205
Re: Annikk's Mechanics
« Reply #76 on: August 17, 2011, 07:12:00 AM »
It's easy to forget that the "I" in AI is not really intelligence as experienced by human beings, but merely an illusion created by the programmer, and the speed of the processor and the efficiency of the algorithms. We encounter AI of various types and sophistication more and more as we interface with the electronic components in our lives, yet we only consider the "cheating" and "winning" aspects when we play games against an AI opponent. Pity the poor programmers who have to write code to accommodate the countless possibilities of how intelligent the user is, or how the user will screw things up or do the "unexpected".

As far as AI in games is concerned, the programmer is forced to implement the "rubber band" effect in order to make the game hold it's value as long as possible. In a game as complex as today's FPS's, if the programmer didn't resort to "cheating" at some point it would be impossible for a desktop PC to compete with the incredible parallel-processor between the player's ears. In a game with much simpler rules, such as checkers or chess, such cheating is not necessary nor possible, really. Someday, processors may become so fast that cheats will not be necessary, but instead a "dumbing down" will be in order. This is already common, of course, but it will become even more necessary. So when does making a game enjoyable and challenging for the player cross the line into "cheating"? Conversely, when does "cheating" detract from the enjoyment? Those are questions the game-maker must struggle with and attempt to balance, unfortunately not always successfully as any video-game player knows.

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #77 on: August 17, 2011, 04:08:14 PM »
Oh, I didn't mean that the cheating/rubber-banding was necessarily a bad thing - I'd have lost interest in most of my games far sooner than I did or will do without it, I'm sure. In fact, I think the 'cheating', if done right can make the game MORE enjoyable, not less. It can give you a sense of satisfaction that you beat it even with that handicap. Rubber banding, while it may be a little annoying sometimes, is also a necessary part of game AIs at present.

SweetCandyGrimm

  • Grimm
  • Shoot
  • *
  • Thank You
  • -Given: 1
  • -Receive: 1
  • Posts: 23
Re: Annikk's Mechanics
« Reply #78 on: September 03, 2012, 11:10:15 PM »
Ok so i thought id jump in to scripting for the first time with making my own Lvl as you have made simple step by step instructions.. only problem.. when u made this Windows 7 hadn't come out yet... when i go to load up the Lvl with just the simple "function LevelSetup()" notepad doc. i get an error that it cant play due to.. well this is the mesg i get :

Unable to load level
resources/maps/Grimm.lua due to
the following errors:
Resources/maps/grimm.lua:1:'end'
expected near '<eof>'

??

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #79 on: September 03, 2012, 11:51:47 PM »
I had this problem too, when I first started. When you save the level, you need to make sure that the file uses ANSI encoding.

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #80 on: September 06, 2012, 03:57:14 AM »
Pilchard... he needs to close his LevelSetup() functions with an "end". That's what the error message says :P

SweetCandyGrimm

  • Grimm
  • Shoot
  • *
  • Thank You
  • -Given: 1
  • -Receive: 1
  • Posts: 23
Re: Annikk's Mechanics
« Reply #81 on: September 06, 2012, 12:58:16 PM »
I had this problem too, when I first started. When you save the level, you need to make sure that the file uses ANSI encoding.

yea after posting that i went thru a few threads and figured out that due to using chrome i only had the LevelSetup() copied and not the rest.. i went back and let it scroll as it highlighted and sure enuff.. i had it... only this i dont have it seems is the ability to set these things (roids) up so they can be traveled to and from... tho im only 3 days into this whole making levels.. and scripting in general.. kinda wish i had a friend around here that did this stuffs too so i could learn it hands on.. but.. meh.. i take what i can get.. my fiance is more hardwear and keeping a pc running... my eyes hurt tho from staring at the screen for so long.. so im out for the night.. peace out ! :P

Pilchard123

  • Tester
  • Old Oak
  • ****
  • Thank You
  • -Given: 4
  • -Receive: 24
  • Posts: 932
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #82 on: September 06, 2012, 04:17:49 PM »
Oops, so it does. I just saw <eof> and thought it was the UTF/ANSI thing.

SweetCandyGrimm

  • Grimm
  • Shoot
  • *
  • Thank You
  • -Given: 1
  • -Receive: 1
  • Posts: 23
Re: Annikk's Mechanics
« Reply #83 on: September 07, 2012, 03:13:00 PM »
Pilchard... he needs to close his LevelSetup() functions with an "end". That's what the error message says :P

she lol :P

Aino

  • Ent
  • ******
  • Thank You
  • -Given: 4
  • -Receive: 30
  • Posts: 1,527
  • Eufloria: Yes
Re: Annikk's Mechanics
« Reply #84 on: September 07, 2012, 03:53:57 PM »
she lol :P

I refer to everyone as he before I know the gender, sorry :)

SweetCandyGrimm

  • Grimm
  • Shoot
  • *
  • Thank You
  • -Given: 1
  • -Receive: 1
  • Posts: 23
Re: Annikk's Mechanics
« Reply #85 on: September 08, 2012, 11:12:41 AM »
she lol :P

I refer to everyone as he before I know the gender, sorry :)

its good dood just call me grimm