stephcraft / project-16x16 Goto Github PK

Steps to reproduce

1. Enter the current loaded level name in the save level window
2. Click to save the level
3. Close the game
4. Open the game - empty screen

This issue is for everyone to see the progress on the combat system I'm implementing, so I can get feedback on how it feels in the game, and how I can improve it. Will upload the changes to my fork, so everyone can get them without merging them to the main repository.

Drag the magic source (pink) and it's animated tile will not move with it.

Issue:

The tutorial here link does not work anymore and the current step is written below. https://processing.org/tutorials/eclipse/

4. Now you should know processing, but maybe you've never used the Eclipse IDE before, tutorial here

Proposed Change:

4. Now you should know processing, but maybe you've never used the Eclipse IDE or the Intellij IDEA IDE before. Eclipse Tutorial or Intellij Tutorial

The two tutorials are just basic tutorials for installing and using each IDE. The direct links are below:

https://www.vogella.com/tutorials/Eclipse/article.html
https://www.jetbrains.com/help/idea/run-for-the-first-time.html

I checked the Processing page and did not find any tutorials, unless I missed one.

An options interface is needed to modify and apply options in game.

Currently the game modes in the GameplayScene are stored as enums, and all the logic associated is being checked and processed inside the scene object using switch case statements.

As mentioned in #68, this enum can be refactored as classes, and i thought a good design would be one following the state/strategy patterns:

• A GameMode abstract superclass with (mostly) empty common methods.
• Concrete classes implementing GameMode and it's relevant methods with all it's specific logic.
• A HashMap storing instances of these objects as values and .class types as keys.
• A public activeMode (or tool) variable which stores the current mode and interfaces with all the objects.

Some benefits i see with this implementation are:

• Better readability: The method calls inside GameplayScene would be more clear, as only one method ends up being called, and as all the logic is stored in separate classes implementing a common interface, it should be easier to understand what does what just by looking at those methods.
• Respects the Single Responsibility Principle: For all the reasons given above.
• Better performance: Even if some checks are done inside the methods, the execution should be more straightfoward as most switch case statements would be removed.
• More scalability: As the project progresses, the modes can be easily expanded upon and mantained accordingly.

Leave any comment or suggestion, i'll be working on the implementation during the following days, along with any relevant reports.

The README contains only a gif from the tileset source.

I think it would be helpful (and more enticing for potential contributors) to include some screenshots (such as play mode, create, menus) of the present game in the README.

Things to be made to improve the current Collision system:

• Create the Collider class
• Create the Tile class
• Create the Sprite class
• Rework Sprite and Tile classes to have a Collider array ArrayList<Collider(x, y, w, h)> for collisions
• Tile based collision detection for Tiles
• class structure should be reorganized to:

GameObject
    Sprite
    Tile

Currently, the tilset is loaded as separate sprites, located in class sidescroller.GameGraphics. The tileset should be loaded as 16x16 tiles instead. This issue could affect #30

We should add unit tests for existing codebase in order to have a coverage of 80% at least.

Each test class should test the related src class and be located under same package.
E.g. Tile.java src class is under project_16x16.components package (src/project_16x16/components directory). TileTest.java test class must be under project_16x16.components package (test/project_16x16/components directory).

Test class name must have the suffix Test added to the source class under test.
E.g. Tile.java src class to be tested must have a TileTest.java test class.

Add a Discord badge ( or see here) to the README for easy access to project's discord channel.

• A good way to do it: In eclipse, right click on the class symbol, refactor -> rename
• File to be renamed: Util.java

• On the option menu and the save menu, the buttons are not in the desired positions. It may need a change on how a button is drawn in the button Class.

• Also, when a menu is displayed, we are able to move the camera (shaking, zooming...) and change framerate by pressing "special keys" ( X, R, V, C, F, G).

• Video here.

1. The fly animation (which is actually SQUISH) should cycle just once during a jump (ie. on take off) - at the moment, it cycles through a second time and makes jumping look janky.
2. The SQUISH animation should cycle once when the player lands.
3. The velocity boost from SHIFT key is too much.
4. Holding SHIFT+space (jump) leads to buggy behavior.

1. Make Level Editor easy to understand for people not for developers only ;)
2. Provide documentation for Level Editor

