This book is a work in progress, comments are welcome to: johno(at)johno(dot)se
aka "MVC for game programmers"
aka "fear the cache"
perhaps call it: Immediate Mode - Ramifications of the Time-Space tradeoff
It seems to me that the structure of the book is emerging, in that I could have a more story-oriented / texty section first (according to the roadmap below), which references the second section which would be more codey / technical / detail oriented.
General introduction to the book, with background/prerequisite information. Be careful not to make this too long or ranty or personal/irrelevant to what the book is actually about. Focus on the book being like GOF, in that it is a practical book / cookbook with useful tips and trix.
Potential sections/chapters:
In general, need a chapter on what I mean by Immediate Mode MVC, and how that relates to everything else. Starting with a talk on visualisation is probably a good way of getting people to reevaluate their assumptions. Stuff on rendering trends, scene graphics, etc, with examples. Later, go into that this revolves around caching stuff (usually for performance), and how that usually leads to systems that are harder to maintain. Talk about the space-time tradeoff here.
Potential sections/chapters:
The main thing to communicate revolves around the high level application architecture that a MVC/E approach gives you. Immediate Mode pertains especially to rendering, as it seems that most people are stuck in the scene-graph/RM mindset concerning rendering. Should not stress or imply that View should be completely stateless, but rather that it should be possible to switch Controllers on the fly without requiring manual cleanup of anything pertaining to rendering, for example switching from editor mode to play mode.
This in turn implies very many things about the "renderer", as well as the existence of the data to be operated upon and visualized (the Model, the actual state of the application). A tendency towards having the entire model in place in memory at all times is central here, and NOT having the Model and it's state coupled to a particular controller / appstate, as GC2 did. The classic example here would be the mission statistics, that were generated in the "in-game" appstate and needed later to be visualized in the "out of game" appstate. This should be solved by having this data in the Model, and having the Model resident in memory at all times.
Potential sections/chapters:
Very much of all of this also stems from the client/server model, and the premise that you want to run some parts of the application remotely (i.e. the server) and some parts locally (i.e. the client). This in turn implies a split of logic from input and presentation, and in my case this was approached in a variety of ways, as explained in the Multiplayer Architectures section.
Probably best to introduce the MVC thing in the local case first, in order to show that the remote case can easily be grafted onto this foundation. Stress the importance of avoiding duplication of state in a single application, even if this means just 2 copies of the same kinds of objects (i.e. WIC). Having the Model be a singleton would actually help stress this point, but it's important that the const& access is enforced. Might be tricky, as the top level Application class needs to be able to update the Model (i.e. not a const method).
IEventTarget and the read/write formality it imposes is central to transparently supporting the remote case, but it is also very useful in the local case as it enforces an asychronous mindset. Stress that applications that are intended to run across a network are easier to handle if they are asynchronous to begin with.
Potential sections/chapters:
This is also a major point, basically that you can avoid things like Juice and XML if you:
Relational data organisation vs Heirarchical data organisation
Real-time Multiuser Editing: Talk about the potential real-time multiuser editing via IEventTarget, i.e. implementing edit events across the network vs state syncing the result of edits (i.e. the map)
Potential sections/chapters:
IMGUI is really a central part of being able to leverage MVCE, because without it you aren't going to be especially keen on knocking together all the little editors that you need (and evolving and maintaining them). RMGUIs will often lead you down the path of more generalisation, simply because making all the little custom editors you would otherwise do is too much work.
Talk about re-evaluating the types of widgets that you might need, and question the standards that Microsoft have been pushing via MFC. Talk about more dynamic views, better use of screen real-estate that doesn't necessarily revolve around scrolling and overlapped windows. In general question the need for windows.
Potential sections/chapters:
Explain the long road from GC, via Josephine and GC2, to MVC/E. How we early on at Massive (1997) chose the Client/Server path. How we realized that we need a client version and a server version of the same concept (game entities), due to reasons of address space, and we figured that these representations should be different because we felt it conceptually unpure to have rendering code on the server. We had played Quake and thought that dedicated servers were really cool.
How I dabbled in persistence on Josephine, because we had decided during GC that savegames were really hard to implement, and therefore didn't, but how we realized that Josephine required them. Enter Juice as many things: a data definition language, a persistence scheme, a runtime memory format. The horrors of the PostOffice idea, a great example of abstraction and event driven systems gone to hell.
possible sidetrack - The various gui systems in use through all the projects. How they all subscribed to the MFC idea of widgets being objects. How that resulted in no gui system ever being reused at all. How that was a big problem until hobbe introduced me via Casey to IMGUI.
How Juice, for performance reasons (load times, etc) evolved into Ice. The hashing of typenames and instance names. How Ice was reused in GC2 because of similar data definition needs (compare with GC's many custom text file formats). How JuiceMaker, created for Josephine, was further extended and augmented to make even better editors for the specific needs of GC2. How this was the foundation of my understanding of MVC, in that it was possible, due to the reflection/introspection features of Juice, to craft editors for specific cases, general cases (spreadsheets), and everything in between. The realisation that there is great value in being able to inspect data and derive other data from this, and also visualize data in a number of different ways.
How the IPlayer/IGame architecture grew from GC's message based local/remote abstraction, as a higher level alternative (methods instead of messages). How this worked better, but how the realisation slowly grew that there was still insane amounts of state replication (all the IPlayer implementations). How this further paved the road for MVC.
How after Massive I continued expanding on the Model/View/IEventTarget idea, having realized that Model and View needed to be separate. How the concept of "reads are free, writes are controlled" evolved. How locality abstraction of the "real Model" works via IEventTarget and const Model&.
How work at Wireless Car forced a much better understanding of MVC, figuring out what Controllers are, the Web Paradigm, stateless / programmable Views. How IMGUI was applicable in the web case as well. How this was fed back into C++/games.
The current state of things concerning MVC, how this is used in current projects. MetaController, multipler Controllers.
The current state of things concerning persistence, derived from the final GC2 savegame system. The late realisation of the values of the relational model, further solidifying my belief in the values of MVC (state != visualisation). Talk about this in relation to the OOPs section, in that maybe objects should do everything possible with their own state (persistence, visualisation, etc).
MVC
Multiplayer architectures - Duplicate info on Model/View/IEventTarget… det är ju rendan ingående beskrivet i föregående kapitel.
Juice, JuiceMaker, Ice, Kokos - Very detailed, med kodexempel och allt, information on NOT how to do it... ;) Kanske inte skulle vara så ingående detaljerat då...
Datadriven, persistance, autopersistance, mm
Generella saker: