ocadotechnology / aimmo-unity Goto Github PK

The green and the red sprites that form the health bar are in the same layer and this leads to problems. When the avatar is created for the first time, it looks fine because of the order in which the sprites are added. However, when the isometric position is updated, the sorting order of the sprites in the children are also updated accordingly and this makes the red bar overlap the green bar completely sometimes.

Allow the possibility to add light points to the scene. This means refactoring the MapFeatureManager class to allow adding elements to the scene that are not sprites. Closely related to issue #3.

As mentioned in PR #64, not many types are consistent throughout the codebase. One instance is that width and height elements are text fields in the GeneratorMenu.cs file.

Right now the build time, even for as little assets as we have imported, takes a very long time (10+ minutes). This is due to the fact that the build includes all the editor files which we ( @ramonfmir @danalex97 and I) believe are not needed.

Mentioned in #26.

I know movement of files in and out of the Editor folder can omit them from building... but don't think this is the best option.

This is truly dependent on the fact if we manage (or decide to) split the editor from the rest of the code. Personally I don't think it's possible. This is in issue #27.

Article that may help: here.

• All the parts of the Level Builder are in separate files in the Editor/GUI/Menus directory. The generic file that renders the window, LevelBuilderWindow.cs is in Editor/GUI and contains some logic that should be moved to the Menus directory too.
• With PR #62 we introduced GUIUtils.cs which should take some logic out of menu's for re-use.

When trying to build to WebGL the project, the build can't be executed. The issues is the import of UnityEditor namespace inside the main assembly. This can be solved by removing some imports.

Another problem with the build is that all the files are included in the build, whereas the tool for level generation and the tests, as well as the test framework folder, should not be included at all.

A suggestion raised by @ramonfmir in PR #55. The file SceneHandler.cs contains method/function names on closing braces as a comment. Not necessary.

In the travis branch we have written quite a few unit tests. However, run time behaviour is just partially tested since in Unity the Editor mode and the Play mode behave very differently. That is why we should write some integration tests before merging #2. The Unity Test Tools package provides support for it.

All the controllers are static, but most of them do not necessary need to be static. Also, adding a singleton class functionality might be useful.

On ctr+s on the improve_editor_ux branch I get the following error:

Timestamps (354) and assets (353) maps out of sync - repair failed

Unless the sprite is renamed in the hierarchy, we can't import the same sprite for the second time right now.

As @CelineBoudier pointed out in #62 there are many files that have unnecessary imports because they have just been copy and pasted from other files for convenience. Some tidying up might be a good idea.

It makes sense to only allow the light to be moved within the sprite rectangle.

Generating obstacles makes them appear on the scene we are working on right now, but if you change scenes (note: nothing to save at this point according to Unity) then come back to the original one, the sprite will be gone and neither on screen or in the hierarchy.

If you move the sprite by mouse (not by WSAD from the Level Builder), unity sees a change, you can then save the scene and the object will persist.

Create a tool for the Unity Editor from which we can easily design levels and export them to the format that the back-end understands (this is implemented in #220).

There are two different projects in this repository:

• The main one, which listens to the back-end and updates the scene accordingly.
• The level builder, which is an editor tool for designers to create levels.

It would be nice if we could split them into two different repositories. One of the problems is that we have intentionally made the level builder depend on the main one so that map features are added to the scene using the same code that will be used in the actual game. I was thinking about making it a git submodule but I'm not sure that's a good idea.

• Prerequisite should say people should clone the project :)
• Add a Contact Us paragraph with the link to code for life contact form

Only the sprite generator builders should be here.

We need to clear the grid or detect the existing grid when the editor window is reloaded.

The score text does not change position when the number of digits in the score change and it looks ugly.

When pressing 'L' it doesn't change to light mode unless you un-select and select again.

Same idea as #6 but with audio sources.

On launch of project on the improve_unity_ux branch as of now the namespace GeneratorNS is not found nor' used in the LightSubmenu.cs file.

Assets/Editor/LevelBuilder/GUI/Menus/LightSubmenu.cs(3,7): error CS0246: The type or namespace name GeneratorNScould not be found. Are you missing an assembly reference?

• Look into other uses of this NS and see if we can remove it.

