Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Should the Source Code be made available?

A topic by Errol created Jan 16, 2021 Views: 352 Replies: 12
Viewing posts 1 to 4
Submitted(+1)

@auraes asked a good question about making source code available!

I decided to update my game with the source code available for download.

When I started learning Adventuron, it was very helpful for me to have source code to reverse engineer.

However, I've never put a game on itch.io, or published anything really in regards to games. So I could be naive in all of this. :D 

Thoughts?

Submitted

I think it's entirely up to the author. If you're proud of it or you're doing something clever or unusual and you think others could learn from it, then by all means share the source code.  If you're embarrassed by it or your source code is a mess or you're worried about someone ripping it off, it's probably better that you don't share it.

Remember that Adventuron source code may only compile for the version of Adventuron that it was written for, due to all the ongoing changes, hidden features and experimental stuff that a lot of us rely on. So, make sure you state the expected version of Adventuron somewhere.

I am currently rewriting some of my old games and you'd be amazed at the amount of re-engineering required.

Submitted

Ooooh, good point on the compiling part! I probably should put that in there.

I don't think anyone would rip the game off. I do want to make the graphics available for use too, but trying to figure out the best way to do that. 

Should it be a separate file with all the base64 code? Should it be individual transparent png? One psd file? Not too sure on that either...

Submitted

If you're using a public repository like GitLab or GitHub, you could create an Assets folder and put all the psd and png images in there. Don't bother about the base64, as that requires an extra step to decode it and it's in the source code anyway.

If you're not using a public repository, you could put the psd files in one zip file and the png files in another zip file and make those available somewhere, such as the downloads on your itch.io game page.

Submitted

I could make it downloadable from the game.

I was debating base64 so that people wouldn't have to import and convert it themselves in the game. They could just copy and paste the asset and then place it where they wish. However, you're right, it's probably much easier to just have the png and they can place it where they want using their own image editor.

Submitted

Good point, I see no harm in sharing the source, especially for an educational development environment. You keep your image,/text copyrights and such anyway unless you specifically cc0 them. And Chris mentions on the site t&C's that Adventuron in its current form is not for commercial development anyway, so there's no worry legally about someone selling your hard work.


I'll try and put my source code up as soon as possible.

Submitted

True... hopefully no one will sell it! ^_^

Submitted(+2)

I'm rewriting my earlier Adventuron games to take advantage of the new features and thinking of putting the source code on GitLab or GitHub. I've got accounts on both, but tend to favour GitLab, for no particular reason. Does anyone have any experience with using these as a source code repository? What are the pros and cons of each?

Submitted(+2)

I think both are largely comparable, especially if you don’t use “advanced” features such as team work, code reviews or CI/CD, and you only want to host your source and use simple features such as issues.

If that matters to you, GitHub is owned by Microsoft whereas GitLab is open-source. With GitLab, you can download a full copy of your repo along with its metadata (issues, comments, merge requests and so on) for archival or to put it on your own hosted instance (if that becomes necessary to you, which I doubt).

GitHub is way more popular though, so you may have better visibility there, but I’m not sure that really matters for a small Adventuron project.

Disclaimer: I prefer GitLab, mainly because I favour open-source projects. Also, I used Bitbucket before, but it stopped supporting Mercurial and I had to convert all my repos to Git myself, and import them somewhere on GitLab, and it was difficult/impossible to keep metadata such as comments and issues. (Luckily I didn’t have a lot of metadata.) This wouldn’t have happened with an open-source platform such as GitLab.

Also, I’m far from being an expert and mainly use GitLab for small personnal projects.

Submitted

Thanks. Very helpful.

Submitted

Oooh, yes, I wasn't aware of any of this. This is very helpful, thank you!

Submitted

I'll second this post, I'm basically in the same boat, having tinkered with both for small personal projects. However, one thing I've noticed if you venture outside of Adventuron that may influence your choice is that I feel there is a tendency with some IDEs to have native support for GitHub, making integration slightly easier. 

The biggest upside for choosing GitHub would be if you wanted more eyes on it. 

(+2)

I'm a fan of GitHub but from what I see GitLab has some neat features I'm not technical enough yet to really use.

Ever since GitHub allowed private repositories, I switched a few repos from Bitbucket to Github, which has better issue tracking. I think Github and Gitlab are both about the same for casual programming.

Looking back, it was important for me just to keep making commits and not worry about the technical stuff.  Given that there are good tutorials on how to move a repo from one website to another, I wouldn't worry too much. If you catch yourself saying "I wish Gitlab/github could do this" then maybe it will be time for a change. But I know I got more mileage out of learning how to use git, e.g. cherry picking commits with add --patch or learning to use branches. And learning how to make good commits has helped with my programming habits immensely e.g. not trying to do too much at once, testing each commit, and so forth.