Selecting objects (to move them) in modify mode is very inconsistent/bugged. Some objects won't select at all; others can be selected once, and then won't select again depending upon where you placed released them.

It seems moving objects to around x<350 will prevent them from being selected again, otherwise they're ok?!

I've looked into it a little, but see no obvious reason why it's happening.

I try to join your dicord sever with this link : https://discord.gg/zDJSCqd but there is an invalid invite link error. please refresh the link

If you spam wasd, space shift and mouse 1 while shooting a projectile you can crash, looks like an animation bug.

java.lang.IndexOutOfBoundsException: Index 3 out of bounds for length 3 at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248) at java.base/java.util.Objects.checkIndex(Objects.java:372) at java.base/java.util.ArrayList.get(ArrayList.java:458) at components.AnimationComponent.animate(AnimationComponent.java:69) at entities.Player.update(Player.java:353) at scene.SceneMapEditor.draw(SceneMapEditor.java:219) at sidescroller.SideScroller.draw(SideScroller.java:215) at processing.core.PApplet.handleDraw(PApplet.java:2483) at processing.javafx.PSurfaceFX$1.handle(PSurfaceFX.java:90) at processing.javafx.PSurfaceFX$1.handle(PSurfaceFX.java:1) at com.sun.scenario.animation.shared.TimelineClipCore.visitKeyFrame(TimelineClipCore.java:239) at com.sun.scenario.animation.shared.TimelineClipCore.playTo(TimelineClipCore.java:197) at javafx.animation.Timeline.doPlayTo(Timeline.java:175) at javafx.animation.AnimationAccessorImpl.playTo(AnimationAccessorImpl.java:39) at com.sun.scenario.animation.shared.InfiniteClipEnvelope.timePulse(InfiniteClipEnvelope.java:126) at javafx.animation.Animation.doTimePulse(Animation.java:1101) at javafx.animation.Animation$1.lambda$timePulse$0(Animation.java:186) at java.base/java.security.AccessController.doPrivileged(AccessController.java:389) at javafx.animation.Animation$1.timePulse(Animation.java:185) at com.sun.scenario.animation.AbstractMasterTimer.timePulseImpl(AbstractMasterTimer.java:344) at com.sun.scenario.animation.AbstractMasterTimer$MainLoop.run(AbstractMasterTimer.java:267) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:558) at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:542) at com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:535) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:341) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) at java.base/java.lang.Thread.run(Thread.java:835)

Needs more documentation (Javadocs or wiki) from the people who wrote the existing classes and functionality to explain to new contributors what each class does and how they fit into the bigger picture (architecture).

The inventory scrollbar scrolls too fast. This is probably strongly related to the fact that the scrollbar does not look proportional/mapped to the size of its content. As you can see in this image, the size of the scrollbar is quite big:

Only global keys (such as fullscreen toggle) should be handled in SideScroller.class -- all other hotkeys (that are scene related) should be handled by the relevant scene by overriding keyPressed or keyReleased.

Here are bugs concerning zooming:

• Can zoom out the camera with scrolling but cannot zoom back in.
• Can zoom while in inventory mode. Scrolling should be only affecting the inventory scrollbar.
• After zooming, the camera drag movement is bugged. The camera eases to a fraction of the movement.

Further explanation:

How it currently works is as you zoom in or out, it changes the camera’s x and y position. This should not happen, as it should only zoom toward the center of the screen. I’m not sure if that’s what the setOffsetScale statements in the Camera class are trying to handle. It doesn’t seem so, because after commenting it out, the canera x and y doesn’t change on zoom, but the camera still zooms. That’s okay, but then the only problem is that it zooms towards the world origin. It should zoom toward the center of the screen instead.

I also noticed the camera position doesn’t scale along with the zoom. If I move in an x or y direction, zoom in, and move again, the camera x and y should increase/decrease faster/slower based on the zoom level. This may be an easy fix, and I’ll keep looking into it, but it would definitly be helpful to have someone explain the zoom offset stuff! Thanks to anyone who knows!

Scroungy

Good evening in the context of a university thesis I ran a few metrics in your work .I send you my results in order to contribute to the improvement of your project.

