gurkenlabs / litiengine Goto Github PK

The utiLITI editor supports moving lights on the fly which recreates the entire ambient light and caches a lot of things in the process. After some time this causes very high memory consumption.

Currently, only the .jar and native library assemblies are created and copied to the build folder. Since the release is provided as .zip file containing all these files, we should auto generate this zip while building.

Currently, it is only possible to properly use most of the GuiComponent features with mouse input. There are several cases, where keyboard or controller input should be supported.

This will require to keep global track of which GuiComponent is currently focused for editing. This is already done for the TextFieldComponent in some way.
The support for these input devices includes:

• Menu : Select elements via UP/DOWN binding
• Slider: move slider left to right or top to bottom
• CheckBox: Trigger
• ListField: Select Element
• NumberAdjuster: increase/descrease number

When saving the game configuration, the default java implementation automatically adds a timestamp.
We should remove this, because this results in changes to a file that might be under version control in some cases.

current:

#CLIENT_SETTINGS
#Wed Sep 06 00:43:52 CEST 2017
CLIENT_country=US
CLIENT_language=en
...

desired:

#CLIENT_SETTINGS
CLIENT_country=US
CLIENT_language=en
...

Sometimes makes Sense top separate a Sprite Info multiple parts, e.g. to reuse them for different frames. We need to provide an Animationcontroller for this.

Right now, all tiles are rendered each frame which was originally implemented to support animated tiles.
Since the static tiles are not supposed to be changed during runtime, we can cache them in one image, which will tremendously improve the rendering performance of the map.

• OnSoundPlaybackFinished

Maybe: pass in sound playback interrupt predicate when playing

Also allow to interrupt sounds.
Might need to return SoundSource wrapped into some interface.

It would be reasonable to allow default scaling behaviors for Images on ImageComponents similar to .Net C# PictureBoxSizeMode enum.

see C# PictureBoxSizeMode

It is oftentimes necessary that a trigger cannot be triggered endlessly (especially collision triggers). It would be good to have an internal cooldown that ensures that triggers can only be activated at a certain rate.

Player Feedback From LDJAM
My biggest problem (which nobody else seems to have reported, so I wonder if it’s Mac-specific) was that I kept getting stuck in walls and couldn’t move for a while. Was especially frustrating on the last level where I’d fought hard for a couple of minutes to get the last person to the spot where I could aim at them and they finally went there but I got stuck on the way there for like 20 seconds and I missed the opportunity.

Apply friction to terrain in order to slow down acceleration and speed up deceleration of entities.

The MovementController implementations also need to be adjusted to support this change.

Right now the Offensive Ability class is implemented per game. Since it seems to be a requirement for almost any game, it should be moved to the engine instead.

The GUI component don't properly support to set properties to all their child components.
It should not be necessary to iterate every single component and set visual settings like "font".

Currently, it is not possible to simply retrieve the LITIengine from the Maven Central Repository because some dependencies cannot be properly resolved.

When forces are active on a IMovableEntity, they are being applied by its MovementController implementation.

Currently this is implemented such that all forces individually:

