Looking to use Pico-8 with my first year game dev students. However, they usually start in groups of two to six (I let them choose who to work with for their first game), using GitHub issues to document their progress, and source code control (again via GitHub) to coordinate collaborative development. How good is Pico-8's .p8 format to merges, in your experience? I can see the distinct sections should allow parallel development, so long as there aren't two people working on the map or the sprites at the same time. But it would be good to get the experiences of those who may have used source code control collaboratively, to see what potential conflicts there might be with merges, etc. Alternatively, how easy is it to copy and paste sprites and maps (the graphics-based elements) between different branched versions?

DoctorMike

I don't have an answer, but I am interested to see what you come up with, as I have considered the same thing (though not in a class setting).

I have considered using node or python to write a "build" script that could consider tabs, gfx, map, sfx, and music as separate files then quickly merge them. I would use this with an IDE so I could incorporate it into the "run" function, so whenever I went to run it would auto-build from separate files. This sounds kind of clunky though, especially for students.

@DoctorMikeReddy: I think it should work fine, but yes, manually resolving merges involving the map/sprite/sfx/music sections will be slightly harder since they're not readily human readable. Some text editor PICO-8 grammars (like Atom's) can display the sprite (and label) data as colored blocks, which makes it a bit easier if you can use the editor for diffing.

@paloblancogames There's already a myriad of such scripts: https://pico-8.github.io/awesome-PICO-8/#tools

(Self-promotion:) picotool in particular is intended for merging sections of carts such as for collaboration. Look at "p8tool build". https://github.com/dansanderson/picotool

FYI I haven't updated picotool to some of 0.1.12's features, especially #include. picotool has its own require() build-time mechanism as an alternative until I get around to updating it.

The latest version of Pico-8 has #include for code, allowing the code to be stored in separate files. This might help your merging.

The other sections are not human readable as others have said, but they are plain text, divided into lines, and should merge automatically for people working on different sections.

@DoctorMikeReddy pico games are by definition small - working on a codebase that is max 2000 lines with more than 2 is simply not going to work (regardless of tooling). There is simply not enough work to split.

note: I’ve seen that at my kid uni, groups are often too large for what students can really achieve.

@freds72 makes a really good point. I was considering using multiple carts, with students working semi-autonomously, possibly using save game or other files to allow inter-operability between carts. However, even with that, the small nature of the restrictions, while individually liberating, might cause issues with collaborations. Ah well, I think it is still important to see how GitHub merges can be streamlined, the purpose for doing this seems moot. Maybe this would be better for our game dev club projects, rather than assignments.

Thanks to all for the ideas though.

DoctorMike