Wednesday, January 27, 2010

Model from Combat in Context

February 5th, 2008 asgoodwin

I was thinking more about the model for analysis of video games from the Combat in Context article.

Just as a reminder, the model is 1) Platform, 2) Game code, 3) Game form, 4) Interface, 5) Reception and Operation.

It is good at describing the dependency structure of a game - code is restricted by capibilities of a platform, form is restricted by the capibilities of the game code, etc. It is also a good description of the bottom up computer architecture. I’ve seen similar levels used to analyse computer programs, and programmers will often talk about the “low level” and “high level” programming similar to this. (Low level will be closer to the computer hardware, programming operating systems for example. High level is a code built on other programming codes, like scripting languages, and the interface and graphics are usually thought of as a high level part of the programming.)

However, I’m not sure it’s the best way to evaluate games, particularly for use in analysis like what we are talking about in our class. I think the computer code section should be expanded to include all the game design from concepts to art to story to the gameplay to code, even though in the end the code will eventually program all the others. I think the other areas are as vital, if not more, to the video game, particularly when looking at it in the same context as film studies would look at film. In general, I don’t think elegant or sloppy code is very important to the game if it has the same output result, except if it causes crashes. In the article, he talks about how the capabilities of the platform - no room for buffering to the screen - made the programmers write the code differently. It is important to know that, but ultimately is it more important to looking at the final project than the concept writing for the game?

If you look at the model as a timeline, then the position would still be the same, but it opens it up what the model can use in examining the game.

(Of course, in my mind the game form is more the “finished product” - what you see and what the code builds. The author might be seeing some of the concept/design stuff there. It just feels a bit off to me the way it is now, in terms of considering the whole game.)

No comments: