Jul 8, 2012 at 1:49 PM
Edited Jul 8, 2012 at 1:50 PM
The Samples have a pretty good ScreenSystem, Input, Asset management and Camera. That would save you a lot of time and might just be enough for a simple game. Also show you how to integrate the DebugView and later on you can extend it easily with your own
shaders and whatnot.
ConvertUnits is fundamental because you need to use the mks system for the physics and not pixels as units. ConvertUnits+Camera are classes you would need to write no matter what anyway.
I would also recommend something different - start by making a TestBed sample (that draws automatically with the DebugView) and integrate it into the TestBed project. This is extremely easy - make a copy of some test that is similar, change the class name,
add new TestEntry and take it from there.
Once you made all your physics work properly the way you want it and have the physics class structure and logic set up then all you need to do is port it into the screensystem and code the drawing bits. Or you can make a scenegraph. But whatever you do you
will know that the physics is working.
I personally also write the GUI stuff in a separate project and integrate it afterwards hooking the gui events to the logic (Model-View-Controller design pattern). The reasoning is to split the tasks into more manageable modules for debugging, testing and
tuning since a complete game is quite complex and can be overwhelming.