Getting LOVE2D to run faster and AI stuff

[EliterScripts]

Hello, I am currently working on a game and I'm interested in getting into artificial intelligence at some point, and making "fake" players in my game so when it starts off, players don't instantly quit because there aren't any players on the server.

Anyway, I am using LOVE's default physics engine, BOX2D, and would like to know some tips on how to get my game running as fast as possible, so that the artificial intelligence can get smarter a lot quicker. I intend to run this on a server (or possibly a clust of servers then destroy them so I only pay pennies for a short period of time for using them), without graphics (or a window for that matter), so I was wondering what else should be done to make sure the game runs quickly?

Box2D seems to have a tendency to allow objects to go through walls if the speed is too high or the conditions are just right. I was thinking I could artificially lower the DT by updating the physics world, giving it a lower number than the actual DT.
I was also thinking about multi threading, but I can't even think of a design where that would actually be faster.

I dont need human playable frames.

Aside from trying to hack the game into playing faster, what are some good things to look at to use AI for a 2-dimensional game? I was thinking I could program my game to send JSON output of all the physics objects, with their shapes, game types (player, wall, bullet), health, velocities and positions, so I was hoping that doing so would allow for my to go outside of Lua/LOVE and use Python (or other language) to analyze the world data, and take actions (such as applying force on the player (moving it around) or shooting bullets).

