Best practices for working on a game with a group of people

Back in 8th grade I made an OHR game with some friends. It was a school-related project, so we all met after class and used a teacher's computer, taking turns doing different tasks. I'd write plotscripts at home and bring them in to test with the game, inevitably having to change things that I'd misremembered while away from the game.

Fast-forward 13 years and now I write code for a living. I haven't used the OHRRPGCE since ~2010, but a group of friends and I would like to try making a game together. We live in different cities, so sharing a computer isn't going to work. ;)

It would be great to use git. I know I can unlump games, but I have a feeling some hard-to-resolve conflicts might arise if, say, two people are both working on the same component of a game.

What has worked for other people? Is it best to just use FTP and take turns?

Other than the odd 1-week contest, I've never really worked on games with other people because any time I try, they bail on me. So I guess if I have to suggest something, partner up with someone that actually cares to work on a project for real.

---

dOn'T MiNd mE! i'M jUsT CoNtAgIoUs!!!
Play Orbs CCG: http://orbsccg.com/r/4r6x

If no two people are touching the same area of the game, then git should work fine on unlumped projects. Take a look at the list of lumps to see exactly how it's broken down.

---

Mega Tact v1.1
Super Penguin Chef
Wizard Blocks

Welcome!

Putting unlumped rpg files in version control works pretty well. I keep my games in subversion.

Whether or not you will have problems with merge conficts mostly depends on how you are dividing up your work.

If you have one person doing graphics, and another doing scripts, and another doing maps, and another doing scripts, things will go pretty smoothly.

If you, for example, have 2 different people working on text boxes at the same time, then you will have merge conflicts, and you will have to take precautions that you don't make changes simultaneously.

You will want to pay attention to merges of ohrrpgce.gen

This file keeps record counts for a bunch of other data files, which means it changes constantly, but fortunately the game can auto-correct its record counts, so even though you will have frequent conflicts with ohrrpgce.gen, they will usually be easy to merge because any change to ohrrpgce.gen that comes from adding new records to another file can be safely ignored.

As the other's said. It's best to split the game up into different areas. This is usually done because some people are just better at certain parts of game making then others. I'm sure some members of your team are better at graphics then others, and the same can likely be said about coding and design.
The best part about splitting the game up into coding, graphics, and design is that they are all easy to put together once created separately.

This question comes up quite a lot! We should definitely put up an FAQ page, and maybe think about how we can make things easier. With git, it's possible to specify special diff or merge tools for certain files, so I've set mine up to display RELOAD (one of the file formats we use) files as human readable xml (see here), but that doesn't get you very far. I keep all my OHR games unlumped in git repositories and sometimes collaborate on them.

It's possible to merge RELOAD files automatically, but unfortunately there are no tools available to merge any of the other lumps*. It wouldn't be hard to write some, because almost all other file formats are fixed size records (it would be nice if Custom included a merge tool).
Also, generally all shops, items, enemies, heroes, etc, are stored in the same file, so you will get conflicts. The partial exception are maps: two people can edit different maps BUT the map general settings (including layer settings) are all stored in the same lump :( (this needs fixing).

In addition to ohrrpgce.gen, you are also likely to have constant merge conflicts in general.reld, because that file includes the version number (including OS) of the last copy of Custom to edit the file. You can also safely ignore those conflicts. (If you all use the exact same version and OS you won't have any). Other than that general.reld stores some of the settings in the General Game Data menu, along with ohrrpgce.gen.

Don't forget, you can export textboxes to a text file, edit and merge that, and reimport. Likewise, exporting graphics so that people can safely make concurrent edits might help.

*EDIT: actually, you can use the tabulate.py tol to convert certain files to spreadsheets, and manually merge them. That's not fun.

Wow, thanks for the outpouring of information, everybody!

With this advice I'll try to divide the labor sensibly, although I imagine everybody's going to want to do a little bit of everything, so it'll take a bit of experimenting to get into a groove. We'll try making a silly testing game for a week or two to get the hang of things before we invest our souls too heavily in work we wouldn't want to lose or re-create.

It would indeed be awesome if Custom had a merge tool!

If you wanted to have different people working with the same assets, you could maybe have a rotating schedule where someone gets to work with X part of the game project on one week, another person works with it another week, etc.

That would be a good middle ground between making different areas of development totally staked out and walled off, and people editing the same file at the same time and cancelling out eachothers' updates.

I'm leaning toward doing that, at least until we figure out whether people really prefer to have individual domains. Most of these people have never used the OHR before. They're all smart guys, so they'll figure it out, but I just can't predict what everybody's going to enjoy doing the most.

We might also be able to maintain a "Hey, I'm working on this right now!" kind of check-out system for each component via email chain. That could get messy. Nevertheless I might try it first -- we'd figure out really quickly if it wasn't working out and I think the potential upside is worth the experiment.