agoutigames/rawsalmonengine

A game engine utilising "Tiled" map files

rawsalmonengine's Issues

Actor restrucuture via inheritance

Structure the actors like the event class hierarchy

• Pros:
  • More flexible actors
  • Creating simplistic actors would be made easier
• Cons:
  • Actors could only be handled via base class pointers
  • Different actors would still need a unified interface
  • This would need extensive use of type checking and declaring of what a certain type can and can not do
  • Especially events would have to always check the actor type

Store key mapping in symbolic tileset

Links a keypress with sending a specific event to the player actor

base64 with zlib compression

• Adjust parser to decompress the map data before parsing when zlib is used

Tasmanian wolf main character tileset

For left and right direction:

• Walk cycle
• Jump until peak
• Fall after peak with landing
• Idle cycle

Multiple Hitboxes

Implement parsing of multiple hitboxes

• Hitboxes are indexed by string
• Each call for a hitbox HAS to check for validity
• String may be slower but possible enum values would be too big/ strange

Desert enemy tileset

We need at least one kind of enemy to test damaging the player.
I'm not sure what species, maybe evil kangaroos or gophers?
It would at least need walk, maybe idle and a death animation.

Store actor templates as actor objects

Instead of storing them as a custom struct, we could simply parse them as a regular actor and use the standard copy constructor (with type name functionality)

Add trigger events

• stores event - case combinations
• each trigger event evaluates a specific parameter, like "Tr_IsPlayer"
• unpacks the matching event behind it into the queue when processed
  • add event function can add an event without sorting by priority if index or pointer to event is supplied
  • priority value of trigger event effectively overrides those of the sub-events

Implement all 4 possible draw orders

• Add draw order as a static member of Layer class
• Modify the Layer::render code to support the three missing draw orders

Implement actor states and map states

We need this for our game logic to function better, so that a player with the state "duck" set to true can be interacted with differently for example.

• add to each actor and map a "vector of strings mapped to booleans" member
• add a "set_state" event
  • can set state of map or actor
  • implicitly set state of processed actor (when "actor" field is empty)
• add a "if_state" event (maybe with the option to chain multiple ifs together in one event)
• add possibility to set states upon construction via specially named custom properties of the actor (STATE_DUCK | TRUE) for example

Layers with inheritance

• Split up the image-, tile- and actor-layers in seperate classes
• Make them inherit from a common "Layer" class
• Manage individual layers by using pointers to "Layer" class

This saves some memory and makes the code less bloated and easier to understand.

Add Event: ate_single

This event wraps another event and makes sure that the contained event can only have one instance in the event pipeline.

• First, block this particular event and the contained event
• If boolean "purge" is set to true: Delete other instances of this event or the contained event
• Process the contained event
• If the contained event ends or aborts, unblock the formerly blocked events

Decrease verbosity of parsing methods

• Decrease duplicate code to a minimum in the parsing methods (somehow reuse the code)
• Especially property parsing should be handled better/ compact

Parse events and store by name

Parse:

• If tileset is symbolic, check if name of tile matches event type
• Parse the event by its "tile" properties
  Save:
• Store in a container located in MapData Instance
  Use:
• Make events linkable in key mapping and actor event slots

Scrolling parallax background

To establish a kind of 3d-feel we can use slow scrolling background images.

• The scrolling speed depends on the size of the image. It always reaches the rectangular borders of the map. The smaller the image, the slower the scrolling and vice versa.
• Since this simple method of the effect depends on the map borders, the camera should be restricted to those (yet to be implemented!)
• This kind of background should be implemented in the .tmx file via an image layer with the custom "PARALLAX" property set to true.
• Seamless backgrounds are not possible this way.

Implement sound + music via events

For a proper game we definitely need sound which plays when certain circumstances meet (get hurt by enemies, jump, land, bark)

• Sounds are packed as events, so it's probably wise to bundle them with other events via the "Multi event"
• A "While event A, do event B" event would be awesome, so a sound can stop if an event aborts preemtively
• The option to make the sounds volume and pan positionally dependant would also be great
• When all possible sound events get parsed, an extra class should be instructed to load and hold the files
• The loaded sound file itself shouldn't be bound to the event, the event should only point at it
• Music works the same way, only difference should be the repeat option and maybe the option to set a starting music in the custom properties of the mapfile itself

Add multi events

• stores multiple events in a sequence
• unpacks its events behind it into the queue when processed
  • add event function can add an event without sorting by priority if index or pointer to event is supplied
  • priority value of multi event overrides effectively overrides those of the sub-events

Normal based lighting

• Low priority due to this being a really ambitious goal which definitely needs an opengl context
• Every tile needs a 3d/rgb normal map
• Light sources need an additional height value
• The light is blended through the individual normal maps by its direction and height and this creates a quite realistic looking fake 3d effect
• Use flat lighting if normal maps are not present