My idea of making a player is make the AI play on a server with other AI players (maybe they will be separated AI's or all under the same AI, not sure what is best), and have them learn how to fight each other, so that when a real human player comes along, they'll have some practice.

The game is a tank game, similar to diep.io, but I am doing my own spin of it, but that should describe some of the basic mechanics of it.

[ivan]

You can use body:setBullet to mitigate the tunneling.
A constant timestep is highly recommended if you expect stable behavior for joints.
Love2D itself is already fast, but you can use profiling to optimize your Lua scripts.
Good luck!

[pgimeno]

I don't recommend Python for performance-critical purposes.

https://github.com/trizen/language-benchmarks

Besides that, try the http://wiki.luajit.org/Numerical-Comput ... ance-Guide to see if that helps.

[EliterScripts]

I don't recommend Python for performance-critical purposes.

I actually don't intend to use Python to run the game. The server will serve the client using LOVE2D/Lua with standard/universal protocols, Python (possibly) will be running the AI that connects to the server.
I am choosing to write this game in Lua/LOVE because 1. it's extremely portable (more portable than Java, since my impression is that Java does not run on iOS mobile devices), 2. I am familiar with Lua 3. It somewhat magically works.

However, I have no college major, degree, friend or experience in artificial intelligence or anything like that, and I don't see any library that I can run in Lua (not really looking for LOVE2D solutions) that sticks out. Most of the tutorials or even people spouting off how they taught a computer to learn to play simple games don't say they've used Lua for artificial intelligence, I've mostly seen Python for AI.

Definitely, I will try using Lua/LOVE2D for the server and "human" client (that is, the client tailored to humans). I plan to have a client that tailors to artificial intelligence, and program the server to simply "flip" a setting and allow the AI client to quickly learn the game (by, for example, making the game run faster than normal time). If I am not mistaken, Python is the way to go for creating the AI player client.

[EliterScripts]

You can use body:setBullet to mitigate the tunneling.
A constant timestep is highly recommended if you expect stable behavior for joints.
Love2D itself is already fast, but you can use profiling to optimize your Lua scripts.
Good luck!

You can use body:setBullet to mitigate the tunneling.

Yes, I know. However, I have programmed my game to have a circle as an enemy. The enemy is programmed to fire a circular bullet (with setBullet enabled) from the center of its own body to wherever I (the single human-player) am at in the world. I believe the collision between the bullet and the fixture it is from is disabled during the initial firing, I'll have to double-check my code. I have created a wall (polygon) that is static in the world, which should prevent the bullet from going through the wall, let alone make the wall move.
However, when the enemy is directly next to a wall (even touching it), and I am at the other side of it, the bullet will go through the wall.

My concern is: 1. I need to fix this and 2. It will ruin the learning of the artificial intelligence and 3. It will become worse if the game is progressing much faster.

A constant timestep is highly recommended if you expect stable behavior for joints.

Good point bringing up, which reminds me of the concern, if I stabilize the timestep for the purpose of AI learning, wouldn't it break when the game is put back to a normal timing system when it is competing against real players?

Love2D itself is already fast, but you can use profiling to optimize your Lua scripts.

So I remember only achieving something in the ballpark of 0.01 DT on both my Ubuntu Desktop (which is beefy with 4core@3.5GHz, 16GB of RAM and GTX 720 (or 780) graphics card) and Ubuntu laptop, which I would say is much slower than I would think is most optimal. I'll have to double check.
Also, if you could clarify what "us[ing] profiling to optimize [my] Lua scripts" is, I would greatly appreciate it.


Thanks!

[ivan]

The enemy is programmed to fire a circular bullet (with setBullet enabled) from the center of its own body

Fixture:setFilterData can disable the collision between the two.
Without "setFilterData" the two fixtures will push each other apart so there may be "knockback" to the enemy as well.

if I stabilize the timestep for the purpose of AI learning, wouldn't it break when the game is put back to a normal timing system when it is competing against real players?

The timestep could be either "fixed" or "variable".
Variable timestep (delta) means that joints' behavior is inconsistent/unstable.
The Box2D documentation explains that you should always use a fixed timestep for realtime simulation.
https://box2d.org/manual.pdf

A variable time step produces variable results, which makes it difficult to debug. So don't tie the time step to your frame rate

Also, if you could clarify what "us[ing] profiling to optimize [my] Lua scripts" is, I would greatly appreciate it.

Profiling shows you which part of the code takes the longest time to execute:
viewtopic.php?t=80759
Love2D is already fast - if you want your game to run faster, you have to run less Lua code.

[BorhilIan]

Multi-Threading in my project looks something like this, does indeed improve performance for me. Currently using it for path-finding among many other things.

Code: Select all

--	conf.lua

function love.conf( t )
	t.title = "Multi-Threading by BorhilIan"
	t.console = true
	t.version = "11.1"
end

Code: Select all

--	main.lua

function love.load()
	--	The channel used by the alpha thread.
	alpha = love.thread.getChannel( "alpha" )
	--	Channel used to get return information from alpha.
	alpha_result = love.thread.getChannel( "alpha_result" )
	--	Create the alpha thread using its own lua file.
	alpha_thread = love.thread.newThread( "alpha.lua" )
	--	Send the alpha thread any important variables.
	alpha:push( "something" )
	alpha:push( 1337 )
	--	Start the alpha thread after giving it important variables.
	alpha_thread:start()
end

function love.update( dt )
	--	Let the alpha thread proccess for the 'dt'.
	alpha:supply( dt )
	--	Do the main thread stuff like normal.
	--	NOTE: IDK WHAT TO PUT HERE!?!
	--	Now wait for our super important result from alpha.
	print( alpha_result:demand() )
	--	Waiting for result above is not nescesary
	--	since alpha will loop once per above supply.
end

Code: Select all

--	alpha.lua

--	You will have to manually require stuff aside from "love.thread".
require( "math" )

--	Get the channel used by this thread.
alpha = love.thread.getChannel( "alpha" )

--	Important startup variables for this thread.
importantString = alpha:demand()
importantNumber = alpha:demand()

--	Get channel for sending information back to main.
alpha_result = love.thread.getChannel( "alpha_result" )

while ( true ) do
	--	Wait until main thread says to run.
	local dt = alpha:demand()
	--	Our super important multi-threaded code!
	print( importantNumber, dt )
	--	Now send any important data back to the main thread.
	alpha_result:supply( importantNumber * 2 )
end

Do keep in mind that if you don't manage your supply/demands meticulously your application will hang without any errors. Not an issue in my application but something to consider. Additionally your applications speed can be limited by the bandwidth between inter-thread communication but I've yet to hit that limit myself. (Modern CPUs are so neat)