AllegroFlare is designed to be a library focused on higher-level concepts. For the most part, AllegroFlare is currently managing middle-level things like OBJ loading, cameras, object positioning, asset management, etc. Recently, AllegroFlare started introducing concepts like TitleScreen which are more higher level.
I'm curious about adding Prototypes, which are yet another level up in terms of complexity. A prototype would be a more "complete" playable screen of core gameplay. In the sense that you have TitleScreen, GameOverScreen, StoryboardScreen, you might imagine actual prototype gameplay screens like ShmupScreen, Racer2DScreen, DungeonCrawlerScreen, FPSScreen, SideScroller2DScreen, etc.
These Prototypes will be a more complicated set of code and will likely extend out much further than a single file. Even though gameplay coding can get pretty complicated, there should be some kind of simplest reduction of features that could be used as a starting point to expand into a more full-featured game. Ideally, the prototype would be somehow feature-complete, in the sense that it would only require the end developer (the person making an actual game from the prototype) to extend it with the features specific to the actual game in question.
Initial go!
In this PR, I've added an initial prototype Prototypes/FixedRoom2D a reduction of a point-and-click adventure (which is the simplest prototype I could think of). This prototype works by having you define objects in a room that you can interact with by clicking on them. (Soon should be able to add multiple rooms). Interacting with an object will fire off a script.
The prototype screen includes an inventory.
How it would be used
The design is laid out such that the end developer would extend the prototype with the following code:
New types of objects to be included in the scene (for example, a wall clock that ticks in the background)
Create new commands for the script
Create new objects for each script command that would contain the script command's data (derived from AllegroFlare::GameEventDatas::Base)
Plug it in to the rest of the screens managed with the Framework
New Additions
In addition to the above, this PR includes a few monstrous additions:
GameEvent data - AllegroFlare::GameEvent now includes data, of type AllegroFlare::GameEventDatas::Base*
Subscribed events - A design in FixedRoom2D/Screen that filters events so that only subscribed events are passed through to FixedRoom2D/FixedRoom2D. Kinda neat.
A simple scripting system - Scripting from a past hackathon is introduced and cleaned up a bit. For now, it will remain in the AllegroFlare/Prototypes/FixedRoom2D/ namespace but could eventually be moved to AllegroFlare/.
Great dialog box system - Point-and-click games have heavy use of dialog. A lot of dialog boxes and related features have been added under DialogBoxes/, DialogBoxRenderers/, etc. These include features like revealing text (text characters appearing one-by-one), fast-forwarding dialog boxes, skipping ahead, multiple pages, choice dialogs, animations when dialog boxes are spawned, etc.
Screen capture in tests - AllegroFlare/Testing/WithAllegroRenderingFixture now has a feature to capture screenshots of visual tests by prefixing the test name with "CAPTURE__". This mostly came to be while developing the dialogs, which involve a lot of visual presentation. The prefix seemed like a good way to do it, but it may be more proper to call a function in the test to signal that a capture is desired, or, capture the screenshot explicitly. Eventually, I'd like to capture motion tests by grabbing multiple screenshot frames and then compiling them into a video at test runtime.
New default string pattern - now using "[unset-name_of_variable]" format for default strings arguments. (note that the quintessence system requires default arguments for all variables).
Screen::Dictionary can now optionally send signals to inactive screens if the user wishes
Still left to do
This feature still needs a bit more work to be complete. For now though, it's a great start and some great new features have finally been broken in. Meanwhile, FixedRoom2D/FixedRoom2D will need the following:
Clarified use case of how script commands and script data will be injected or extended into the prototype.
Support for multiple rooms
entity_dictionary and script_dictionary need to be soft-coded
Strategy for saving/loading content
Clarify the role of audio_controller. Are users expected to send events or command to the audio controller directly?
Clarify how audio is loaded into the audio_controller
Problem
AllegroFlare is designed to be a library focused on higher-level concepts. For the most part, AllegroFlare is currently managing middle-level things like OBJ loading, cameras, object positioning, asset management, etc. Recently, AllegroFlare started introducing concepts like
TitleScreenwhich are more higher level.I'm curious about adding Prototypes, which are yet another level up in terms of complexity. A prototype would be a more "complete" playable screen of core gameplay. In the sense that you have
TitleScreen,GameOverScreen,StoryboardScreen, you might imagine actual prototype gameplay screens likeShmupScreen,Racer2DScreen,DungeonCrawlerScreen,FPSScreen,SideScroller2DScreen, etc.These Prototypes will be a more complicated set of code and will likely extend out much further than a single file. Even though gameplay coding can get pretty complicated, there should be some kind of simplest reduction of features that could be used as a starting point to expand into a more full-featured game. Ideally, the prototype would be somehow feature-complete, in the sense that it would only require the end developer (the person making an actual game from the prototype) to extend it with the features specific to the actual game in question.
Initial go!
In this PR, I've added an initial prototype
Prototypes/FixedRoom2Da reduction of a point-and-click adventure (which is the simplest prototype I could think of). This prototype works by having you define objects in a room that you can interact with by clicking on them. (Soon should be able to add multiple rooms). Interacting with an object will fire off a script.The prototype screen includes an inventory.
How it would be used
The design is laid out such that the end developer would extend the prototype with the following code:
AllegroFlare::GameEventDatas::Base)New Additions
In addition to the above, this PR includes a few monstrous additions:
AllegroFlare::GameEventnow includesdata, of typeAllegroFlare::GameEventDatas::Base*FixedRoom2D/Screenthat filters events so that only subscribed events are passed through toFixedRoom2D/FixedRoom2D. Kinda neat.AllegroFlare/Prototypes/FixedRoom2D/namespace but could eventually be moved toAllegroFlare/.DialogBoxes/,DialogBoxRenderers/, etc. These include features like revealing text (text characters appearing one-by-one), fast-forwarding dialog boxes, skipping ahead, multiple pages, choice dialogs, animations when dialog boxes are spawned, etc.AllegroFlare/Testing/WithAllegroRenderingFixturenow has a feature to capture screenshots of visual tests by prefixing the test name with "CAPTURE__". This mostly came to be while developing the dialogs, which involve a lot of visual presentation. The prefix seemed like a good way to do it, but it may be more proper to call a function in the test to signal that a capture is desired, or, capture the screenshot explicitly. Eventually, I'd like to capture motion tests by grabbing multiple screenshot frames and then compiling them into a video at test runtime.[unset-name_of_variable]" format for default strings arguments. (note that the quintessence system requires default arguments for all variables).Still left to do
This feature still needs a bit more work to be complete. For now though, it's a great start and some great new features have finally been broken in. Meanwhile,
FixedRoom2D/FixedRoom2Dwill need the following:entity_dictionaryandscript_dictionaryneed to be soft-codedaudio_controller. Are users expected to send events or command to the audio controller directly?audio_controller