Refactor environments into hierarchy?

szemenyeim / DynEnv

Dynamic Simulation Environments for Reinforcement Learning

GNU General Public License v3.0

13 stars 1 forks source link

Refactor environments into hierarchy? #2

Open rpatrik96 opened 4 years ago

rpatrik96 commented 4 years ago

Status quo

Code for both environments is on the same hierarchy level, which makes the code harder to maintain/navigate.

Proposal

Create a robocup and a driving folder for each.

Considerations

Would it break anything

github-actions[bot] commented 4 years ago

Hi! This seems to be your first issue in this repo: now, you are officially a member of the Order of Bug Bounty Hunters. Keep hunting!' first issue

rpatrik96 commented 4 years ago

Additionally, it would be reasonable to have a superclass for both environments, as there is duplicate code in both.

szemenyeim commented 4 years ago

Hmm, yeah, let's separate the env-specific things (Including classes, like Robot, Car, Pedestrian, etc.), and create a superclass. I don't think it would break anything (at least anything that can't be fixed).

rpatrik96 commented 4 years ago

There are some questions/remarks worth discussing regarding this matter:

make_dyn_env uses the use_continuous_actions parameter for allowHeadTurn as well. Isn't this a continuous action as well? Here some rename would make the code easier to understand. I will leave it this way in my next refactor commit.
as the render function was almost the same, I opted for renaming robots and cars to agents, so I could refactor.