A greeting, and a mild plea for help

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • A greeting, and a mild plea for help

      Hello everyone. My name is Sean Wcisel, I'm a Computer Science major at Western Michigan University. I got Mike's book about six months ago (at the time, I'll admit it was a bit over my head), and it's really become my favorite reference text for most of the general programming I do. When I get too stressed with school and work, I flip through the "tales from the pixel mines", and remind myself exactly what I'm shooting for.

      The book provided an immense amount of insight, and though I've only attempted micro-trials of the source provided, I'm getting more comfortable with the concept of view, logic, and application. If someone could just give me a bit of insight here, I should be all set to start my own gaming venture:

      I'm having a bit of trouble organizing myself, or rather, my initialization code. I want to initialize direct3d, a keyboard object, a mouse object, etc. I'm not sure which objects will need to be in their own classes, and which can be grouped. I more or less just need a bit of help with my heirarchy, if anyone has a good visual model, I'd really appreciate it.

      I look foward to working and communicating with you guys in the future, and Mike (don't know how often he lurks around here, but what the heck), thanks for the incredible book!

    • View, Logic, and Application

      Hi Sean,

      I think Application is the term used to describe the overall system that binds all of the pieces together. View and Logic are meant to describe the two pieces that make up the components of each system.

      The reason components are broken up into two pieces is because we are making the assumption that this will be a game that is played online through a network. (More explained later).

      To help visualize your code, start with a simple loop that has a start, middle, and end. The middle part would be a loop that cycles. This will eventually evolve to become the framework of your app.

      Now think about the pieces that a game would need in terms of individual components of a larger system. The obvious ones are audio, graphics, and input. Less obvious ones might be physics, AI, networking, and maybe even something game specific, such as weapon effects.

      Let's use graphics as a starting example. So this component would be separated between view and logic. In other words, there will be a graphics view class and a graphics logic class. The logic class is the nuts and bolts of the graphics component. It is a self-contained system that essentially can be copied over into any codebase without reguards to what the rest of the app needs. It is written from the point of view of that particular graphics engine. Logic might not be the best term for this class, but there ya go.

      In contrast, the view class is a great term because it is essentially the eyes and ears of the logic class. In terms of design patterns, the view class is an adapater between the logic class and the rest of the application. The view class will be an event listener. It will take those events that it cares about and make sure that the graphics logic does something useful with those events. The view class is meant to prevent the rest of the application having to #include "GraphicsLogic.h" and making direct calls to GraphicsLogic. The benefit of this separation is that you can have multiple programmers working in a team without colliding with each other too much because the components are decoupled, thanks to the use of the event system.

      There will be exceptions made to the use of the event system in the name of optimization. This will occur mostly with graphics, but these exceptions should be few and far between because they close off an avenue for networking.

      So on the subject of networking, if you adhere to the view and logic architecture throughout your application, then you essentially have a codebase that is network ready. All you have to do is translate incoming network packets into events and events into outgoing network packets.

      Even without networking, this event system use of the view/logic architecture is a great way to keep programmers from tripping over each other.

    • RE: A greeting, and a mild plea for help

      Hey there Sean - and welcome to the site!

      The answer to your last question is "quite often", in fact I usually peek on the site a few times per day, but I can almost never beat some of the posters to answering a question first (right, Kain???).

      That's a good thing, in my opinion!

      Here's a litmus test for how to separate subsystems into the application layer, logic layer and view layer:

      If the code is "close to the hardware" or "close to the operating system" then it exists in the Application Layer. In a perfect world, porting the game to a new platform or a new OS would require changes only to code in the Application Layer, and no where else.

      If the code seems to mess with game rules - how things move about or how the state of the game universe changes - then it exists in the Logic Layer. For example, if a weapon in your game takes a clip of ammo, and that ammo clip has a certain size, say 90 rounds, then changing it to become 91 rounds would be a game logic change.

      But, what happens if the ammo clip could suddenly take 180 rounds, you ask? Wouldn't that look different? Would that, then, require a change in the appearance of this ammo clip????

      Yes it would - and that beastie exists in the game view.

      If a game subsystem affects how a game looks, or how an independant entity like a human player sends requests to change the game state - like pulling the trigger of their weapon loaded with 180 rounds of ammo - then the system exists in the game view.

      As you can see - some things like an ammo clip, have both a game state (180 rounds), and an appearance in the game (a huge f-ing clip of ammo). So they have bits of themselves in both Logic and View.

      Now, this describes a "perfect" world - one of those things you learn about in college but doesn't really exist once you graduate!

      The point is - don't be afraid to build something that isn't perfect. You might actually learn something - and you might even invent something better than anyone has ever seen.

      I hope that helps....
      Mr.Mike
      Author, Programmer, Brewer, Patriot

    • Let me see if I've got this straight:

      Application is essentially an independant entity, I code one application layer to manage each other component, and calls to those components. I would create a logic class of a component, graphics, for example, and use the view and logic layers differently. In this case, view would interact with my application to determine which graphics to load, then send those calls to the logic layer, which would directly manage them. To use an example true computer geeks can appreciate: my view is like Tron, and the logic layer would be the tools he uses. I want my view to manipulate the logic for me.

      Whew, assuming that's nearly correct, I might be on my way out of this little rut I've gotten myself into. I work a graveyard shift as a security guard at a factory (gotta pay for school, ya know?), so I figured I'd kill some time playing with the Teapotwars code. Long story short, I forgot to install the DirectX SDK on my laptop (not to mention visual C++, I just had lame ol' Bloodshed).

      Well, to be honest, I'm still a bit star-struck, but thanks a ton for the help guys. It's tough to find a site where you'll get one, let alone two thorough responses like that.

    • Wow! Thank goodness for small miracles, eh? I had about four follow-up questions, but they all answered themselves as I was typing :D . I now realize this is probably the wrong section to have placed the latter part of this thread in, and that the dual purpose of this topic inherantly makes it a fish out of water in any forum section. Unfortunately my "greeting" and "plea" are now uncleavable, let them stand as a testiment to my shameful efficiency . :P

      Thanks as always for the blistering fast feedback.

    • Well guys, I'm still having a bit of trouble. I don't suppose anyone has a really simple example I could pick apart and build on. I could really use something that just initializes, maybe takes input from a couple buttons, and closes with a simple command. The teapotwars example is a little over my head :( . I'm sure I'm at that point just before things "click" for me.

      P.S. speaking of teapotwars, I'm having some trouble with the whole nxphysics thing. I've got the SDK, but it's being a bit of a headache. I'm not complaining; I'm just saying that I haven't been able to play with the code after all. Thanks a ton guys!


      -Sean

      The post was edited 1 time, last by SeanWC ().