Bolero Planning: Difference between revisions
No edit summary |
No edit summary |
||
Line 55: | Line 55: | ||
✅ '''[Scenes/Actors]''' I need some way to cache or memoize handles to other actors. | ✅ '''[Scenes/Actors]''' I need some way to cache or memoize handles to other actors. | ||
* Added a way to refresh handles on a per-tick basis by verifying the target actor's serial number. It won't scale well if hundreds of actors search for an actor that isn't present in the list, but should be OK for now. | * Added a way to refresh handles on a per-tick basis by verifying the target actor's serial number. It won't scale well if hundreds of actors search for an actor that isn't present in the list, but should be OK for now. | ||
✅ '''[Scenes/Actors]''' Need a system to automate actor-to-actor collision checking. | |||
* 29/Sept/2019 Actors can now opt into a per-tick overlap check. The scene tick function informs each opted-in actor of which other opted-in actors were overlapping it at start-of-tick. It's lacking spatial partitioning, so it won't scale well, and it has no context for how the collisions should be resolved. | |||
⌛ '''[Scenes/Actors]''' Early versions of the engine had a simple message stack system for sending messages between actors. Re-enable and finish this, and add support for sending messages across scene boundaries. | ⌛ '''[Scenes/Actors]''' Early versions of the engine had a simple message stack system for sending messages between actors. Re-enable and finish this, and add support for sending messages across scene boundaries. | ||
Line 61: | Line 64: | ||
'''[GFX/Window]''' Functional fullscreen (canvas needs centering IIRC) | '''[GFX/Window]''' Functional fullscreen (canvas needs centering IIRC) | ||
Line 82: | Line 83: | ||
❓ '''[I/O+Conf]''' Debug: Save / Load game state | ❓ '''[I/O+Conf]''' Debug: Save / Load game state | ||
* 27/Sept/2019: Putting off for now. Need to distinguish between the game state and the overall engine state. Would savestates include the engine configuration as well, and user-facing save-games in memory? Also need to consider whether this should be exposed to the end user, or require them to enable some kind of developer mode. | * 27/Sept/2019: Putting off for now. Need to distinguish between the game state and the overall engine state. Would savestates include the engine configuration as well, and user-facing save-games in memory? What about the state of the sound module? Also need to consider whether this should be exposed to the end user, or require them to enable some kind of developer mode. | ||
❓ '''[I/O+Conf]''' Need to ensure that Unicode is handled correctly when strings are pattern-matched. LÖVE accepts UTF-8 strings, but strings in Lua itself are not really Unicode-aware. | ❓ '''[I/O+Conf]''' Need to ensure that Unicode is handled correctly when strings are pattern-matched. LÖVE accepts UTF-8 strings, but strings in Lua itself are not really Unicode-aware. |
Revision as of 11:43, 29 September 2019
Bolero is a 2D game engine, currently under development for the LÖVE Framework.
This page tracks development progress and is intended to eventually provide a rough schedule towards completion. Eventually, this info will be shifted over to a dedicated wiki.
Legend
✅ Complete
⌛ Pending, in progress
❌ Cancelled, decided against
❓ Unsure, implementation issues
Task List
2019
September
✅ [Planning] Get this roadmap started :)
✅ [GFX/Windowing] The engine has rudimentary support for multiple per-scene viewports with their own scrolling rules, but I don't think I can fully flesh that out right now and also get a game finished. So turn that stuff off.
✅ [Scenes/Actors] Finish generic actor-to-tilemap collision and platform movement handling
- 'Finish' probably isn't the right word, but there is now a generic platformerTick() that multiple actors can now use.
✅ [Scenes/Actors] Fix issues with sloped terrain
- This required rewriting the collision and platformer movement systems, and implementing a navigation layer / cache.
✅ [Scenes/Actors] Get the spinnyboys rolling up and down the hills
- Still a bit buggy but the overall effect is in place.
✅ [Scenes/Actors] Build up method calls for actors to simplify programming them.
- Started doing this, and also added methods to scenes as well.
⌛ [Scenes/Actors] Make a camera / scrolling / scene transition manager.
- ✅ Target-to-follow
- ✅ Scroll boundaries
- ✅ Fade-in / Fade-out transitions
- The functionality is in, but it really needs to be refactored.
✅ [Scenes/Actors] Revisit actor creation and removal functions, with respect to how they affect Lua garbage collection, and how the order of actors in the array can cause subtle bugs.
- ✅ Stat order: Run actors according to a separate sorted array.
- Done! There is now an actor_order list which is used as a stat order. Now when an actor is initialized in a recycled table in the middle of the pool, it's still added to the end of the stat list for processing and drawing.
- ❌ Garbage accumulation: I'm thinking I probably shouldn't worry about this right now. I'll come back to it if I suspect it's causing performance problems.
✅ [GFX/Window] Fix sprite-to-actor alignment issues when sprites are flipped horizontally or vertically
✅ [Scenes/Actors] Fix issue where scene can be rendered for one tick before it has been properly initialized. When this happens, the top-left of the map is displayed with no actors.
- Mitigated by forcing scene creation to run one tick before returning.
✅ [Scenes/Actors] I need some way to cache or memoize handles to other actors.
- Added a way to refresh handles on a per-tick basis by verifying the target actor's serial number. It won't scale well if hundreds of actors search for an actor that isn't present in the list, but should be OK for now.
✅ [Scenes/Actors] Need a system to automate actor-to-actor collision checking.
- 29/Sept/2019 Actors can now opt into a per-tick overlap check. The scene tick function informs each opted-in actor of which other opted-in actors were overlapping it at start-of-tick. It's lacking spatial partitioning, so it won't scale well, and it has no context for how the collisions should be resolved.
⌛ [Scenes/Actors] Early versions of the engine had a simple message stack system for sending messages between actors. Re-enable and finish this, and add support for sending messages across scene boundaries.
[Widgets] Full options menu tree. Need to improve the widget system in order to do this. Selection boxes, "OK/apply/cancel" buttons, scroll boxes, etc.
[GFX/Window] Functional fullscreen (canvas needs centering IIRC)
October
(Pending further planning)
November
(Pending further planning)
December
[Planning] All engine components necessary to finish the game should be operational
[Planning] Get some kind of engine demo out for feedback
I need to do these, but no timeline scheduled
❓ [I/O+Conf] Debug: Save / Load game state
- 27/Sept/2019: Putting off for now. Need to distinguish between the game state and the overall engine state. Would savestates include the engine configuration as well, and user-facing save-games in memory? What about the state of the sound module? Also need to consider whether this should be exposed to the end user, or require them to enable some kind of developer mode.
❓ [I/O+Conf] Need to ensure that Unicode is handled correctly when strings are pattern-matched. LÖVE accepts UTF-8 strings, but strings in Lua itself are not really Unicode-aware.
- 27/Sept/2019: In the codebase, string operations are limited to parsing the config files and command line arguments, and processing internal error messages. This is probably something to revisit later on once the engine has more substance.
- 28/Sept/2019: LÖVE has a copy of the Lua 5.3 utf8 library which can return the correct offset for a UTF-8 character. I added this Lua UTF-8 string library to the external libs as well.
Off-limits for now
❌ [Audio] I'm really interested in sound synthesis through queueable sources. Maybe next time.
❌ [Audio] Music / ambiance cross-fading, same as above.
❌ [Tools] Asset editors for animations, terrains, envelopes and other engine constructs. They would be nice to have, but I can get by with defining them in code for now.
❌ [GFX/Windowing] The multiple viewport stuff, as mentioned above. Though, it would be fun to give each viewport its own canvas and do zooms / rotations / stuff like that.
❌ [GFX/Windowing] The drawing code should probably use love.graphics.translate() to position draw calls, but the game seems to be running well enough right now. Revisit if this is determined to be a performance bottleneck or causing some other problem.
Unsure
❓ [GFX/Windowing] Shaders. Not sure if I need them right now, or if I should completely hold off. Will revisit when I have more work done.
❓ [Scenes/Actors] Need some kind of space partitioning to limit the number of collision checks between actors.
- 28/Sept/2019: Don't go after this until there's a clear performance need to do so. The engine is running fine with 100 actors right now.