“Freedom” is set in a minimalist world loosely based on the 1860s, and is about a struggle, identity, and self-reflection. I can describe it as a 2D platformer that can go 2.5D at times.
The game supports controllers and a keyboard, and the keyboard can be remapped if you want.
Having a prefix like “spr_” or “S_” or “s” in front of a name of a resource tells you what you expect the asset to be and prevents GameMaker from giving you errors for not having unique names.
Plan for keeping things organized from the beginning, as inconsistent names will become frustrating further into the project.
I used JSON(Java-Script Object Notation) for dealing with files, especially for translations if that was an option in the future. I used this as it is compatible with other technologies and is scalable when making more complex games
Keeping text separate in an external file allows for the application size to be smaller, and if you are using different files for localization, then it would be a smaller hit on memory usage.
If you had a typo or some error with the text, you could just resend a text file to players instead of recompiling the whole game, saving lots of time and preventing extra bugs in the meantime.
I would save the JSON as an included text file, save it as an in GM(S2), then run a script at the start of the game to read all the JSON into a global data structure which is used throughout the game and destroyed at the end of the game.
For playing the sounds and music in-game, audio_sound_gain has control over the sound volume and allows users to change it later.
This game includes a lot of jumps, including variable jumps (holding the key to jump higher), wall jumps, and air jumps.
Air jumping, one of the main points in the game, is an incredibly lazy version of coyote time. Coyote time is the point where the game allows you a couple of seconds "buffer" after players have left a ledge, usually to improve how good the game feels to play.
For collisions, there is usually the option to have the player collide with any object in the room (really slow) or collide with tiles (fast).
I used tiles and made tiny and long objects for collisions because the game does not easily follow a grid.
Start planning what resolution you want from the start of the project. The resolution in a general sense is the number of pixels packed on a display monitor, typically measured horizontally and vertically. The aspect ratio is the number you get from dividing the width of the screen by the height of that area.
I used VM builds for testing and quickly iterating, but all of my released builds (the ones offering YYC anyway) use the YoYo Compiler for performance.
The camera in the game by itself is a hybrid 2D-3D camera, creating a 2.5D effect that I control using triggers I set in the room. When the trigger is activated by the player, it changes the camera's perspective (2D to 2.5D and back). The 3D cubes can exist in the 2D space as a result, and these are using the new GPU control functions.
Thank you so much for your time, happy to answer questions, and have a nice rest of your day!