A demo featuring AI, Collision, and other features from the 2D Nickel RTS Game Engine.
- Combining multiple behaviors in autonomous agents
- Various steering behaviors (seek, flee, wander, obstacle avoidance, etc...)
- BOIDS steering behavior (align, separate, cohere)
- Theta * pathfinding
- A * pathfinding
- Dijkstra pathfinding
- Line-of-sight detection (used by Theta * algorithm)
- 2D collision detection with separating axis theorem (polygon to polygon)
- More 2D collision detection with circles, polygons, rays, lines, & points
- 2D collision resolution (without rotational resolution)
- Quadtree for collision optimization
- 2D Particle effects (in this demo: smoke, fire, jet, falling ice)
- Buffer optimization for particles
- Custom UI
- Debug visualizations (some steering vectors, quadtree, collisions, etc...)
- Editable tilemap
- Advanced parameter control of most aspects of the demo
- If the sight line ends up at an intersection of 2 avoid circles, agent may get stuck: to fix this, we would need to scan all obstacles in the scan area and create a new convex avoid surface.
- Game objects are quite loaded with functions and variables, causing major slowdowns with just a few objects: to fix this, we can separate static-abled properties from individual game objects into static classes.
- The UX is not as intuitive as it could be, users may get overwhelmed on first look at all the options: to fix this, we revamp all the options and place them next to similar options, and fit advanced options in dropdown menus or dialogue boxes that would pause the simulation.
- Looking underneath the hood, we see many areas of the code to be quite messy, this is because this demo and many parts of the Nickel library were hacked together with little to medium attention to software design, but with greater attention to specific algorithms. To fix this, we could separate game data and logic, then have an MVC style approach, except the controller would be split into multiple parts, where each part would handle a crucial portion of the game loop as well as initialization, and the model would be simple .json files filled with object data. So now if we wanted to create a game using the engine, we could simply add modular structures to the controller and the view, and easily setup our game data in .json files. Along with this high level architecture, we should also make use of some design patterns. For this, we should focus on using the pipeline design pattern with the different parts of the controller. Using abstract modules will also help to allow more extensibility. Since game objects, more often than not, are tangled with each other, we can allow users to inject custom scripts into game objects to manipulate them easily. Since this is JavaScript and not C++, it is too easy to inject variables and whatnot into JavaScript objects, so we would have to devise a way to discourage that and utilize the game objects bulit-in script injector system instead. This is a summary of what the architecture can look like after some improvements.