Some of the notable metric results :

1. Chidamber - Kemerer Metrics
   

2. Complexity Metrics :
   

3. Complexity-Package -Project Metrics :
   
   V(G)avg ->Calculates the average circuit complexity of all non-abstract methods in the project.
   v(G)tot ->Calculates the total circuit complexities of all non-abstract methods in the project.

Help needed in developing the Camera class. I simply do not have the time to work on it. If anyone has questions about my current code feel free to ask me. Other than that development for this will be in the CameraDev branch.

It would be easier to use all those items if they had names

Instead of switching back to the game and pausing. The pause menu opens on top of the options menu and blurs the menu bellow.

The projectile should have two colliders, one is a small box in front of the projectile to detect collision with entities & gameObjects and the other one is a line also in front that detects if it touches a wall. The magic projectile also needs to have an animation to fade away when it collides with an entity, gameObject or a Collider.

• Modify colliders
• Might affect the temporary solution implemented in #21
• Fade-out animation
• Destroy when colliding with MirrorBox on a non reflecting surface
• Implement the new projectile system in the magic projectile
• Generate pre-rendered particles from the base particle

The level designer requests to be able to use Tiled while the level editor is in construction for Project 16x16. Tiled is a third-party tileset map editor. It exports to the .json format.

A button with the functionnality of converting a Tiled .json file to a game map file format is needed.
The function should be placed in the Utility class.

Here are resources to help you achieve this issue:

• Processing library for drawing Tiled maps
• Tiled JSON format documentation

Alot of tiles are missing, for exemple:

• The sign with writings on it
• The barriers
• The pink decorations
• The working benches
• The very light platforms
• The small tubes decorations
• The big tube with a wheel on it
  more...

All tiles should be 16x16. The only exeptions are the magic projectiles

• DOOR_RIGHT needs to be split in 16x16 tiles

After the walking animation cycles though frames 0-7 a first time, the animation gets stuck on frame 0 when walking right and stuck between frames 0 and 1 when walking left.

The MirrorBoxObject only reflects projectiles that travel from left to right, i.e. projectile.direction = RIGHT. I'll get working on this.

As you can see in this image, you can actually get stuck into blocks. This is easily recreated by shift-jumping into a blocks corner.

It is really consistent and it always work if you hit the corner correctly.

Most of the time you're able to get out of the block by walking away from it but you also might get stuck in it (I wasn't able to replicate it).

The Utility class should have some javadoc comments explaining its purpose.
There are missing javadoc comments on the following functions:

• PImage scale(...)
• PImage rotate(...)
• boolean fileExists(...)

A tip to write good comments is to answer the question Why? instead of What?

It is possible to hold the swing attack on a source. This will spawn continuously magic projectiles and swing projectiles.

Development of the Options.

1. Create a static Option class
2. Create static variables in the Options class to represent specific options
3. Create control keys options
4. The options will be stored in a JSON file, so a JSON file structure must be designed
5. Integrate a Option.load() function. It must parse the JSON file and set the variables
6. Integrate a Option.save() function. It saves the data from the variables in the JSON file
7. Replace all hardcoded Key values for Player movements by the keys defined in an Option class

There are about ~85 warnings in the project. These warnings are not explicit errors, but it is a good practice to have none:

A non-exhaustive list of feature TODOs and/or suggestions.