Change game timing

• Currently many methods rely on frame based timing, rather than time based
• Change all occurences of frame based timing, to time base (if possible)
• Comment all possibly different program behaviour

Flat lighting

• Create light source objects and/or tiles
• Create the most basic kind of lighting which takes the direction of the light source into consideration
• Create a really basic shadow shader

Add trigger frame to actor animation

Often an event should be triggered when the animation passed a specific frame.

• Parse this specific frame in the Animation tile.
• Save this frame as "float m_speed" to reuse this here not needed variable
• Implement function to determine if the frame just passed

Improve player event structure and input events

• Currently the player movement is a pretty rough hack via a public var
• Rewrite so that the SDL events are passed to the gameinfo object and processed there
• Maybe implement key mapping via config file
• Maybe translate SDL keypress events into refined game events

Desert'ish background image with sky and sun

Can be bigger than 1920x1080, so we could try some basic parralax mapping.

Implement Tile Types

To make player interaction easier, plain tiles should have, just like actors, a kind of type associated with them.

• To match their actor counterparts, tile types should be stored as a plain string var
• The "cause" value of events holds tile ids, so that extraction of tile types is possible
• Also add a method extracting type of tile id, no matter if its actually an actor or a tile
  These steps should make the implementation of "slippery" tiles, deadly spike or fire, etc. much easier.

Cut string comparisions to a minimum

Currently either the types are hardcoded enums which a user can't expand by themselves, but they are running reasonably fast, or the types are plain strings which can be introduced via the Tiled GUI, but run slower. We need a solution in between!

• Con String: its slow
• Con Enum: You can't print readable output (it only says "animation state: 3" or so) and a end user can't introduce new types without touching code

Better would be a slim class which mainly acts like an enum(no string comparisions) but has a lookup function for spitting out its "real" name for debugging purposes. The type names could be either introduced via a text file or dynamically while parsing the map file.

Desert tileset with australian plants

A basic one will do, but can also be fancier :-)

Actor events

• The heart of the game logic will propably reside in these events so beware
• We need an event class which somehow can hold all types of possible events which can be exectued by the corresponding actors ingame (will inheritance help me here?)
• Every actor needs some kind of event pipeline which it processes with each update call
• Each event needs a variable which stores its priority; needed for correct event execution order
• Every actor action should be event based, even the most basic stuff like walk right

Implement "spawn actor" event

• The event should spawn an actor at the supplied coordinates
• Position relative to the triggering actor should also be possible
• Implement a check after parsing if the actor to be spawned exists
  This spawning should make shooting fireballs and such possible

Collision detection

• Create a function which checks for colission of an actor with the surrounding tile hitboxes and returns a vector of const references to the colliding tiles
• Create a function which checks for colission of an actor with another actor and returns a vector of const references to the colliding actors

This is important to get those actors finally walking

Collectible tileset

We need some kind of collectible to test the colission with the player.
The choice is up to you :-)
It would be great if it could have an idle animation and/or pickup animation.

Add parallax background layer 2 (first tree area)

The second fastest layer should be various trees to enhance the impression of depth.
Different exemplars of the ten most common Australian trees. Acacia, for example, and eucalyptus, of course. This layer runs a little slower, so details are more important. I'd like to see some fun detail. Birds, for example. A Cockatoo here and there... such things.

Specifications:
- Look: Common Australian trees, in different variations, preferably without much repetitions.
Complemented with cute funny details.
- Size: 7000 x 1800 px
- Format: png

Add Event Slots: OnSpaw, OnLoad

On some occasions we need an event only once, upon construction of the object.

• For Actors simply add the OnSpawn event slot and initialize the event pipeline with this event.
• For the Map this is the first event slot at all, make sure to also add the OnAlways slot.

Add parallax background layer 1 (grassy things)

The fastest moving layer should be tall grass and little bushes passing behind the player.
Typical grass as a good reference to the Outback. Spinifex for example. 😺

Trees belong more on layer 2 and 3, which is why we prefer small, dense plants here.

Specifications:
- Look: Spinifex Grass or similar looking.
Dried-up grass and fresh green. Mixed.
- size: 12000 x 2000 px
- format: png

Add parallax background layer 3 (second tree area)

Trees further away are to be drawn on this layer.
The scroll speed is slower, but the trees are also smaller.
That's why the details aren't so important.

Basically the same tree types as on layer 2, but smaller.
Interrupted by grassy plains and sandy areas.

Specifications:
- Look: Common Australian trees, grassy plains, sand, some rocks and stones.
If possible create an illusion of depth, a view into the far distance.
- Size: 4500 x 1500 px
- Format: png

