2.00 Open-source NL2

Started by Simon, September 02, 2015, 12:28:14 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Simon

Final decision: Yes, it will be open-source. No, Git is not going to be used, or at least not in the near-future.

Brain dump from IRC:

<SimonN> I'm considering writing a post for namida, suggesting to do NL 2 development on github. I most likely won't build it myself though, but you never know
<Rubi12> er whats NL2
<SimonN> NeoLemmix 2, his rewrite
<Rubi12> oh
<SimonN> basically, opening the source is important for the odd user who likes to look at the source for fun, and may help with debugging if the co-users can look at the source
<SimonN> he might also attract people who send in patches, but that's not the main point with such a project
<SimonN> maybe someone wants to build themselves on Linux, but right now I don't think he's gonna support it
<SimonN> for Windows users, building from source isn't attractive; the same Windows binary built by the maintainer will run for everyone


I was happy to teach git to people on IRC in 2011, when Lix went to github. I'd still be happy to do that these days.

-- Simon

namida

#1
It will be open source, but most likely in the "here's a zip of the source code" format rather than GitHub or similar. The "folder(s) on my hard drive, with backups on DropBox and maybe a USB drive" model has worked perfectly fine for me so far, and ultimately has no effect on the end code; so why fix what isn't broken in this regard?
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

geoo

Quote from: namida on September 02, 2015, 06:48:49 AMThe "folder(s) on my hard drive, with backups on DropBox and maybe a USB drive" model has worked perfectly fine for me so far, and ultimately has no effect on the end code; so why fix what isn't broken in this regard?
It's worked fine so far because there have been no collaborators. If you intend to share your changes on a regular basis a versioning system is gonna save you quite a bit of work. If you don't intend to do that (a reasonable assumption as there hasn't been much interest in the code in the past as far as I'm aware, maybe also because the compile environment seems a bit tricky to set up) you'll be fine without the few other quirks that git provides for you. I quite got used to using git for my work by now (not even always code, and sometimes only as local repos) as I enjoy having a revision/progress history complete with access to the code at any stage, in particular to track down bugs that were introduced at some point but spotted only later.

Simon

#3
Quotewhy fix what isn't broken in this regard?

Because version control is framestepping for software development.

You won't know why it's essential unless you have seen it work well1. Why should people use convenient, efficient engines like NL or Lix, when they can play L1? Why should the USA switch to metric, even though they have archaic units to measure everything?

git is an extremely lightweight, powerful, local content tracker. For normal development, there is no server involved. Removing git-tracking from a project is equal to deleting a single .git dir inside the project root dir.

Local branching, merging, and reverting are the main points. They're akin to framestepping with possibility to insert or reorder.

Lix on github is 40 MB, complete with 4.5 years of history. If you clone this, you get a full-fledged local copy of the repository. You get side branches that I chose to make public, right now 1 out of maybe 20 local branches, for physics discussion with geoo. From the 40 MB of data, you get to build any version back to March 2011, complete with levels and graphics.

Quoteand ultimately has no effect on the end code

It has an effect, because people are encouraged to help.

I don't care much if you hack NL using Windows Notepad, or some fancier editor. I'm not affected by your editor choice. I do care whether you publish source using version control, or in a plain archive. It's harder to talk about changes, and to make patches, which git could transparently merge in. It will record what happened when and why, so if you've merged crap, it's always possible to revert precisely.

Even if you never get a patch, it's convenient for others to follow your thoughts, and easier to look at what's new.

Similarly, it's convenient for me that geoo maintains the community levelpack on github. I can pull from him whenever I want to release the main game, and suggest patches for him to merge automatically.

These are the benefits from publishing git history. The even more important thing remains the local control.

6 Myths Preventing Developers from Using Git -- the first being "I back up regularly, so I don't need source control".

-- Simon




[1] About source control working well: I've never liked centralized version control like SVN, where you either push your buggy code to a server as soon as you're done writing it, or can't commit for days. Committing should be different from inflicting changes on the world. When I was doing a SVN-managed university project 6 or 7 years ago, my policy was: Nobody but me works between 2 a.m. and 7 a.m.

namida

I see what you're getting at. I might consider it once it's in a much more advanced state of development.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)