Structuring example projects for a book.

I teach a class on game programming every June, and have since 2011. Through the 2014 camp, XNA was the technology we used. The text for the class was a book that I wrote back in 2007.

Since XNA was officially mothballed this year, I’m writing a new book for the class that focuses on MonoGame and Xamarin Studio.

That’s where the question comes in. I’m struggling with how to structure the examples so that:

  1. MonoGame source is easily referenced by each project (for debugging / tinkering).
  2. A single instance of MonoGame is referenced by the examples so that updates are easier.
  3. Readers who act before reading the text aren’t confused by the (likely) missing MonoGame dependency, referenced from the example(s).

I summarized my thoughts here: Issue #1 (GitHub)

I’d love some feedback on this topic. Barring feedback to the contrary, my strategy will likely be:

  1. Fork MonoGame, then create a branch for the examples.
  2. Add my examples in a subfolder of that branch.
  3. Have a single solution (per platform) that houses all examples.
  4. Create source files to build my solution and project files alongside MonoGame when protobuild is executed.
  5. With each MonoGame release, test (and tweak as needed) examples before merging latest stable MB release back into my branch.
  6. Use Tags to mark stable version snapshots?

Why start with a fork? I’m glad you asked.

I expect some readers to be a little enthusiastic, jumping straight to the samples before reading the text. I’m not a fan of expecting the user to have an existing, parallel / peer project with MonoGame sources at the ready, and I’m not so delusional as to believe that my examples would be accepted into the main samples repo.

So … Thoughts?

UPDATE: I went ahead with (IMO) the best of a group of bad options.

New repo created. Moved issue here: Issue #1 (GitHub)

To avoid confusion, I’ll kill the old repo once I’ve fully kicked the tires and committed to using the scheme described.