| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
If an Event is adjacent to a Map boundary, then it could accidentally walk off the screen during the following circumstance: When a MoveEvent() action tells said Event to move off-screen while the Event is already moving, collision checking will be bypassed and the Event will proceed to walk off the screen, after which an Exception will be thrown when said Event attempts to move again. This bug has been fixed.
|
| |
|
|
| |
EventHandler controls when they are executed and allows MapViewGameState to poll it to see if it is currently managing any action threads. If it is, MapViewGameState should be able to prevent certain actions from occuring (unless the action thread is ParallelProcess) such as keyboard input.
|
| |
|
|
| |
As direction itself is always the same as moveDirection when moveDirection is needed, it will do fine without having to complicated access modifiers.
|
| |
|
|
| |
StepMoveEvent has an issue where an event could walk off the screen under its influence because it preformed no collision checking, due to the fact that the parent map had to be accessable to preform collision checking. Now, both event styles (unified with an AbstractEvent class that handles functions common to both styles) carries information about its parent map, provided by EventList which is in turn provided by the parent map itself.
|
| |
|
|
| |
startMoving() wasn't exactly a fit enough name for the method, so it was changed to nextMovement()
|
| |
|
|
| |
Previously, GameCharacter (HeroEvent's backend) stored it's graphic as a graphic/offset combination. However, the EventGraphic class is the correct way to store it.
|
| |
|
|
| |
Previously, Map's checkForCollision did not properly check collision and would allow an event to initiate movement to a location another event was already moving to (but wasn't at yet).
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
