I think the biggest issue in making game open source is that most fan games are never finished and many of them don't have anything worth open sourcing as they are based on existing engines with minor alterations. They are abandoned, what means the authors don't want to put more effort into it and open soucing it is more effort. Especially with hosting because games can have some large assets, as well as some leftovers. Another option is open development, which is great because other people might join, but it scares away people who want more control over the project and don't want it to turn into an unsorted collection of random levels with random quality. Even with open development there's, again, the issue of large assets. With code/frameworks it's easy, just use git, but storage of textures, music, models, videos and Unity/UE4 project files - not so much. Gitlfs and hosting are additional expences and I doubt anyone wants to spend money on development of a non-profit game. Git also has an issue of people not knowing how to use it, fan games are often made by amateurs, after all. Personally I want to open the souce of Sonic Stranded (formerly known as Sonic Liquid Survival), but only after finishing the game. I'll do two releases - of the full game and cleaned up and streamlined framework with tutorial level and some level design tutorials. If people will make bad games from it, I will blame myself for bad tutorials, but I will be honored anyway because it would mean I helped someone have fun making a level. But I won't release it until I'm done with the game and some post-release bugfixes.
The way I look at things like this is: there is always room for improvement. I wouldn't wait on an infinite timeline. I have a lot of respect for programmers that are able to say "yeah, that code isn't the greatest/isn't up to my standards, but it's functional and can be changed later" - it shows good understanding for prioritization and its impact on the project. When you say documenting code, are we talking in the fairly literal sense, like so? Code (Text): // Does some cool function // param_a is for something // param_b is for something else void some_cool_function(int param_a, int param_b); Because let me tell you, it's a good idea to get in the habit of doing this up front. I've had this help prevent scope creep, even. As a side note with love, always write your code and its inline documentation for somebody else to read. That somebody could just be you in a week, month, year, decade from now, and without good naming and documentation, you bet your ass you won't be able to understand it, let alone newcomers.
Releasing my projects open source would require that I implement clean, legible code that other people could easily read It also means the burden of fielding questions from people confused by what I'd written And that starts to sound like a level of work beyond casual funnin' around
Something I wanted to do but probably never will at this rate was to develop and release a toolkit to make fangames with basic stuff from existing games so people had something to work with, but keeping the stuff of my own fangames out of it to not spoil the fun and protect the stuff I cared more about. I think we would have more quality fangames if they had a robust base to work with that doesn't necessarily ask them to code, much like what happens with rom hacks, but on the fangame side. Of course, a lot of shitty projects could emerge from that precious framework, but my own stuff would still be mine. About code quality, I'm such a perfectionist that I would polish the code and write every comment even if I wouldn't make a public release the source code, so that doesn't worry me, and I'm so out of the coding trends that feeling embarrassed about my coding style would make no sense, at least it would be polished and documented enough for them to update it quickly. XDDD
I will probably open source Sonic Frenzy Adventure. There are three main reasons I would not do it: 1- It's obsolete. By far you will end up doing much better with Sonic Worlds. 2- It contains several copyrighted stuff, like music or art, so it will be hard for some people to identify if they can use the asset or not. 3- It's extremely messy. Still, I will probably release the original files because maybe someone wants to mod it. Feel free.
All you people saying that you have to have clean code in order to release it publicly have clearly never looked at any of the programs or mods that I've released on GitHub over the years.
IMO, it's highly preferable that the code should be kept clean and documented if it's going to be open source. It just makes it easier for the people who want to look at it and understand it.
I mean, aren't most fan games full of copyrighted assets out of proxy? There's plenty of projects that are open source, but I think it's safe to assume that the community understands and assumes it's all owned by SEGA and whatever other sources are used, unless said otherwise (such as original music compositions).
I know this is a bit of thread necromancy, but this is a topic that I've thought about a lot for a long time. It's been a while since I've participated much in this scene, and I mostly drifted away into other things (even though Sonic holds a special place in my heart, and Sonic Retro as well). My take on why we do not see open source as much as we should, especially with fan games, is because ultimately this scene is not about sharing and learning. It's about pride. Sure, there's some sharing in the form of some basic tools and stuff for disassembly and reassembly of ROMs for Sega systems, but by and large, people participate in here to show off how much they can change things around or make something based on the Sonic "world". Also, at least around the time I was more "active", there was a higher bias against open source for various reasons, even though generally we would benefit from more open source projects as a community. That's why @Stealth never released his engine as an open source project, even as a dual-licensed one to allow commercial use under alternative terms. That's also why @The Taxman never did for his engine either. The few open source engines (ProSonic, OpenSonic, etc.) either received no interest to develop or wound up drifting away from the community to survive. Sonic 2 HD is probably the most (in)famous fan game to have struggled to be developed because it is done in a closed manner. It went through two engines, both of which are proprietary and cannot be freely contributed to. This new generation of Sonic fan games using proprietary engine codebases are interesting, as many are semi-open. Bumper Engine requires Unity3D, SonicGDK requires UEK, and so on. These engines are partially open source, but are not useful without the proprietary core, even if you have the code. To this day, you would think that I would be surprised that nobody builds on open source engines like Godot, which provides a wide array of features to support both 2D and 3D games, but if you consider that many folks consider it a matter of pride to implement things from scratch or use "industry" tools (though Godot is increasingly used in industry as well...), it starts to make sense why they write their own 2D engines or build upon Unity3D, UEK, or Source for 3D games. Simultaneously, a lot of folks have apprehension about showing their code, because they know it isn't perfect. This natural fear combined with pride makes it so people just don't consider it despite all the open source stuff they consume to help build these things. Maybe one day this will be better. I continue to hope...
Much, much more literal than that. What you're posting is the absolute bare minimum someone should be doing when coding. I am extremely verbose with my in-code comments, and also practice as descriptive naming patterns as possible. That's just proper coding. I mean documenting as in creating actual documents to accompany your source code. Like blog posts, a dev diary, etc. Things that explain, outside of pseudo code or comments, not just how your code works, but also your thought process. I keep a diary when I develop things, I've done so since I was a little kid. Every day, when I'm done working, I spend about 30 minutes writing what I did for the day. Like I said, not just how my code works, but also how I approached problems. Like, what I was thinking, how I expected a solution to work, what sort of topics I was reading and researching to help me achieve my goal, etc. This way, if I need to retrace my steps on a project, I can speed by and skip spinning my wheels going through dead ends as I reteach myself things. But doing this is extremely time consuming. Basically a second writing project on top of your normal development.
I feel encouraged to do exactly this sort of thing, with dev diaries/summaries, when I start working on original projects, and get my feet wet in C# for things beyond just video games. Right now, I comment my code to the extent that it annoyed some people who tried to read it, (As in maybe too many Captain Obvious comments. ) but I'm certainly not going this far. For the fan game I'm working on at the moment, it'd just take up precious free time I could spend on bolting the rest of it together. Because as this thread only reaffirms, it's the wild west in fan game source code- especially so when it's somebody's first project of such a great scope as a full-fledged video game. We naturally don't know what we're doing yet! I still don't! :specialed: I doubt I would get super-verbose about what I'm doing with code, and what my thought process was while writing/structuring things, but any past reference for your future self is surely a helpful one, as you said. Less time spent remembering how a certain thing works, so you can refactor it, or plug something else into it, makes the time taken to document things worthwhile.
Back in 2016, when I was doing my practice period of web coding (PHP for the most part), not only I made all the captain obvious comments, but I also added dates as to when I added or modified the code, and what I did, even pointing to specific lines of code and changes made on each of them(bad thing when the size of the code changes and thus the line numbers). I in fact made the dev diary inside the code itself, and, of course, it took me more time than any code I had to write, but I wanted to be sure it was written as an explanation for others that could come next. Oh, and, with non-coding projects my train of thoughts is so evident for me, my own work is self explanatory or takes very little time to figure out again. XD
This is exactly how it should be done. Generally speaking, if you write code properly it shouldn't need comments, because everything should be clear from the code itself. But occasionally you have to sacrifice readability for efficiency, and these are the times you use comments to explain why it's not readable.
Newbie question, what stops several teams of devs from sharing code and then releasing separate fangames with their own levels/stories etc?
This is something I can think I can answer. We've technically gone over it in a different context, in this thread, but it's worth repeating, I think. A) In a way, this has already been done with the likes of Sonic Worlds, a popular fan game framework that's been used for half a dozen great Sonic fan games, and even indie darlings like Freedom Planet 1 and Spark 1! It has been the key building block for many wonderful games! The authors and contributors to Sonic Worlds Delta should be proud of themselves at this point. B) As for complete fan game engines being used to make other campaigns, this one is trickier for a lot of reasons: A) So many fan games are built to be finished as quickly as possible, then optimized and bug fixes are patched in at a later date, so you'll see instances of code that are the metaphorical equivalent of duct-tape everywhere, even after optimizations/code cleanups. These "unclean" "engines" are therefore unsuited for being gutted of their original campaigns, and having new campaigns being built on top of them. You'll never completely get rid of the spaghetti and leftover bits from the previous project, which will cause unexpected hitches/disruptive technical problems that can bring the whole project to a grinding halt. It's just easier, if not safer, to use a cleaner, fresher framework with none of the entangled bits from a previous fan game. B) One thing you see often in programming circles that many developers like to code things all in their own way, to the point that, sometimes, two developers can't reach a compromise on how to approach a particular feature, the code's architecture, or even what libraries or IDEs should be used for the project. Some may argue to use Unity for ease-of-development while another might prefer Unreal- then you have the occasional C++ snob who prefers Visual Studio and SDL libraries for everything, to the point of snubbing Unity users. Because we humans have our preferences, biases, and can't always agree on everything, let alone what to use, most developers will want to either challenge themselves by making their own engine, or sticking to what they know best. This is part of the reason there are so many Sonic fan game "engines" these days; some frameworks prefer accuracy over performance, or performance over accuracy, or some other design philosophy that's agnostic of either side of the argument. Even I went as far as making my own physics for my project, for reasons that ultimately weren't very well justified, and it wasn't going to be perfect anyway; it was my first attempt at anything like that! Learned a lot of hard lessons I'll never forget. (Pain and embarrassment remain the cruelest, but most effective teachers.) But it's still the only purpose-built fan game "engine" for the likes of Freedom Planet, so I take a little pride in it and will address its shortcomings as best I can. tl;dr, "code smell" is a big problem with completed fan game engines, it's why most fan games start fresh instead of recycling pre-existing work. Everyone has their preferences for IDEs, and differing design philosophies for "engines". (Game Maker, Unity, Clickteam, Unreal, Godot, C++, or even C#! You'll find Sonic frameworks in every flavor under the sun.) It very much mirrors the open-source world, where there's several different apps solving the same software solution in all their own ways, but the world is better and more productive for it, honestly.
This isn't an exact parallel, but similar enough to illustrate a point... An example that comes to mind is the DOOM 32X WAD Converter (aka Wad32X), which I made a little over a decade ago now. I was pretty proud of myself for having done something nobody else did, and it required a good bit of research beforehand to make possible. I released it, but I honestly didn't expect it to get much use. To my surprise, years later, I noticed all these YouTube videos of DOOM 32X hacks... using custom levels and graphics. I thought it was neat, and after some searching around, concluded they *must* have used my program. And yet, almost NONE of them even made mention of the tool they used or my name. Sadly, that's fairly common. Those hacks wouldn't exist but for my hard work putting that program together. That's why it doesn't ever surprise me when people choose not to go open source. Others have a tendency to use what you've done to establish their own fame and glory without acknowledgement. And while I make a lot of my stuff open source, but I know I run the risk of being ripped off in a similar fashion. It's a pride thing I suppose, and yes, I agree that it can sometimes hold back a project's potential.
I fully plan on SC2 being open source. I have the github account ready to go but I've just been scrapping for time to actually get it uploaded. I basically feel the same way as Sax does about it. At this point, any mods or improvements only benifit everyone along with learning. EDIT: Github hates large files without paying -- so this will have to do. https://drive.google.com/drive/folders/1aFPnD2oQuBtADyKR67GixmN3oSJAegqx?usp=sharing Forgive me for any dark humored shit in my comments. I never intended to release a source. Also, thanks to everyone who I copied (got inspired) off of. You're all a liar if you try to claim you've never done the same.
A few of you mentioned github’s storage limits. Anyone know if it will give you enough room for a game with 6 zones with 2 acts and 4 unique enemies in each?
Unless your 6 zones, 2 acts, and 4 unique enemies per zone tops 100 GBs, you should be good. The only other thing to know is that your individual files should also not be larger than 2 GB. Long story short, no reasonably scoped 2D Sonic fangame should be approaching Github's max repo size.
