
Darwin Xavier
After attending a few game jams, I thought that there had to be a way to more quickly create protoypes and try small mechanics to see what could be fun. While there are many different ways to do this, I had decided to build a framework to create prototypes. The goal of this framework is to quickly create a prototype with simple mechanics. By testing what could be fun in an actual game, game development could potentially be sped up.
The editor provides a grid system that can be manually filled in with sprites, certain sprites have behaviors added to them. These behaviors may have values that can be manually set through the user interface.
There is a list of variables, "Lives" and "ChallengeCounter" are pre-defined variables but the user is able to add other variables aswell.
Triggers can be set on any grid position which will allow the player to change a variable. By manipulating the "Lives" variable, the user is able to increase or decrease the amount of lives the player has. By manipulating the "ChallengeCounter" variable, the user is able to creating different states of the game. For example, the game starts up with the ChallengeCounter initiated at 0. By increasing the ChallengeCounter by 1 when the player hits a trigger, some of the blocks will disappear due to the "Ranges" of those blocks.
Every grid position can have up to three different "Ranges". A range is defined by; what sprite should be displayed, the actual range (for example: 0-1, referring to the ChallengeCounter), if the sprite should be displayed). By having different ranges, interaction between objects can be created.
The sprites that are used in my framework are taken from http://kenney.nl/assets, these are free to use as stated in the license.
Prototyping framework

While the framework was able to create some interactive gameplay, the GUI was still very hard to understand. This went against the goal of framework, which is simple and fast prototyping. In order to create a more, easy to understand GUI, I sketched up a new interface with the hopes that it would be a step in the right direction.
Not only the GUI was hard to understand, setting up different ranges for individual positions on the grid was very tedious. So I decided to also rework that part of the framework. What I had in mind, was a system that would use different states. By allowing the user to switch states in the editor and change all or some of the sprites, the user should be able to create an interactive level.



By giving sprites that have some functionality attached to them a different color, the framework is able to give the user a better understanding of the level. For instance, a blue color defines a grid position that has functionality in a different state. A green color defines a trigger.