When an object is selected, the console updates the display only when the mouse hovers the object.

Forcing level designers to create the levels using our own button would be a good idea. First of all we wouldn't need to worry about dynamically adding the generators so that map features can be created. Instead this new scene that we control the creation of can have all the scripts (in the for of components) that we will need in the future.

By doing this, the ObjectController won't need to worry about the Level Builder Context and instead just worry about moving game objects in the scenes, as it should be.

Also, it would be nice to have a drop down menu with the levels.

Sometimes, not making the PNG's in the 'Resources' folder have a 'Sprite' texture type leads to problems. Let's find a way to automate this so that we don't have to change it for each image in the editor.

On the improve_editor_ux branch when I open the editor window I get the following error:

ArgumentException: Getting control 15's position in a group with only 15 controls when doing Repaint

It all works afterwards.

To make our issues easier to understand, reproduce and read - I think we should make use of github's ability for templates.

We need to create files named as PULL_REQUEST_TEMPLATE.md and ISSUE_TEMPLATE.md in the root directory for our repo according to this blog post.

There's many open-source ones available to use already, such as this.

We hold a type in the SpriteGeneratorBuilder. The way it's done, it works but it is a bit hacky and is hard to understand. Also, leads to lines of code such as line 144 in SpriteGeneratorBuilder. We should find an alternative way. @danalex97 might have some ideas.

A small enhancement I don't want to include in the current dropdown_and_refactoring branch because it's getting way too large.

I suggest we remove scenes after generating new levels so we don't get too much cluster in the hierarchy menu.

A simple call to this method with an appropriate flag will suffice.

I'm pretty sure that the ExportController doesn't work.

For now we select the options manually. Basically we need to force the camera to be orthographic and with a certain size and clipping plane.

The likes of files like AssetFetcher.cs use obsolete methods. We should convert them into the newer updated scripting API instead. E.g. EditorApplication.OpenScene() is used.

We need to integrate the current export with the back-end. The exported JSON should also contain the name of the class it generates, so the back-end can differentiate between the objects.

It would be nice if we could clearly see the object selected. Maybe change the opacity.

Update the README, write a wiki and improve / tidy up the comments.

Nowhere in the level builder it says that you're moving the light so sometimes it looks like the keys are broken. Think about something.

This is not that simple though. It is a problem we have encountered throughout the process of building this editor tool. You can detect keys all the time but you can only modify the interface of the editor inside the OnGUI() method. The way Unity works, it will only be called when the mouse is over it, which might not lead to a great user experience.

We had at some point a version that was running some tests on Travis.
Maybe we should cherry-pick that from the travis branch?

@ramonfmir @OlafSzmidt @CelineBoudier

Some convention errors. All files within Assets/Editor/LevelBuilder/GUI/Menus have capital letters at each new word in the filename. Same goes for classes within them. LightSubMenu.cs file has it's class called as LightSubmenu and this caused some errors to be raised when the class is called elsewhere.

Test the exporting functionality and the options in the editor. Most of it should be easy to test, since both the level builder tool runs in Editor mode just like the unity tests tool. The only tricky part will be the 'try' option added in #19.

This might be fixed together with #38. It seems to me like there's a lot of hard-coded things and the colour doesn't seem to work.

Now that the issue with the scenes not saving is fixed (#52), we should consider how to save a level without having to generate a new one (for example when you want to work on a different existing one, or simply want to exit Unity).

A simple save button for the current open scene should do the trick.

First, we need to write a full test suite for the current code. This will be run in TravisCI and after doing that we will also build the Unity project to WebGL and upload the generated files to Google Cloud Storage.

Often we try to load resources and assume that they're there, however that might not always be the case. Also, for instance the JSON format might be incorrect and everything will just fail without giving a very clear error message. There might be other cases in which better error handling is needed but these are the main two. Let's add our own assertions and error messages, it will make our lives easier.

We can only add one light on each sprite for now. We should perhaps think about a better way of adding lights instead of a simple toggle.

The ToJSON functionality should be pushed to the MapFeatureData structure. This should be implemented in a similar way the LightData is implemented.

Width and height fields are placed in a way such that it is only visible when on full screen and the window for the level builder needs to be quite wide for it.

It would be nice to have style checks for C#.