Bolero Planning: Difference between revisions
(todo: implement more game state stuff) |
(Putting this page on hiatus) |
||
(4 intermediate revisions by the same user not shown) | |||
Line 2: | Line 2: | ||
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. | 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. | ||
'''31 Oct 2019: Note! I've decided to put this page on hiatus, as I now have just enough engine components finished to comfortably work on gameplay stuff. I may come back to this for version 3 of the engine. In any case, weekly project updates will continue on [https://rabbitboots.com/blog/ my blog].''' | |||
Older content: [[Bolero Planning (Old)]] | Older content: [[Bolero Planning (Old)]] | ||
Line 19: | Line 21: | ||
== 2019 == | == 2019 == | ||
=== November === | === November === | ||
Line 57: | Line 35: | ||
❓ '''[GFX+Window]''' Once upgraded to LÖVE 11.3, use the call ''love.window.setVSync()'' to set the sync mode without recreating the window. | ❓ '''[GFX+Window]''' Once upgraded to LÖVE 11.3, use the call ''love.window.setVSync()'' to set the sync mode without recreating the window. | ||
❓ '''[GFX+Window]''' Once upgraded to LÖVE 11.3, use ''love.window.getSafeArea()'' for best-fit scaling in windowed mode to account for OS components. | |||
❓ '''[I/O+Conf]''' Debug: Save / Load game state | ❓ '''[I/O+Conf]''' Debug: Save / Load game state | ||
Line 77: | Line 57: | ||
❌ '''[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. | ❌ '''[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. | ||
❌ '''[GFX/Windowing]''' Multiple tilesets per map. Tiled supports it, the engine really should support it. (It does support multiple tilesets, just not more than one per map.) However, the tileset definitions in the engine are totally separate from Tiled tilesets, and the way that terrain definitions are referenced would have to be rewritten to support more than one set at a time. I think I should be OK with one pretty large base tileset, say 512x512, 1024x1024 or even 2048x2048, and use smaller tilesets for specific special areas. Mark this as one more item to put off for the next iteration of the engine. | |||
Latest revision as of 11:35, 31 October 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.
31 Oct 2019: Note! I've decided to put this page on hiatus, as I now have just enough engine components finished to comfortably work on gameplay stuff. I may come back to this for version 3 of the engine. In any case, weekly project updates will continue on my blog.
Older content: Bolero Planning (Old)
Legend
✅ Complete
⌛ Pending, in progress
❌ Cancelled, decided against
❓ Unsure, implementation issues
Task List
2019
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
❓ [GFX+Window] Once upgraded to LÖVE 11.3, use the call love.window.setVSync() to set the sync mode without recreating the window.
❓ [GFX+Window] Once upgraded to LÖVE 11.3, use love.window.getSafeArea() for best-fit scaling in windowed mode to account for OS components.
❓ [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.
❌ [GFX/Windowing] Multiple tilesets per map. Tiled supports it, the engine really should support it. (It does support multiple tilesets, just not more than one per map.) However, the tileset definitions in the engine are totally separate from Tiled tilesets, and the way that terrain definitions are referenced would have to be rewritten to support more than one set at a time. I think I should be OK with one pretty large base tileset, say 512x512, 1024x1024 or even 2048x2048, and use smaller tilesets for specific special areas. Mark this as one more item to put off for the next iteration of the engine.
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.