FlatRedBall builds are produced primarily using Github Actions. At the time of this writing, there are two github files:
Engine.yml
glue.yml
Both can be found in the workflows folder:
These are explicitly invoked currently, and should only be invoked when it is time to make a new FRB release.
The Engine.yml file is responsible for the following actions:
Increasing the version number - this is not pushed to the repository but is set to the current date and minute locally on the github action. For example, running this on April 2nd, 2024 would set the versions to 2024.4.2.123
where the last number (123) is the total minutes of the current time. This allows multiple builds to run in a single day without producing conflicting verison numbers.
Build all versions of FRB in both release and debug
Publish relevant nuget packages
Upload newest templates
Change version numbers (see above in Engine.yml for details)
Build Glue
Zip and upload FRBDK.zip
Team City has an automated build which runs whenever anything is pushed (assuming Vic's desktop is turned on). This attempts to build Gum (the tool) and the .NET 6 libraries use for MonoGameGum. If the builds succeeds it also attempts to upload a new nuget package. Note that this will not upload a new NuGet if the version number is not manually increased first. Also note, this DOES NOT currently upload a new Gum tool - this must be done manually.
To create the nuget packages, follow these steps:
Open one of the MonoGame Gum sample projects in Visual Studio - these link MonoGame Gum and the projects it depends on. For example, <GumRoot>Gum\Samples\MonoGameGumFromFile\MonoGameGumFromFile.sln
Double-click GumCommon and change its Version to the {year}.{month}.{day}.{build}, where build is 1 if it's the first build of the day.
Repeat this for GumDataTypesNet6, MonoGameGum, and ToolsUtilitiesStandard. Be sure to use the same version for all.
Save the files and push the commit
If Vic's computer is on, it will automatically build. If not, Vic must open it and manually run a build.
Vic has noticed that sometimes the build will fail due to the referenced ColorPicker not being available. If the same .sln (in the build folder indicated in TeamCity logs) is opened and built in VS 2019, the manual build works. Then if TeamCity is run again, all works. This is a hacky workaround.
Update April 26, 2024 - this may not be accurate, Vic is investigating...
Currently Gum uses XNA and .NET 4.7.1. This will not build using dotnet build (not sure why). Therefore, Gum must be built and uploaded manually. We could eventually automate this through TeamCity until Gum (maybe?) gets updated to modern .NET. Until then the steps are:
Open Gum locally in Visual Studio
Open Gum AssemblyInfo.cs and set AssemblyVersion and AssemblyFileVersion using the date-based format.
Rebuld Gum
Navigate to the location where Gum is built
Go up one folder so that you are in the Debug folder, and you see the Data folder
Right-click on Data and Zip it. This will produce a .zip that has a Data folder inside - this matches the expected folder structure from previous builds so make sure this is the case
Rename this Gum.zip
Manually upload this to FlatRedBall's Files folder using sftp to /home/frbfiles/files.flatredball.com/content/Tools/Gum/Gum.zip
This file is used when creating FlatRedBall builds, so Gum must first be built and uploaded to the FlatRedBall FTP prior to running the FlatRedBall Github Actions. Otherwise, an old Gum will be included in FRBDK. This may be okay depending on if Gum has important new features.
Thanks for your interest in contributing to FlatRedBall. The FlatRedBall Engine and associated tool are continually-evolving, and your involvement can help move the technology forward even faster. There's a lot of ways to get involved.
Community management for FlatRedBall is the highest-impact way to contribute to FlatRedBall. FlatRedBall is a healthy, actively maintained engine with a long history of bug fixes and feature improvements. However, despite all of these qualities, FlatRedBall is not as popular as many other game development technologies. We believe that FlatRedBall exposure is very low relative to what it provides. Fortunately, you can help!
We can see evidence of FlatRedBall's activity and health by looking at the commit history on GitHub. The following is a snapshot of the activity from the point when FlatRedBall was added to Github until May 2024. Keep in mind that FlatRedBall had been developed for over a decade prior to being moved to GitHub, but the Subversion history was not preserved on migration, so even the graph below represents less than half of the commit history!
Of course, FlatRedBall also benefits from having more code contributors and we encourage contributions of all type. The point here is to emphasize the importance of community management, not to discredit code contributions.
If you are interested in helping FlatRedBall grow but you do not have a lot of experience with FlatRedBall, or even game development in general, this is great news! It means that you can have a large impact without needing to absorb the vast body of knowledge about FlatRedBall. You can start making an impact today!
If you'd like to help out, see the sections below for specific ideas.
The FlatRedBall Discord server is an active place to ask and answer questions. The more activity in the Discord server, the more confident new developers will feel when evaluating FlatRedBall. Joining the server and chatting can help the community grow and stay active.
FlatRedBall Discord: https://discord.gg/tG5RBgw
The best way to find and report bugs in FlatRedBall is to use FlatRedBall. Inevitably if you use FlatRedBall long enough you will run into issues, whether these are bugs or friction that slows down development. You can report issues on FlatRedBall's Github page, or chat in the discord.
FlatRedBall accepts pull requests for bug fixes and new features. If you're not sure where to start, you can brows the open issues on Github. Of course, most contributors are encouraged to address issues found through development on their own projects. By fixing issues which affect your project, you already have a test case, not to mention stronger motivation to fix the issue.
If you can create content such as sprite sheets, Tiled maps, Gum components, music, or sound effects, you can provide these packs for use with FlatRedBall. General-purpose content can be uploaded to websites such as itch.io and opengameart.org, but
FRB is a mature and powerful engine, and the more people who know about it, the better! Let others know that you're working with the engine, show off your progress, and invite others to join the community.
If you want to help spread the word, there's lots of ways to help. The best way to show off FRB is to show off work that you or others are doing on various social media. If you have a game or demo that you're working on, then you can create screenshots, gifs, and videos of your project.
If you don't have anything to show off, that's okay - you can join the Discord server and look at what others are doing. Specifically, check the ๐ช| showcase and ๐| frb-updates channels. You can contact the author of any post and ask if it's okay to promote their content on any social media platform such as reddit or twitter.
You can help spread the word by creating tutorials and blogs about how to use FlatRedBall. This type of content not only serves to educate potential developers, but it can also be motivational. It gets people thinking "Wow, I can make that too!".
You can create video tutorials or written blog posts. Here are some ideas on things to cover:
How to get started making games in FlatRedBall. This could be general-purpose, or it could be focused on a particular genre
A deep dive into a particular topic, such as how to make your collisions run efficiently
Covering a particular tool or feature in FlatRedBall, such as how to make animations in the AnimationEditor
Covering technology adjacent to FlatRedBall, such as how to add steam achievements to your project
Integrating FlatRedBall or Gum technology with other technologies, such as how to use Gum in a MonoGame project
All documentation is stored in a dedicated repository at https://github.com/flatredball/FlatRedBallDocs
This can be forked and edited as markdown files. Alternatively if you would like to edit the documentation in GitBook (recommended for heavier edits such as adding new pages or reorganizing docs), you can request access in the discord server.
A variety of lists exist for game development tools including lists on reddit and GitHub. Some of these have been identified and added as GitHub issues. You can look through the issues and find areas where you can add FlatRedBall. You can also do searches online for lists of game engines and tools and see if FlatRedBall is listed. If not, this is a great way to spread the word.
If you'd like to be involved in FlatRedBall, but don't have a project that you'd like to start you can still join others in a project. The FlatRedBall community always has a number of active game projects and many of these are willing to take on help, whether it's through code, art, testing, promotion, or general feedback. Ask around to see who is looking for help.
Of course, if you have your own project you can post about this project in Discord and see if others are interested in joining.