evoman_framework's People
Forkers
cyberwillis jurrew27 judithnaomi haritha2298 hc1111 mjmessanella baat094 friedscholvinck sidiox phpeke sauloperceval alexsandr0x naftalluz anadepaula jyjeanne awesome-archive jwillekes rvdb7345 wolfb34 hensjiepensjie jenno98 pepijnnn matthijsdewit111 youngcheese kvtulder dccdelang sebastiaangroeneveld zhuang-jiawen sterlingjosh pjetroque mjgroeneveld nedimazar dymitrlubczyk anwarasif retamal96 nikita29112 gabhoo doublegio abijithanikkuruthi karim-1 roelrotti charlesaugdupont rinapiggy enis-b yuhao2252 daniyal9538 ravi-bossema fsun2000 tgroenewegen caro96hall tamrell guedesbruna sidpatkar maxiels aeli3 slayerofthebad martijnwesselius akhiltrc lloydnyarko marijn111 olegbezb maeganboosten thomas097 alexantonides chitreshcms reitsmairis bannopostma lccls arendgeerlofs tomsiebring sandergs92 ammeraal paulhosek niclashaderer hhuo7 niklasschaaf caspeerrr mario-holubar anproulx mzdog033 alexpapadatos95 lincde mz033 mateianton ploita mrclsu adaskos07 simonilic jygdub fr30 matercomus gid-git obviouslyluuk kaapthijs markmitrani mttvu simeongk veerleblomvu ea-group54 donalshorttevoman_framework's Issues
Inappropriate Min-max scaling in demo_controller
Hi, I'm debugging my assignment 2 code, and I find this issue. Maybe you would want to take a look at it?
In demo_controller.py
, the control
method does a min-max scaling:
def control(self, inputs, controller):
# Normalises the input using min-max scaling
inputs = (inputs-min(inputs))/float((max(inputs)-min(inputs)))
The problem is that min-max scaling should be done on the entire data set, not on individual inputs, otherwise, it will result in distorted data ranges.
In this case, this scaler will completely shadow the inputs[2] and input[3] because the original value range of these two is [-1, 1], while all other value ranges are wider than [-400, 400] based on my test. This means that after scaling, the original value of inputs[2] and inputs[3] won't matter because it is not significantly big enough compared to other values. This is bad because these two inputs represent "player's direction" and "enemy's direction", but now these two values in this case can not be recognized by NN.
The following graph is an illustration. I collected some data from the sensor to draw this figure, the y-axis is the scaled inputs[2], and the x-axis is calculated without original inputs[2] and inputs[3]. They show a directly proportional relationship with k=1, meaning that they are basically the same and the scaled inputs[2] is irrelevant with inputs[2] from the sensor.
I'll suggest to change it to something like this, which will make the scaling more resonable:
def control(self, inputs, controller):
# inputs_range represents real range for each inputs from sensor
inputs_range = np.array([[-700, 700], [-400, 400], [-1.0, 1.0], [-1.0, 1.0], [-700, 700], [-400, 400],
[-700, 700], [-400, 400], [-700, 700], [-400, 400], [-700, 700], [-400, 400],
[-700, 700], [-400, 400], [-700, 700], [-400, 400], [-700, 700], [-400, 400],
[-700, 700], [-400, 400]])
inputs = (inputs-inputs_range[:,0])/float((inputs_range[:,1]-inputs_range[:,0]))
Maybe you would want to fix this after the assignment 2 finished? Since lots of groups already working on their project based on this NN structure.
Inconsistency in multimode with the documentation
From the documentation: "
play(self, pcont=None, econt=None): executes a game run using the solu-
tions given as ’pcont’(player) and ’econt’(enemy) for the controllers. When
using the default controllers these parameters are not necessary, as agents
will take random actions.
When in single objective mode, it returns: fitness, player life, enemy life,
and game run time, in this order as single values. When in multi objective
mode, it returns: fitness, player life, enemy life, and game run time, in this
order as 4 lists containing values of each game (lists are ordered by the order
of enemies parameter provided)."
But actually in multimode is returning the mean - std of the player life, enemy life and time instead of the arrays
evoman_framework/evoman/environment.py
Line 608 in 8408b71
Deprecated code in tmx.py
ElementTree.getchildren seems to be deprecated:
evoman_framework/evoman/tmx.py
Line 81 in 38b63fb
Can be fixed by:
for c in list (tag):
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.