Thursday, 23 October 2014

Marking Criteria

Hello once again, readers!

On my course, part of the proposal for our dissertations is to lay out some basic marking criteria to help the markers to know what they're looking for in our work. This means that, for example, a modelling dissertation with focus on texture artwork won't be marked down too heavily for poor sculpture quality.

As I stated in my introductory post, the emphasis of my dissertation will be on coding, specifically in the C# language. This means that I would want the marker to focus on the same elements of the products that I create, rather than, say, the artwork, or the fundamental design of the game.

So, what kinds of things would I like the markers to look for in the games I will be creating for the dissertation? Well, for one, does the game function?
If the game simply doesn't work, then that represents a serious problem in the code, and a failure on the coder's part to fix it before the deadline. A game which doesn't function can't typically be legally sold, and will give the user a very bad experience. In this context, my games need to be able to load, play out, and end without any serious problems which would directly prevent the user from progressing or the game proceeding to operate.

Does the game include any noticeable bugs?
Even if the game works at a basic level, bugs can ruin the user's experience by affecting their ability to play the game effectively, breaking their immersion, or preventing them from advancing. These should have been ironed out by the coder(s) before the game's deadline.

Is the product even a "game"?
Obviously, for a product described and marked or reviewed as a game, it should actually be a game. For the purpose of this dissertation, I would like the definition of a game offered by Eric Zimmerman and Katie Salen (in their book Rules of Play: Game Design Fundamentals, page 80) to be used to ensure my products are games:
"A game is a system in which players engage in artificial conflict, defined by rules, that results in a quantifiable outcome."
That means that the products must have some level of gameplay and user-interactivity, a set of rules to govern this gameplay, and both victory and failure states (whether implied or explicit) based upon the user's actions.

Other than these major points, I would also like my work to be checked for good coding practise; this means that I must follow basic practises like:

  • commenting explanations of each part of the code
  • laying out the code in a sensible manner (I keep variables at the top, where they're easily accessible, and prefer to lay out functions in a conceptually chronological order, such as Activation at the top and Deactivation at the bottom) whenever possible
  • and ensuring that the code is efficient (or at least isn't horribly inefficient). This mostly involves ensuring that no un-used, un-needed or repeating variables or functions remain.


Now, while my dissertation is primarily coding-based, there are also some lesser elements of basic design, notably in the planning stages of my projects, and in the implementation of the mechanics. Of course, the design shouldn't be the focus when marking my work, but I think that it's only fair that the design of the games I create affect my grade, positively or negatively, on a Computer Games Design course. Therefore, I would like the markers to look at my products (particularly my final product of each semster) as games and assign a small percentage of the mark to the gameplay, and whether or not it is enjoyable to them (or if they can understand how it would be enjoyable to others).

This should provide a basic set of principles I wish to achieve with my dissertation work, and which form the basis for marking my work. If any of my tutors reading this find any problems with it, then I'll be more than happy to add to or rectify this post.

Until the next post, dear readers, have a fine day.

No comments:

Post a Comment