Sorry!
Before continuing in explaining how the editor works, I would like to apologize for the time it's taken to push another update to Itch.io, or to add any information anywhere else. While you may not have seen much of what's been developed, the game has been in active development. As I've said before, most of additions and changes to the game have been on the code side, and I'll explain why in a bit, but I would like to apologize because I've also started developing another, small game that might help aid the development of BSH.
Free Forever
Because of the input I've gotten so far on the game on how it kind of looks like a rip-off of MegaMan (While otherwise being built completely differently, and is by no means derivative work) and just because I can, I'm making Byte Sized Heroes free. Not only will the game always be free (Which means no microtransactions or ads), the game will also still be shared on Steam Greenlight and the engine I've built will be completely open source under the GPL (GNU General Public License) forever. Additionally, I will be actively pushing updates to Github in a short while.
For me, Byte Sized Heroes is a passion project. It's not a "I'm going to work really hard at this and make lotsa money" project, it's a "I'm going to work really hard to help the progression of indie development, especially in areas where certain game engines need more open sourced project to reference and learn from, in the same way Game Maker always was back in the day, hailing from the evolution from Klik N Play in indie development".
That's surely a long-winded goal. TL;DR: I wanna make free shit.
For me, Byte Sized Heroes is a passion project. It's not a "I'm going to work really hard at this and make lotsa money" project, it's a "I'm going to work really hard to help the progression of indie development, especially in areas where certain game engines need more open sourced project to reference and learn from, in the same way Game Maker always was back in the day, hailing from the evolution from Klik N Play in indie development".
That's surely a long-winded goal. TL;DR: I wanna make free shit.
The Level Building
The Byte Sized Heroes engine is completely modifiable with and without Construct 2. Documentation is provided in-project inside Construct 2 (Of course this requires a Construct 2/3 license), and some documentation will be shared on the official Byte Sized Heroes website to explain how modders and gamers can use the in the editor to build their own maps, stories, etc.
In the editor, everything is a simple click and drag interface. Objects that can be clicked and dragged into the game include characters, enemies, obstacles, utilities, and the like, and will all be organized in categories, characters can be given lines of dialogue when spoken to in the overworld, but can also be modified dynamically in the Map or Story Scripts; Enemies can function the same way, but have set attack animations and patterns; Obstacles are like map tiles that consist of animations like machines, waterfalls, etc., with Scriptable functionality; and Utilities consist of things that modify how the game runs such as controlling camera movement like snapping it in place or keeping it from moving past certain points or even slightly pull the camera to it, setting objectives (including welding the objective to a physically dynamic pick up, or trigger zone), of course Trigger Zone which triggers an event either when touched by the player or the entire time they're within it's area, Scene Volumes that change animations of certain objects visible in runtime (such as adding snow, or dripping rain); and much more.
In the editor, everything is a simple click and drag interface. Objects that can be clicked and dragged into the game include characters, enemies, obstacles, utilities, and the like, and will all be organized in categories, characters can be given lines of dialogue when spoken to in the overworld, but can also be modified dynamically in the Map or Story Scripts; Enemies can function the same way, but have set attack animations and patterns; Obstacles are like map tiles that consist of animations like machines, waterfalls, etc., with Scriptable functionality; and Utilities consist of things that modify how the game runs such as controlling camera movement like snapping it in place or keeping it from moving past certain points or even slightly pull the camera to it, setting objectives (including welding the objective to a physically dynamic pick up, or trigger zone), of course Trigger Zone which triggers an event either when touched by the player or the entire time they're within it's area, Scene Volumes that change animations of certain objects visible in runtime (such as adding snow, or dripping rain); and much more.
The Scripting
Scripting inside the scripts editor is rather simple. There are three different script editors: Map Scripts, Story Scripts, and Game Mode Scripts.
Map Scripts are scripts that will run every time you enter the current map.
Story Scripts contain a flow chart of individual script sheets identified by thumbnails and names, these names are used to transition from one Story Script node to the next in the chart, which happens when specified. This allows the person building the Script to easily create branching paths, because when the Script Node "Switch to Story Node *Node Name Here*" is used, it will create a the node and link in the Story Scripts editor and will branch off for each "Switch to Story Node" node created. Because you can call a function when players make choices, this could be used to make a story with branching paths.
Lastly, Game Mode Scripts are used to determine the score. The creator of the Game Mode adds the amount of teams in the match. For instance, for a free-for-all kind of Game Mode, you'd add a team each time a player spawns. Otherwise, you'd create to teams right off the bat, and split them up based on different traits of the player, such if they're in a party together, or their skill levels. After the teams are decided, they objective for scoring is then chosen. We'd determine if, when a player is killed, the other player is on the opposite team, and if they are and we're playing a Deathmatch kind of Game Mode, add a score for that killing player's team.
There will be reference Scripts one could build from inside the editor for every script used in Byte Sized Heroes.
Map Scripts are scripts that will run every time you enter the current map.
Story Scripts contain a flow chart of individual script sheets identified by thumbnails and names, these names are used to transition from one Story Script node to the next in the chart, which happens when specified. This allows the person building the Script to easily create branching paths, because when the Script Node "Switch to Story Node *Node Name Here*" is used, it will create a the node and link in the Story Scripts editor and will branch off for each "Switch to Story Node" node created. Because you can call a function when players make choices, this could be used to make a story with branching paths.
Lastly, Game Mode Scripts are used to determine the score. The creator of the Game Mode adds the amount of teams in the match. For instance, for a free-for-all kind of Game Mode, you'd add a team each time a player spawns. Otherwise, you'd create to teams right off the bat, and split them up based on different traits of the player, such if they're in a party together, or their skill levels. After the teams are decided, they objective for scoring is then chosen. We'd determine if, when a player is killed, the other player is on the opposite team, and if they are and we're playing a Deathmatch kind of Game Mode, add a score for that killing player's team.
There will be reference Scripts one could build from inside the editor for every script used in Byte Sized Heroes.
The Engine
I purposely built the engine to utilize CSV's to load information during runtime. The game (after the next update) starts the player off IN-GAME, which means they will have to walk to any area they want to enter. When this is done, they trigger a set of events that loads information from CSV's pertaining to the map that needs loading, and then drops all other information, keeping only what is used in memory.
This is important in reference to Construct 2, because when using animations, all the other animation frames would be kept in memory. Because one object is cloned to create each placed object in the world, the game would hold ALL of the animations of the game in memory, all the time. That is a A LOT of information. Instead, the game will keep only the animations that will be used in memory, and animations can be added to this "Memory Pool" as we will call it through scripting, by using the "Preload Animation" script, so as to be able to use it exactly when needed.
Map data including where these objects are placed are typically saved in a folder specific to the browser the game is being played in, but all the information can be exported in JSON format, and reloaded into the editor later. All information exported and loaded in this fashion will always be forward compatible, so nobody will ever have to update their projects for new versions of the game.
Based off this information, you can easily assume that modders will be able to create mod packages that include new sprites and animations for the game to be used in scripts for other modders, and because Script sheets can be exported to seperate JSON files as well, they can also be imported to include in other modder's packages.
This workflow would allow people the ability to utilize tools like Github to push and pull updates as a team, as well as the ability for modders to collaboratively add other mods to their own.
This is important in reference to Construct 2, because when using animations, all the other animation frames would be kept in memory. Because one object is cloned to create each placed object in the world, the game would hold ALL of the animations of the game in memory, all the time. That is a A LOT of information. Instead, the game will keep only the animations that will be used in memory, and animations can be added to this "Memory Pool" as we will call it through scripting, by using the "Preload Animation" script, so as to be able to use it exactly when needed.
Map data including where these objects are placed are typically saved in a folder specific to the browser the game is being played in, but all the information can be exported in JSON format, and reloaded into the editor later. All information exported and loaded in this fashion will always be forward compatible, so nobody will ever have to update their projects for new versions of the game.
Based off this information, you can easily assume that modders will be able to create mod packages that include new sprites and animations for the game to be used in scripts for other modders, and because Script sheets can be exported to seperate JSON files as well, they can also be imported to include in other modder's packages.
This workflow would allow people the ability to utilize tools like Github to push and pull updates as a team, as well as the ability for modders to collaboratively add other mods to their own.
The Release Date
I can't make any promises for a release date of all of this in the next month, but it will all be complete by August. You can expect to see the next push then, and a relatively low goal Kickstarter campaign to back a bit of the project's development. Rather than going full time on this, I'm keeping a stable full time job and making this the best it can possibly be. If you'd like to contribute to that goal, you can contact me via email: [email protected], donate to me on Itch.io, or wait for the Kickstarter to role around. Until then, I'm going to be working intensely on my lonesome!