Why aren't more fan games open source?

Discussion in 'Fangaming Discussion' started by flarn2006, Feb 27, 2020.

  1. Gnidel

    Gnidel

    Member
    4
    1
    1
    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.
     
  2. SF94

    SF94

    Tech Member
    776
    2
    18
    Utah
    SA1/2 hax
    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):
    1.  
    2. // Does some cool function
    3. // param_a is for something
    4. // param_b is for something else
    5. void some_cool_function(int param_a, int param_b);
    6.  
    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. ;)
     
  3. BlazeHedgehog

    BlazeHedgehog

    A "Community Enigma"? Oldbie
    1,462
    5
    18
    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
     
  4. Xiao Hayes

    Xiao Hayes

    Back on track Member
    640
    39
    28
    Bilbao, Spain
    Upgrading my own life to pro edition
    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
     
  5. BlueFrenzy

    BlueFrenzy

    Member
    28
    18
    3
    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.
     
  6. MainMemory

    MainMemory

    Have no fear...Amy Rose is here! Tech Member
    4,435
    74
    28
    SonLVL
    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.
     
  7. Ralakimus

    Ralakimus

    pretty much a dead account Tech Member
    557
    158
    43
    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.
     
  8. Sparks

    Sparks

    Member
    3,034
    13
    18
    Kyle and Lucy: Wonderworld
    I mean, aren't most fan games full of copyrighted assets out of proxy? :V 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).
     
  9. Conan Kudo

    Conan Kudo

    「真実はいつも一つ!」工藤新一 Member
    478
    1
    18
    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...
     
    • Like Like x 1
    • Agree Agree x 1
    • List
  10. Cooljerk

    Cooljerk

    NotEqual Tech, Inc - VR & Game Dev Oldbie
    4,334
    75
    28
    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.
     
  11. Lilly

    Lilly

    Muffin Taste Tester Member
    2,240
    84
    28
    United States
    Shang Mu Architect
    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. :psyduck:) 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.
     
  12. Xiao Hayes

    Xiao Hayes

    Back on track Member
    640
    39
    28
    Bilbao, Spain
    Upgrading my own life to pro edition
    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
     
  13. Billy

    Billy

    RIP Oderus Urungus Member
    1,918
    38
    28
    Colorado, USA
    Indie games
    Best advice I ever got for code comments was not to comment on what was happening, but why.
     
    • Agree Agree x 2
    • Like Like x 1
    • List
  14. DigitalDuck

    DigitalDuck

    Arriving four years late. Member
    4,892
    72
    28
    Lincs, UK
    TurBoa, S1RL
    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.
     
    • Informative Informative x 1
    • List