for (final Force force : this.activeForces) {
...
final double angle = GeometricUtilities.calcRotationAngleInDegrees(collisionBoxCenter, force.getLocation());
final boolean success = this.getPhysicsEngine().move(this.getEntity(), (float) angle, gameLoop.getDeltaTime() * 0.001f * force.getStrength());

This should be refactored ot only call this.getPhysicsEngine().move(this.getEntity(), ... once and aggregate all the forces before.

Wehenver a map is first loaded, the props are flickering for the first few frames.

When serializing maps with the litiengine XML model, the JAXB marshaller serializes a lot of unnecessary information which increases the filesize a lot.

Currently the implementation of our GuiComponents is not as clean as we want it to be.

• Constructors with large amounts of parameters
• Inconsistent behavior
• Not 100% completed implementations

(There are a lot of codesmells related to these components)

We should streamline all our GUI components and clearly define what they can do and what they can't.
The most important topic is the ease of use of the component interfaces.

• Introduce a Z-Order (distinguish mouse events -> only top most component)
• Add documentation about GuiComponents.
• Test remaining implementations

Currently the litiengine uses the default JAXB format for its XML output, which results in a large indentation that causes the gamefile to be beigger than necessary. Also the xml output of the mapeditor only uses one indentation, so we'd increase the comparability between the tool outputs.

current:

····<map height="64" name="hospital-level1" nextObjectId="0" orientation="orthogonal" renderorder="right-down" tileheight="16" tilewidth="16" version="1.0" width="64">
········<properties>
············<property name="AMBIENTALPHA" value="0"/>

desired:

·<map height="64" name="hospital-level1" nextObjectId="0" orientation="orthogonal" renderorder="right-down" tileheight="16" tilewidth="16" version="1.0" width="64">
··<properties>
···<property name="AMBIENTALPHA" value="0"/>

Changing the active environment detaches all the emitters in the current environment from the game loop. It seems like they are not attached anymore when switching back to the previous environment but only when the environment is initially loaded.

When playing "Naughty Gnomes" on a virtual machine provided by VMware Workstation 12 Player, the mouse could not be used properly.

Maybe the Screensize from the main display is used instead of the remote display and therefore the distance calculations for the mouse are wrong.

Currently one needs to add a collisionbox and a static shadow to the exact same place, which is redundant if one wants to just e.g. block the lighting with the collision box.

Currently, the engine only supports tilesets that are embedded in the map.

We need to implement support for external tilesets (.tsx files).
This can be done by using the source XML attribute and deserializing the tileset from the provided file.

Also, the file needs to be included in the environment file and the editor needs to be extended to support importing/updating exporting tilesets.

Currently the resolution only has influence for the windowed mode of the game because the fullscreen mode just uses the entire screen.

• Support ratio based scaling (4:3, 16:9, 16:10, ...)
• Make sure that the selected resolution is used in fullscreen mode
• Scale game in fullscreen according to resolution
• Implement selection of screens

The AStarGrid should take the terrain into consideration when calculating the costs for a cell.

Currently, it's not possible to use all functionality of the steam controller properly.

Steamworks4j provides access to the functionality.
We need to evaluate what we need from this library and how we can integrate it into the engine.

The Spawnpoints are part of the engine but currently not available on the environment.
They should be retrieved automatically when loading a map and provided as a list on the environment

Right now the keyframes from the sprites.info are loaded to the game but need to be manually retrieved when creating an animation with

new Animation(Spritesheet.find("sprite-name"), ... , Spritesheet.getCustomKeyFrameDurations("sprite-name"))

This is really redundant and should be retrieved automatically if any custom keyframe durations are specified.

The Rendertype of destructibles is set to GROUND on destruction. this looks horrible with larger entities, where you can just walk on them like cardboard.

XML is deprecated for saving TileLayers in the Tiled Editor. We need to update our serialization to support CSV as default.

Currently the images of a ImageComponent is always aligned top-left in the GUI component but this is not always the desired behavior.

The updating mechanism of the GamepadManager doesn't require a GameLoop with all its features.
A thread would be enough to execute this functionality once per second.

If an entity moves fast enough, it is currently possible to glitch though small collision boxes.
This needs to be investigated and fixed.

When increasing the timescale, the Movement is not affected. This is currently by design. We need to properly define and document how exactly the behavior should be.

I would like to ask a sample "Hello World" project using LITIengine or a "Getting started" wiki.
Thanks

In contrast to the original .tmx approach, we use an object model for the XML serialization of the map instead of manually serializing the layers.
We do enhance the tile- and imagelayers by an order property but this is not compatible backwards, which might result in losing the original order of the layers when serializing.
Because we're serializing two collections of layers it is not possible to mix the layer order between those elements. Within the layer types, the order is correct but if the order was originally something like

- TileLayer 1
- ImageLayer 1
- TileLayer 2

our serialization will result in the order

- TileLayer 1
- TileLayer 2
- ImageLayer 1

which would result in a wrong rendering order for the Tiled Editor and maybe other renderers.

To handle message for entities, it is currently necessary to overwrite the sendMessage method in a child class.
With this extension, it should be possible to just register on an Entity in order to react on certain messages.

Currently the IKeyboard interface is allowing IKeyObservers to be subscribed to all keyboard events. Typically the consumer doesn't require any type of keyboard events.

On the otherhand it is possible to register for individual key events keyPressed, keyReleased, keyTyped but only for specific keys.

Some usecases need to subscribe to these events independet of a spcecific key which is currently only possible when implementing the IKeyObserver interface but then again all methods need to be implemented, even if only particular ones are required.

Target state:

Refactor the IKeyboard interface to provide access to explicit key events without having to implement all others.

Add key independent methods:

• onKeyPressed
• onKeyReleased
• onKeyTyped

Instead of hjolding all appearance options seperately we should introduce a new Appearance object that holds all visuals for GuiComponents.

Currently, triggers can be activated without any delay. It would be reasonable to have a cooldown for activation.

The GuiComponents currently don't support enabling/disabling.

• Mouse events should not fire
• Provide different disabled color for control and text

Also ImageComponents should support a different backgroundimage for the disabled state.

There's an issue with the SoundEngine currently not supporting to loop sounds/music.
The problem is that the following method doesn't forward the loop parameter.

  public void play(final boolean loop, final Point2D location, final float gain) {
    // clip must be disposed
    if (this.dataLine != null) {
      return;
    }

    this.gain = gain;
    final PlayThread thread = new PlayThread();
    thread.start();
    this.played = true;
  }

Currently, the utiLITI editor is separated from the *LITIengine repository. This causes the necessity to create and maintain two parallel versions as well as the build and quality infrastructure.
To circumvent this, the editor should just be migrated to the main repository under a tools folder.

Although our exported XML maps can be opened with the mapeditor, the output XML differes in a lot of ways.
Some properties are being serialized in a different order and some have a different type (double instead of int).

It is desired to adjust out output in order to improve intercompatibility between the tools.

Example:

current:

<object gid="0" height="21.0" id="162" type="PROP" width="20.0" x="694.0" y="315.0">

desired:

<object id="162" type="PROP" x="694" y="315" width="20" height="21">

If another track is being played the request of slowly fading out the first and/or fading in the second track arises.

From @TheRamenChef #173 Add functionality for multiple music tracks to play

While playing multiple music tracks at once isn't inherently useful, it would help to be able to have two "versions" of a track playing at once, and switch between them using the gain controls.

The custom implementations for StaticShadow, Spawnpoint and MapArea should inherit from Entity just like all other things on the environment (e.g. Trigger)

Currently the loading of MapObjects of all MapObjectTypes is implemented in the Environment class.
If someone wants to change a loading behavior, he needs to overwrite the Environment and provide a custom child implementation for certain methods.

This results in the environment being a very large and hard to maintain class and the API requires to inherit from core litiengine classes, which is not desired.

The new approach would be to implement small IMapObjectLoader units that handle the loading process for exactly one MapObjectType. These will then be registered on the environment, which holds exactly one loader for a certain type.

  public void registerMapObjectLoader(final MapObjectType type, final IMapObjectLoader loader);

  public void registerMapObjectLoader(final String type, final IMapObjectLoader loader);

By providing an overload method that accepts a String as type, it is also possible to reuse this approach for custom map object types that are not part of the engine.

In order to save some system resources, the ScreenManager should decrease the FPS if it is in the following states:

• Iconified
• Has no focus (e.g. behind other windows)

Parts of the loops are similar and can be extracted. Also we need to check whether the current InputLoop implementation is any good or if we need an own implementation for this.

It would be helpful for GUI development to display the bounding box of GUI components.