Also, we will have handouts (or, rather, point to the necessary backstop material), but we will have to present enough framework to make the activities meaningful. We do intend to have much emphasis of hands on, however. Hopefully you’ll be happy with the balance.

Agreed. Not only is the design the critical part, but I think it’s harder than the programming, too. (I can program a game, but I don’t think I can design a great one for corporate learning … yet.) Plus, if the game design is solid, the programming & visuals doesn’t have to be over the top or glitzy. For example, I’m impressed by the First Aid game here.

… Your original post asked, “What should we skip?” My suggestions are:
1. Don’t preach to the choir. You don’t have to sell immersive learning simulations to us, the attendees are already self-selected believers or at least optimists.
2. Anything that can be put in a handout, save it for the handout. Save as much time for hands-on, collaboration, and dialogue. Keep history, theory, and definitions to the minimum necessary for us to understand you, and put the rest in the hand-out. If it’s covered just as well in your book as you can cover it in person, then save it for your book, because seminar time is more expensive than buying a book.

Let’s be clear; it’s not programming games, it’s getting the design right, but that is what is critical anyways. As you’ll see. Hope that this answers your questions, and that we see you there!

Does that mean that the attendees will work through a design case study hands-on? Or does that mean that you will present a case study?
In general, I’m interested in if the attendees can expect any hands-on experiences during the seminar, and if so, how much? Thanks!