• Remove VIEW mode (since modify mode can do both)
• Add panning to MODIFY mode
• Game object rotation in modify mode (non-trivial if not steps of 90deg since collision boxes would need to be angled accordingly and detect collision at angles)
• Pause menu [IN PROGRESS]
• Main-Menu [IN PROGRESS]
• UI Components: checkbox, slider, key entry
• Sound
• Player key mapping [IN PROGRESS -- functionality works, needs UI]
• Enemies
• Multiplayer [RUDIMENTARY]
• Tighten player hitbox
• Level Preview (in level load)
• Docs: development getting started and project set-up
• Animation improvements (see #67)
• Introduce static final class for ease-of-access to constants (such as strings, number constants, color presets, etc.)
• MODIFY mode: Right-click and drag to select multiple objects
• Replace project collision solution with a more robust solution
• Refactor GameplayScene so that modes (PLAY, MODIFY, etc.) are better separated -- a class for each?

The FALL animation sequence is triggered during a jump, but is not triggered when the player falls without jumping (falling from a platform for example).

This issue is mentioned as a bullet point in #68 and i'm opening it here for better isolation.

As the collision solution implemented in the project currently is not as much escalable, i'm taking a shot on it. Talking with @Stephcraft over Discord, he gave me advice on the desired implementation, using a PhysicsEngine singleton to register and handle every collision check for every non-static Collider object. The reached design is as follows:

• Creation of a new class, PhysicsEngine, as a singleton with read-only calls across the project, with the instance that can be stored in SideScroller for update() calls.
• Creation of a Collider abstract class which stores some rudimentary shape data, like position and rotation, bit-masking for quick collision detection, collision data, and some common collision methods. During initialization, it will register itself into the PhysicsEngine singleton, and un-register during destruction.
• The collision calculations would be made inside each interested collider, as there could be many different collider shapes and collision logic depending of the concrete implementations.
• Each class interested in having collision detection would need to store a concrete Collider object or list of objects, and move it along with them (as there is no common transform to move it automatically).
• Switching the commonly used collision logic of non-static objects into these classes, and delegating the pre-calculation of collision data to the PhysicsEngine class, such as each interested class that stores a concrete Collider class can quickly access to the collision information stored in each of them (All colliders colliding and collision normals).
• The PhysicsEngine will do some pre-calculations for each shape defining some grid-based bounding for quick collision detection (filtering the Colliders by distance). These bounds would be stored inside the Collider and recalculated each time it moves inside or outside a cell, to avoid unnecesary processing.
• Tile-based collision data would be supported as it is now implemented, so it wouldn't be necessary to define a new Collider for each tile present in the scene.

Things left out from this refactor, left pending of implementation:

• Other collider shapes beyond the standard RectCollider.
• Collider shape truncation, so it isn't necessary to calculate for each of its bounds.
• (Possibly) collision detection for rotated shapes.

Please, do tell me if i'm missing something or any suggestion, i'll be working on it shortly.

This is for artist. We need to draw a death animation for the player.

Currently, there is no way to load the game other than setting the map within the code. A loading menu to load levels within the game would be quite useful for testing. I can handle this at the moment. In addition, a tab system to work for any window should be implemented, and since this will be first built in with the load and save menu, I can handle this too.

public class Multiplayer {

	/**
	 * A client connects to a server and sends data back and forth.
	 */
	private Client c;
	/**
	 * A server sends and receives data to and from its associated clients (other
	 * programs connected to it)
	 */
	private Server s;

Names like c (as per client) and s (as per server) must be avoided since code readability is reduced. I'd go for a full code base review.

The audio in the project is handled by the Minim library. This library is yelling errors at runtime. The sources of the errors are unknown and a solution must be established to fix the errors.

Here are the errors:

=== JavaSound Minim Error ====
==== Don't know the ID3 code TSS

==== JavaSound Minim Error ====
==== Error parsing ID3v2: String index out of range: -131

==== JavaSound Minim Error ====
==== Don't know the ID3 code TSS

==== JavaSound Minim Error ====
==== Error parsing ID3v2: String index out of range: -131

==== JavaSound Minim Error ====
==== Don't know the ID3 code TSS

==== JavaSound Minim Error ====
==== Error parsing ID3v2: String index out of range: -131

==== JavaSound Minim Error ====
==== Don't know the ID3 code TSS

==== JavaSound Minim Error ====
==== Error parsing ID3v2: String index out of range: -131

• A good way to do it: In eclipse, right click on the class symbol, refactor -> rename
• File to be renamed: Sidescroller.java

Currently the scroll bar on the inventory can only be moved with the mouse wheel, I will add left click capabilities to the scroll bar.

The development and master branch has different commits. A merge without conflicts is needed.

I don't think a master\development branch distinction is needed until there's a playable build on the master branch. Until then, I think everything should be done on the master branch (and temporary feature branches)

micycle

Should be 3, not 0.3.

Add a pre-commit git hook to auto-format (and standardise) source code before a commit/PR (ie. someone's source code will be formatted to the format of the project whenever they commit).

Something like this.