rickbatka / co-op-engine Goto Github PK

This is really a placeholder for further discussion. I'm not 100% convinced any more that we will need many rectangles for colliding. Let's chat and maybe close this one out.

• An item of each type (equip, usable, miss)
• A first character
• Wall
• Tower
• Projectile
• Ground

Hurray the networking framework is done, but there's a bit of codesplosion to clean up, mainly the rampant dependencies on the networking which would ideally just act in the background as a silent observer of all things.

• Get command construction out of constructors
• Provide simple calls to create and queue commands throughout the system (maybe a commander singleton XD)
• GET RID OF DIRTY FLAG ON GAMEOBJECT, THAT WAS AN AWFUL IDEA!
• Figure out and pin down reflection based instantiation of components on game object, or switch to using names object instantiation paths through factories (it's currently straight down the middle doing a little of both)
• Provide a better helper for command creation and tagging of clientid (this should probably be wrapped into the simple call to the 'commander')

We need a better camera than one that just locks on to it's follow target, it should sweep meaning it probably has this functionality:

• Moves at a certain speed (must be faster than the locked target can move)
• Follows slightly behind target (gives more of a feel that you are moving)
• to get a really good feel, have it move faster the further it is away from the target, probably have speed be exponential on distance from target

character mechanics

• stats with temporary modifiers and durations (the stuff from effects equipped not skills)
• life and death respawn system

Problem comes from objects not being able to be inserted into a quad during a split, seems to happen most often during a notify on a collision or phys update... it's transient and deep in recursion... so yay...

Game object will no longer have a weapon, instead it will have children which can be weapons of more objects.

Things to think about:

• Should the child be updated via the parent's update, or it's own. If the child is updated via parent, it cannot live in the quad tree, this would mean other things can't interact with the child, the child can only interact with others. Other side would be that they update independently and are in the quad tree, this would have the complications of references from parent to child, resolution of who would get updated first, among other things. I'm leaning towards via parent, for it's simplicity. Either way I can come up with multiple situations down the road that would plague each decision.
• redesign of how objects are represented in the world. Game object will now have an attachment point, and a child attachment point (where it's held and where it holds). These will be represented on a per frame basis. Easiest way I can think of would be to add an origin (where it's held) and an attachmentPoint (where it holds) to the frame. This could be extremely easily implemented into the renderer as one of the overloads takes an origin (there would be some physics tweaking involved).

We should take some time and think this one out.

Games need sound! It must have these capabilities:

• Music loops, crossfade on demand
• Sound effects, able to be played on demand.

probably another candidate for a singleton or service

Decorative particle engine, important for feel

• Particle Object
• Animations on particles

Quick discussion:

I started moving the creation of game objects out into factories and it seems the factories need to be coupled to the main game for several reasons. They need to get textures that the game has loaded, they need to put the newly built objects into the quadtree, and they need to put the new objects into the lists for update, as far as I can tell.

I was thinking, then, that each factory should get initialized with a ref to the main game in the game.init (or right after loadcontent or whatever). Then, each factory can expose itself via a GameService like we do for the ActorInformationService now. This way, different places can spawn things into existence, without knowing / carinng about the guts of hooking up textures and such.

Example: inside player brain, input notices we pressed the "Build" button and we determine we are in a valid state to build a tower. We call TowerCreationService.GetUnbuiltStandardArrowTower() and it's automatically wired into the game everywhere it needs to be.

Thoughts / concerns?

hybrid client / server / ad hoc: clients trust their own events, server controls the AI. server believes clients as well. server also controls game state / win conditions, etc. server basically controls everything except physics, interactions. server holds all objects.

Animation toolset must have the ability to:

• Choose SourceRectangles from a spritesheet
• Set physics rectangles per frame
• Set attributes of each frame
• Animate through the frames automatically while file is being edited elsewhere
• Compile animation data into a game parsable file (most likely building the object structure and serializing it to a flat file)

Tower mechanics

• placement logic
• restrictions on placement (no overlaps)
• menu system
• controller support
• a few stock ones to get going

Right now I have a hack that tints the gameobject red if it's in knockback mode. Should ideally flash the sprite white, but I can't figure out a way to tint the sprite white without writing a shader.

Task is to either write a shader or figure out some other way to tint white (or decide red is good and we don't want shaders )

Towers should have state objects like players. Tower building animation can then be an actual animation in the spritesheet and we can get rid of the hack in the renderer to make it look green. Also then we can simply not have a physics rectangle during placing the tower and it won't freaking shove the player around, which will be nice.

I'll take this one.

Meet up and agree on the desired look-and-feel of the game we will make. From there we can start discussing programming language / framework and begin to scope out the project.

Lets go back and take a look at all the things we marked to do later and keep a record here of what has changed

skill system

• component to store skills and cooldowns
• state information management w/ animations and whatnot
• stock skills to get a full working character
• modifications of stats on character from equipped skills

Things that were kinda pie in the sky for the initial pathfinding system.

• Dynamic path reset timer based on queue size
• Pathing that is taking a while should get deprioritized (a few hundred, snapshot it, queue it again)
• Different heuristics based on AI type (some take into account damage, others are suicidal etc)
• If crunching is fast enough, possible include more frequent snapshots of quadtree possibly start including dynamic things like players (have enemies like saboteurs that avoid players) or have enemies move around a large traffic jam of mobs stuck down a hallway
• Possible network splitting of pathcrunching tasks

A game needs states, like views or pages (start menu, gameplay etc.)

• Gamestate system
• Start Menu
• Gameplay State

• some kind of a physics engine picked out / built
• player on screen, moving around
• game objects collide with each other

Drawing and animations have broken the physics somehow

• get elastic quad tree cells to grow with single elements again
• collisions are COMPLETELY broken, the only reason the kinda work is some unintended math coincidences(it's hilariously bad how this is currently working), so fix math.
• collaborate on drawing and physics(get each other up to speed on the components structures)

stuff needs to stick around when game is closed.

• Loading a level from a file
• loading / saving character stats

State machines live on the gameobject and can be implemented/injected like components

• game object state machine stubbed
• player state machine
• enemy state machine
• tower state machine

weapon / attack: each character has list of things hurting them w/ cooldowns. cannot get hit by the same thing during that thing's cooldown.

Regarding pathfinding for game objects. This device lives outside the game and takes requests from objects for a path to their destination, this comes from the idea that pathfinding is CPU intensive and can ruin gameplay if included in the update/render thread.

• Asynchronous object able to receive request queue and lock swap them into an active task queue
• Able to lock replace path in a game object component
• A* pathing each request based on destroyable objects
• Heuristic based on time (time to destroy objects/move distances)
• Dynamic path reset timer based on queue size
• Use snapshot of quadtree for generation(using meta objects)
• Different heuristics based on AI type (some take into account damage, others are suicidal etc)
• Have pathing grid update based on static object changes (broken walls/towers)

Possible Once Implemented Check Out

• If crunching is fast enough, possible include more frequent snapshots of quadtree possibly start including dynamic things like players (have enemies like saboteurs that avoid players) or have enemies move around a large traffic jam of mobs stuck down a hallway
• Possible network splitting of pathcrunching tasks

Needs:

• A projectile that on contact applies it's weapon effects
• This projectile is a fully built game object with a weapon of it's own.
• Weapon effect that (miss or hit) fires a projectile (the one the tower holds)
• Tower fires projectiles at a given rate
• Projectiles have a lifetime
• Functionality to hook into on hit for projectiles (later for explosions and secondary effects, I suppose this could be an effect nvm)

Bonus

• Tower has a single target it acquires on it's own
• Can only acquire targets within a certain range

• object with lower bounding box center (BoundingBox.Center.Y > OtherboundingBox.Center.Y) draws on top. This should allow player to walk behind walls, trees, etc, while also letting them come around and walk in front.
• objects with bounding boxes always draw on top of those without bounding boxes. this way players will always walk over top decorations, dead players, burnt down towers.

Game needs numbers, bars, and menus

• Menus: tower choice, skill selection
  • Controller support
• Skill buttons with apparent cooldowns and or resource progress
• Bars for stats and HUD health
• Numbers on hits?
• Health bars on enemies?

Bugs and inefficiencies are popping up and the new bottleneck is the tree traversal during collisions and notification of movement.
This is caused by the quad tree having to split and verify quite often, making it a deep tree. The remedy will be to flatten the tree to an adjustable amount.

Objectives:

• Each quad in tree needs to be able to hold multiple objects
• Max objects per quad must be adjustable
• Validate strategy that doesn't explode the tree.
• Ensure the 'we both moved to a new quad' bug doesn't transfer
• Ensure the infinisplit stack overflow has protection (maybe have it increase allowed count for each split making a fat bottomed structure)
• Uninflate when object leaves (didn't quite have time for it)

idea for validate: give quadtree an update and have it do a depth first analysis of quads removing as it traverses

EDIT: added one last little thing

Went to implement weapon knockback, and I was having trouble getting a fast knockback. Realized all movement is clamped to global movement speed limit, also realized that everything walking around right now is basically moving at that speed limit.

Because of the way physics code is written, this means nothing can move faster than the player walking speed.

we need per-object speeds, but really, we probably need per-object-per-state speed limits. I hacked in a temporary speed limit increase for weapon knockback, but it won't allow for variable knockback for stronger attacks or anything like that.

It feels pretty hacky to say, oh I need a strong knockback, let's adjust the speed limit for a few MS and then set it back after knockback is done.

Moving on to other stuff, but this needs more thought.

This AI will have the following attributes:

• Pathfinds to a certain distance from the player
• once within range, charges the player, if stuck pathfinds again
• if within range, swings weapon and attempts to hit player
• Die on death and be removed from the world

If you un-comment the camera follow code (player brain), you'll see some pretty bad jitter in the sprites when moving diagonally. I tried making sure none of the numbers are getting cast to ints (like in the set position call), they aren't.

Is the camera transform rounding to exact pixels when the player is moving in sub-pixel amounts? If so, how the heck do we get a smooth camera follow?

Actually I don't think that's it because the camera follows smoothly when only moving along one axis.

• Level object with data and components, just like game object
• Level gets set up with the map info and the proper director and stuff
• Gameplay owns the Level. Level will own the background, AI director, Game Director.

Use the menu to select a level, have the game director spit out some enemies, and evaluate a win condition.

Decorators

• "inflator" Can Grow or shrink(start/end size), start delay, time it takes to get from start to end size, be sure to use the origin as the expansion point
  • expand from center... it's not working right now
• "spinner" spins
• "fader" fades between 2 given alpha values, start delay, time from start to end

Emitters

• beam Has a circle on each end with a line in between
• "explosion" big fast expanding flash with some smoke that fades
• "spinning dust" poof that expands while spinning and moving slowly

Misc

• refactor effect application: at the time of effect application, have both parties full game objects available for the effect to take advantage of (note: leave room for subclass sandbox pattern eventually)

Edit: removed spin jitter, wasn't necessary

Object animations
Background Animations
Character state machine
CHANGING IDEA

• Decide on Snap to grid objects or tilemap
• Implement objects either snapping to grid or tilemap engine.
• Resolve collisions w/ map properly

gameplay logic

• resources awarded via kill events
• wave spawning math
• win / lose conditions
• tower cost calculation

Mainly the method of disposing objects from the world:

• Object can be placed
• Object has health constrained between min and max
• Health Affected by enemy attacks (good time to define what makes an enemy)
• When health reaches zero (or other death event) the object is removed from the world

EDITS: changed reqs to more match this objective and exclude other issues

Pathfinder is creating loops, looks like it might happen when target is switched in ai mid pathing, or when the object has been removed?..... hack in place to prevent the pathfinder from locking up so it's not gamestopping right now.

We need some basic sound assets, ones that we don't have to worry about licensing (homemade or freelance).

• swing weapon
• bloody hit with weapon
• tower shoot arrow
• arrow hits dirt
• heal zap
• death noises

game needs a dynamic camera as well as things that stay static

• Transform based camera (a singleton is a must on the camera)
• Static UI elements that live outside the transform camera

From other case
Particle sandbox tool. Seriously, how cool would it be to have a little tool where you can change parameters with sliders, click on and off the various decorators, and craft sweet new emitters. *Note! Not as trivial as it sounds, there are a few gotchas. -Rick

• Visualization tool
• Data representation of an emitter and particle, save/load
• AssetRepository integration