Feature Request (To be fulfilled by Studio Momentum) - Synthesis/Architecture Examples

[bmalumphy]

Summary

Simplicity is beautiful, but as you build a game as close to the metal as possible, inevitably complexity emerges. Organizing complexity while staying as true to simplicity as possible is a difficult balance, and many self-taught devs or those exploring the possibilities of Raylib independently may not have experience in navigating that for any system, let alone a game system. This feature request is meant to elucidate the possibilities of full game development, beyond the scope of playgrounds and single idea builds.

Proposition

We propose three improvements to the example space in the Repository, to be fulfilled by my team, Studio Momentum:

1. An extension of the examples section that includes pieces that synthesize multiple ideas in one form. The architecture will not encompass a single main.c file but will instead encompass multiple (possible several) project files that compartmentalize code productively and puts multiple features on display in harmony. Examples include tilemaps with advanced collisions, advanced lighting techniques, multiple sprite architectures, etc.
2. Another extension of the examples section that includes fully playable games with a bit more meat on their bones. While this is arguably synthesis, what we propose is that this would be a game that could, within a smaller (10-15 minute game) scope, do alright on its own at an event like NextFest or PAX. These demos would include specific build practices for CMakeList.txt that make deployment simple as well, giving folks an impression on how to build their games easily with minimal additional configuration.
3. Lastly while external libraries are typically shied away from here, we would like to show examples of how to integrate libraries like TMX without including it in the build for the actual game, along with long term plans to show how you can avoid TMX entirely with your own native solutions-including providing one ourselves to potentially allow Raylib to at least have a good example for tilemaps and potentially even integrate tilemap systems into Raylib itself without ever needing to show TMX ever again (depending on the desires of current contributors).

Expected Delivery

Proposal 1 will be contributed to effective one week after acceptance for a few examples that we already have prepared. However the others will likely heavily depend on our time relative to our commitments and development time on our own project(s). Given that, we estimate the following:

• Proposal 1 Delivery 1 week after acceptance
• Proposal 2 + 3 Delivery 3-5 Months after acceptance

We aren't strictly speaking operating in an Agile environment, but we are iterative waterfall at worst. We also don't plan to go dark during development and will keep stakeholders informed of progress on a weekly basis.

Risks/Doubts/Unknowns

• The joy of programming, often, is figuring it out on your own. We recognize that keeping examples to a minimum viable solution forces developers and engineers to think for themselves, make mistakes, learn from said mistakes, and grow. Increasing complexity of examples in this way would inevitably spoil the solutions to some problems that it would be productive for some developers to figure out on their own, or introduce too much to learn for someone that's just starting. This is why we commit to discuss these propositions with current contributors and owners as much as possible to ensure we maintain the philosophical ethos of the project as both an educational tool, and a practical one.

• There may not be an audience immediately in front of us to appreciate these examples. Most users of Raylib are hobbyists or those who are educating themselves on game and software development. They also may not immediately show interest in these larger scale examples because they aren't interested in scaling their work (yet). We believe this is not entirely universal however, and would suggest that having these examples could bring more technical developers looking for broader examples before jumping in.

• We recognize that these could also be encompassed in tutorial videos/our own repos just fine, and that it may not make sense to have these in the Raylib repository itself.

[raysan5]

@bmalumphy Hi! Thanks for this proposal! In the line of the exposed requirements, there are already some repositories that can be useful, despite not being that popular:

1. raylib-game-template - This is a basic template for games with several screens, showing a possible screen organization, it implements in C screen loading-unloading and transition between them. I used that same template for multiple gamejams. raylig-gamejam-template is a slight improvement over the previous, implementing GitHub Actions workflows for automatic Release generation and multi-platform compilation on every commit.
2. raylib-games - This is a collection of +10 small games that I developed mostly for GameJams, they are complete, short games with multiple different mechanics. I usually update them for every raylib release, including the Makefile build system.
3. raylib dungeon 2d (tile-based) - This is a tile-based 2d game demo I implemented for a University course, it's quite limited in features but the provided documentation is quite extensive and detailed on how to work with tilemaps and tilesets. In that same line, I'm currently working on a tile-based game. Also note that there are several raylib-tmx libraries ou there and also raylib-extras including some advance raylib samples.

[bmalumphy]

Awesome @raysan5 ! How would you feel about a focus on 2D platforming in addition to these great cases? If we came up with a list of proposed features that are a bit more precise, we could maybe nail down the ideas we hope to bring in addition to these pretty well.

Also, assuming you're cool with these ideas in principle, what would you like to see from additions to these samples you've built over the years? In addition, would you want them to be separate from the main examples repo?