mrnex / noble-experiment Goto Github PK

For some reason the quit button hit box seems to be registering collisions 30px above where it should be. I have a hunch as to why this is happening and I think it's because mouse positions are handled in window space, not panel space. Will attempt solution soon.

Replacing shopkeeper with wind animation for testing.
Only first two frames play before looping to the beginning.

queueAnimation() called on line 74 of state.object.ObjectShopState

The framework is there. We need more enemy states that attack in different ways, we need more projectile states that have different patterns of flight.

You can see how EnemyState and ProjectileState were made for reference

Currently objects in battlestate are handling their own collisions, while objects in overworld state adhere to the collision manager's rules. We must standardize the collision manager and change objects in the battlestate to work with it instead of handling their own collisions.

When the user holds 'shift' and presses '=' in order to get '+' on the main keyboard, the '+' is not recognized.

Additional concern: Since '+' is not recognized when entered in this manner, the HUD does not show the '+' in the equation.

Steps to reproduce:
Run game
Run player into enemy
Select enemy or projectile equation
Type an equation using the addition operator using the '+' from the main keyboard, not the numpad.

In EnemyScatterShotState's update(), calling shoot() more than once causes newly created projectiles to halt and not travel across the battlefield.

This code:
for(int i=0; i<numBulletsPerShot; i++){
shoot(attachedTo.getYPos() + (50*(i-1)));
}

Replaced with (for time being):
shoot(attachedTo.getYPos() + 50.00);

numBulletsPerShot = 3;
Intended result: 3 projectiles with differing yPositions of +/- 50 are created at the same time.

Some states imply that their attached gameobject should be able to be targeted, such as Entities while battlestate is running. There should be an astract sub-class of state for states which implement a standard set of targeting / submission methods.

This is where the submitting of equations and answers will take place.

I recently went and did error handling in the battlestate section of the game. Please try to break battlestate with detailed reports of your actions, steps to reproduce bugs, and stack traces (if necessary).

Need to know if battlestate is completely error free (Probably not) or still somewhat broken (Probably).

Commit of un-error handled code:
fe3a245

I'll handle the player script, kind of messy.

We need a way to read in and store images

Equation Objects should be reduced to a state on an object. They should not be an object themselves. We have 3 types of objects. GameObjects, MovableGameObjects, and Entities. Projectiles, entities, have a projectileState.

The equations should be managed here. NOT in their own object.

Over the updates the state system has become outdated and inconsistent.

As of now there are two completely separate state systems, ObjStates and States (engine states). These currently do not inherit any base class and are their own classes completely.

These act very similarly, and so there should be one abstract State, with objState and EngState inheriting it and defining the two state implementations.

Further more, the state systems themselves are not only implementing completely different state classes, but they behave slightly differently.

GameObjects handle their states by the following rule set:
Any time a state is placed on top of the state stack, whether by pushing it there or popping the state above it, it's enter method is called.
Any time a state is removed from the top of the state stack, whether by pushing something over it or popping it, it's exit method is called

This is very fundamentally different from the way the engine handles its states:
Any time a state enters the stack it's enter method is called (This can only be triggered by pushing the state onto the stack)
Any time a state exits the stack completely it's exit method is called (This can only be triggered by popping the state from the stack)

These systems need to be made consistent and utilize at least the same base state class instead of being completely independent definitions.

We must discuss the two implementations and decide on the one which provides the least artifacts with preferably lower initial overhead cost of re-implementation.

All managers (now in Engine.Manager) must extend Manager base class and implement inherited methods.

I know. It's intended due to prioritization of work temporarily. I am fixing it today or tomorrow!

After defeating or losing to an enemy, ending the battle, clicking the 'Continue' button brings up an exception in main: "The method setPressed() is undefined for the type ButtonState".

Edit: it's every button that transitions to a new view

Working on getting game ready for tomorrow morning at the moment. So if anyone sees this, feel free to jump in and correct it.

Put the drawing code for the player's answer string inside of a method overriding ObjState's draw method. This will make sure it only happens when the player is in battlestate and not when the player is in overworld state.

Furthermore this reveals another design flaw: The answer string should From a pure design standpoint be drawn to the screen from the HUD. This will make sure no other object is drawn on top of the answer string. This is secondary for now, however. Because side effects are minimal and it's not a priority for now.

Error is caused due to Enemy.running without state. Will revoke access to running and make it work as follows:

If an object has a non-null state on the top of it's state stack it is running. Else it is not running.

When targetting an entity which is in a targetable state, and this entity does NOT hold an equation (There is a single number above the entities head), if the player submits an equation starting with a negative number a slew of null pointers arises.

Steps to reproduce:
Run game
Run player into enemy
Press space until number above enemies head is highlighted
submit an equation starting with a negative value (-2 + 5)

We need to create the HUD for the battleState.

The HUD can be an extension of gameobject if a template is wanted or it can be it's own class entirely with HUD objects which it contains and updates.
Except unlike most game objects it will be kept track of by the ScreenManager instead of in the Engine's current state.

This is because it must be excluded from things like camera manipulations, always be drawn in front, etc.

The HUD will need multiple states or will need to be made up of interchangeable autonomous elements in order to adjust for overworld / battlestate switching.

If abstracted, what I'd recommend, is viewing the HUD as a set of gameobjects which are always drawn on top and in fixed positions. Other than that the set behaves like normal gameobjects if you exclude the fact they maintain reference to an external variable.

Let me know what you think, Thanks!

Somebody needs to keep the GameObjects updated with relevant assets from the folder. This will need to be a responsibility maintained over time.

For reference on how you attach an image to a GameObject see this relevant commit:
789c95f

Specifically changes in the profileManager class, and where the image was placed.