cyanskies / hades Goto Github PK

• sync and serialisation of curves
• curves can tag themselves as trimable at the cost of being able to save replays(client can trim and let server hold the full data)
• Save/load mechanic
  • Saving of curves and objects on a low level

This header should provide support for debug info overlays to be rendered on top of the game.

with the assistance functions
overlay* CreateOverlay
DestroyOverlay(overlay*)

need to catch invalid_argument and out_of_range from std::stoi

A few components have been developed in ortho that need to be brought back into line with hades

• parallel_jobs
• transactional_map
• value_guard
  • shared_guard
  • transactional_guard

Change the input loop to skip input if the GUI used any of the input events?

Make tile_work and terrain_work thread safe, by only accessing the datamanger through const or by sharing a shared_ptr to a mutex they both use.

current impl causes a race condition.

Seek won't necessarily work for example.

Support a hard-coded file/name manifest.
files added to the manifest by the engine are in the /common directory
files named in the C++ manifest are expected to be in the root /game directory
files in the scripted manifest are expected to be in the same folder as the manifest file
example
define the manifest.
all files will be loaded and kept in memory after this point
in main() { //it is a total failure for a manifested file to be missing resource.addtxture("texture_tank", "filename"); }

before the game starts, assign all the files from the manifest global names, so they can be referred too.
scripted manifest item will have global names generated.

struct textures { //manifested files are read only const texture tank = resource.texture("texture_tank"); }

manifests should support adding extra stuff too, like unique identifiers for game elements, or yaml for new units?

manifested types should contain extra info to easy their use.
textures -> expected dimentions
audio - > expected length

custom asset types will need to implement loadfromfile/loadfrommemory

class asset : public resource::baseAsset {}
//before reading manifests
auto assetTypeId = resources->register asset type("typename", loadfilefunc, loadmemfunc);

//for a compiled manifest(in hadesmain)
resource->addCustomasset(assetTypeId, "name", "path");

//at the start of the gamestate
asset* custom= resources->(assetTypeId, "name");

custom types must be registered before loading any assets. or external manifests

Add support for a built in server with connection and curve syncing functions

a server consists of a Server/Trunk and one or more server/branches.

only one trunk can be run at a time, and a client can only connect to one trunk.

branches represent sub-instances of the game, like different areas in diablo2. branches may communicate with each other through the trunk. and the trunk may be responsible for data that is persistent between branches(such as player data)

yaml dependencies need to be checked before they can be assumed

add support for scripted components and systems. these will be running in angelscript.

they should be able to be specified by manifest.

Zero == zero should equal false

current implementation is overly complicated, and blocks out a few needed abilities.
we should be able to replace the curvemaps in GameInstance and the spritemap in Gamerenderer with transactional maps instead of maps of value_guard. after all thats the point of transactional map

includes a few simple terrain generators:

• fill with terrain type
• fill with random terrain from terrain list(avoiding incompatible transitions)
• fill with random terrain shapes from terrain list(as above)

also includes functions for drawing terrain straight onto vertex arrays without a tile map:

• draw vertex(size, terrain)
• draw tiles(size, terrain)

A ninepatch class similar to this: https://github.com/Hapaxia/SelbaWard/wiki/Nine-Patch

should make doing a lot of gui stuff easier.

This is basically for tasks that have been ejected from the Hades 2 target.

• support travel between separate maps; this would be done with a decoupled server system.
  • This must be done without shutting down the first map, allowing players to be connected to difference logical servers, with their own map, but still sharing the same shared campaign and player state
  • these need to be actually separate unlike the current system
  • allow connecting to multiple of these at once(ie. pip of a player on a different map)
  • this will allow us to use more standard layer systems(like Link to the Past)
  • server must be able to spin up sub areas as scripts attempt to access them.
  • should also allow for sub areas to be shut down once all players leave.
• Investigate 3d rendering primatives( sf view, sf vertex)
• scripted systems
• network support, both local and internet rendering.
  • curves must be automatically synchronised
  • client side will have to deal with how to interpret them
  • being able to have more automatic serialisation and synchronization of network data and commands?
  • network sync would be a property of curves
  • only sending needed data again, hiding non-local entity updates
• In game cut scenes( this will require scripting to be completed
  • For rts, just a queue of orders and callbacks should work
  • for other games alternate actor versions of entities may be required.
• Campaign support
  • Default campaign type(sequential mission list)
  • Support for a campaign header in the save file to track campaign progress
• Campaign upgrades
  • Additional Campaign types
    • Mario world connected level graph
  • Multimap travel This must allow for ending a server on one map, but continuing the same logical 'game' on a different server/map(ie. load the inside of a house and move to it, using the campaign save header to load the correct flags and so on in the new map)
  • auto local area persistence registry, saving data automatically as player moves between multimaps
• Object Editor
  • Support drag select of multiple objects
  • Support movement of group of selected objects
  • Allow editing of common curves for multiple selected objects

either wait for sfml to support this directly or add the following features.

• view with 3d coordinates and rotation
• verticies with 3d coordinates

Load unloaded resources the first time they're requested with get<>()

We'll need to add TGUI loaders for image, texture and font types, so that tgui themes will work correctly with the data manager.

Current linux blockers:

• filesystem being linked in automatically(scheduled for GCC 9).
• std::from_chars supporting float conversion

This should handle cleaning passing input to game states, states register actions(like MOVE) and receive them along with context(joystick number and state, or key state). This should be exposed to the console for macro rebinding and needs to be saveable/restorable and exposed to be edited easily in game menus as well.

change refresh() to refresh(bool unloaded_only = false)

same for all the other refresh overloads

also add a clear command for the refresh list.

A collision base type, with support for comparing any of the the child types.

Axis aligned Rect,
Circle,
Point

collision_test(returns true if intersecting):

• Rect -> Rect
• Rect -> Point
• Rect -> Circle
• Point -> Point
• Point -> Rect
• Point -> Circle
• Circle -> Rect
• Circle -> Point
• Circle -> Circle

collision_move(returns a vector pointing from the objects current position, to it's final position,
this includes allowing the object to use up remaining move by sliding along no-colliding directions):

• Rect -> Rect
• Rect -> Point
• Rect -> Circle
• Point -> Point
• Point -> Rect
• Point -> Circle
• Circle -> Rect
• Circle -> Point
• Circle -> Circle

safe_move(returns the largest non-intersecting move):

• Rect -> Rect
• Rect -> Point
• Rect -> Circle
• Point -> Point
• Point -> Rect
• Point -> Circle
• Circle -> Rect
• Circle -> Point
• Circle -> Circle

collision_normal(returns the normal vector of a move that would result in a collision):

• Rect -> Rect
• Rect -> Point
• Rect -> Circle
• Point -> Point
• Point -> Rect
• Point -> Circle
• Circle -> Rect
• Circle -> Point
• Circle -> Circle

this will allow the workers to sleep in-between job batches.

ability to command a sprite to load an animation, with a fallback default animation.

an animation contains the texture reference it needs, plus all the data needed for that animation,

these are loaded from yaml

animation:
player_jumps:
texture: texture_id
length: how long the animation should last in game time
frames: [each frame is a set of 4 coordinates + a relative frame time]

This causes 500ms waits even when no joystick is being used. newer version of SFML fixes this.
See: https://github.com/SFML/SFML/pull/1195/files

currently applied to mod paths when loaded, should be applied to all file activities, in as_raw.

the result is that debug paths are erroneously applied to usercustomdirectories like %documents%.

may be due to false loading of non-present (0,0) textures for missing files.

a sprite batching system, needs to manage different groups of textures/sprites and support automatically moving a sprite between batches, if it's animation isn't on a single texture. with some form of key for accessing the sprite.

Probably should be thread safe as well. as it would be modified by the client controllers.