nickiannone / spookhouse Goto Github PK

Implement walls and a grid system for the game world. For now, focus on making it visible with simple lines rendered in the Draw step of the level, after the background and before the Animation subsystem, at a huge z-depth. Make a system which allows for wall creation and destruction, and generates a map of passable areas that can be fed into the future AI system.

Goals:

• Create Grid class (represents the grid itself, contains walls, renders to graph/bitmap, contains algos for mapping world -> grid and grid -> world coordinates)
• Create Wall abstraction (class? bit in bitmap?)
• Implement BSP mapping or similar tech to define separate rooms/doors in graph/bitmap
• Implement algo to determine which room a world coordinate is located in
• Create new prototype which allows for simple creation and deletion of rooms, and dynamic rendering of grid

NOTE: This may be subject to dramatic changes! The dual concept of walls/grid cells and rooms/doors is very important to lighting, AI, and input, and it should be done right and efficiently!

Implement a Renderer subsystem which sits between the world-level coordinate system and the Gosu screen-level coordinate system. This will consume AnimBlocks produced by the Animation system, as well as managing draws of future lighting and UI stuff, and perform all rendering to the screen. It will also provide translation between screen and world coordinates, for purposes of user input, and zoom and pan operations on the game level. Future modifications will allow the UI system to capture inputs such as keystrokes and mouse events, or pass those on to the level for resolution of character selection, prop placement, wall creation, etc.

Goals:

• Create Renderer class
• Create constants for z-depth ranges (background, world, menu, overlay)
• Implement level of indirection between screen and world coords (both XY-offset + depth + scaling & screen clip box)
• Write algorithms to map screen to world coordinates (both XY and Z-depth)
• Write draw method to consume AnimBlocks and render them at the appropriate depth, scale, and location (also clip blocks outside the screen!!!)
• Implement simple pan/zoom controls (possible smooth pan/zoom over time via Update instead of instant pan/zoom?)
• Make Levels use the Renderer system to draw to the screen instead of doing rendering itself.
• Pass input through the Renderer to get world coordinates.
• Create prototype level with world-level click targets, and panning and zooming.

Implement the base classes and animation system, and get a simple prototype running.

Goals:

• Implement animation system prototype, based on what is described in /docs/animation.md.
• Create a stick figure Mesh.
• Create stock skin assets.
• Create a simple AnimSet consisting of "Idle_RightForward" and "Walking_RightForward" animations, with a couple of frames each.
• Create an AnimatedObject which uses the Mesh and AnimSet.
• Bind some keys to switch back and forth between "Idle_RightForward" and "Walking_RightForward".
• Implement an FPS counter to render to the screen.
• Hook up the animation system to the GameWindow, and start rendering.
• (Optional) Add pause, slowdown, speedup, and reverse controls.

Implement an AI goal/pathfinding system which consumes the grid system's room output, a character's current location, and a goal, and produces a path to move the character to the goal. Should produce incomplete path after a certain point, or if the goal is not found. Implement path-following logic which runs on the character's Update step.

Goals:

• Create Pathfinder class
• Incorporate goals into Grid system for room resolution (exit sign?)
• Implement time-constrained path resolution given grid system output and current location
• Create Actor class which invokes Pathfinder when searching, and consumes the path while moving. Log when the actors are searching, moving, or lost (visual indication?)
• Update room-creation prototype to spawn Actors which move through the rooms and attempt to reach the end goal.

NOTE: May experiment with crowds-based AI pathfinding with hinting and contextual analysis of environment as opposed to simple A* pathfinding, since haunted house movement is crowd-and-environment oriented, involving a group of people looking around for either an exit or arrows on the walls, and starting with the leader, coming to a loose consensus on where to go next. However, this won't come until later, and for now, A* to the goal will get a prototype out the door.

Implement the basis for a Level class, and build game logic into level implementations instead of the game window itself. Goal is for modularity of game environment, so we can create and destroy levels and test out stuff. Might also serve as a home for the resource loader, so we can throw away assets we don't need when levels are unloaded (and avoid a singleton loader!)

Goals:

• Create Level class, which provides similar functionality to Gosu::Window.
• Modify resource loader to be constrained to the Level object (with portability of assets between level loads/unloads)
• Add events for loading and unloading level (to be overwritten by implementing subclasses)
• Modify the GameWindow class with ability to load a new level (including binding and unbinding window events)
• Reimplement the animation test prototype from Issue #1 as a level subclass.

NOTE: We're not focusing on serialization of level files just yet; that will come in Milestone #2. This class represents the in-game model of a level. For now, it will also contain game state.