Can't have multiple maps simultaneously

• Important data is currently saved as static inside the Tile Tileset and Actor class
• This makes having multiple maps functional at the same time impossible
• Fix this by moving the relevant data inside the MapData class and reference to it inside the posessed class objects

Add actor event "slots" for standard interaction

If something like a colission between actors happens, a specified event could be triggered

• Possible slots:

  • on_collide
  • on_activation
  • on_hit
  • on_death

• As a result we need an "add_cause" method which adds a pointer to the actor which triggered the event.

• For pointer consistency the actors in the actor layer should be stored in lists rather than vectors.

• Events which use this "cause" functionality should always have a nullptr case.

Event processing returns signal

Instead of a bool indicating if the event's processed, the event could return a enum which can also tell if the next event should also be processed or if the event processing should stop here.
The default signal should also be parsed (and if not it should be probably "next")

Signals:

• next
• stop
• end

Rebuild camera as a complex type

• Camera knows the map size and can check if it's over the map border
• Camera knows the player and can follow her/him itself
• Camera now belongs to mapdata and not to gameinfo
• Camera position can only be set via methods and not manipulation of members

Implement "logic" events

For our major game logic to happen, we need a handful of events which wrap other events and trigger them if a certain condition is met. For example:

• "Play Sound X as long as event Y doesn't abort"
• After collision -> Trigger event X if the cause(tile or actor) is of type Y, else trigger Z
• If event X runs successfully trigger Y else if event Z... else, and so on

This means we need a couple of events:

While Event

• As long as event x runs, also run event y afterwards. If x aborts preemtively, also abort y.

If, Elseif, Else Event

• Simply chain events together via If, Elseif and Else. A Successful completion means true, abort means false, next means that no evaluation happens. (But there should also be an option so that next means false as long as no evaluation can happen (so the else and elseifs could be triggered sooner))

If Type ==, Elseif Type ==, Else Event WIP Name

• First implement a "isType" Sub event which successfully ends when the cause matches the given String type, else return abort
• Then we can use the "normal" If, Elseif, Else Event and use the "isType" as condition for the Ifs and Elseifs
• This is made possible because all kinds of multi events, (including logic events since these also hold other events) inherit the cause object of the "mother event".

CSV Map encoding

• Implement a parsing algorithm for this

actor masking by oversized tiles through intertwined rendering

• Use the Tiled layer groups for determining which layer is intertwined with the actor layer
• Create a special render function which intertwines the tile rendering with the actor object rendering

We need this so the player can walk behind a tree or a house and not in front of it

Add parallax background layer 4 (far distant mountains)

The slowest layer should be reserved for things on the horizon. Mountains and hills. Everything that makes up the real Australian horizon. Even the sky and a few little happy clouds too.

Specifications:

• Look: Mountains in the far distance, with sky, clouds, some birds drawn in a suggestive way.
• Size: 3000 x 1300px
• Format: png

Background color

Use the background color which gets supplied via the .tmx file.

Isometric mode

• Add Map orientation type as a static member of Layer class
• Modify the Layer::render code to support isometric tiles

Implement "change_map" event

• The supplied parameter should be the name of the .tmx file
• We don't need the transfer of data between maps yet

Event Cooldown

Add map container matching event type string and timestamp in actor
Event process function can optionally use this data for implementing a cooldown

Add basic actor events for demonstration purposes

Events to be added:

• go to x,y coordinate via mouse click
• play specific animation (attack a direction)
• A basic text box event would be great!

Introduce MapEvents + Integrate with ActorEvents

Map Events should drive everything whats map/game related, for example:

• Change Map
• Change Sound Volume
• Move Camera/ BindUnbind Actor to Camera
• Quit game

These events should lie in the pipeline of the map and be processed just like Actor Events. How do we do this?

• Either Reuse the ActoEvents somehow (difficult, have no idea how, maybe templates?)
• Or Copypaste most of the code and change "Actor" to "Mapdata"

Next Problem: An Actor should could also trigger MapEvents but how?

• Either through some kind of casting, so that the Actor somehow drives the map (nah)
• Or Wrap the MapEvent inside a special kind of ActorEvent which does nothing but sending the MapEvent to the EventPipeline of the Map (sounds good)

MapEvents should be processed after all Actor Events are processed

Clean up actor collision code

• Currently the collision methods bug out when the rect width or height is below the pixel step
  (about 10px with a maximum actor speed of 500px per second), fix that with a better algorithm!
• The performance is probably als not as good as it could be
• Bugs when actors are partly or completle outside of map boundaries

Store actor type in object

• Store the gid of the actor template tile in the actual actor object
• Implement method which returns string of the actor template name (aka type)
• This enables stuff like fetching all coins or frogs on a map