Video Game Theory: Static and Dynamic Elements

Editor’s note: The following blog was written by a Opinion-blogger. The thoughts and opinions expressed are those of the individual writer and does not necessarily reflect the views of NordicGameBits or the other writers and authors of the community. 

Last week and the week before, we looked at two different video games that were each designed with a specific kind of formal element at the center of their design.

The sprawling cities of Assassin’s Creed 2 belied that game’s focus on place. The feel of being somewhere that the player could then act in front of. The game world as a backdrop place for the player’s actions.

The dizzying geometry of Super Hexagon intimated a focus on action. The constant motion of everything in the game, including the fluidity of its meaning, set the player free in movement and mind. The actions of the player take centre stage and dictate the flow of the game world.

This week, I’ll try to argue for a further abstraction of this part of our vocabulary to build on our video game theory. This, I fear, is not as easily done through analysis of single games as the last two weeks, so I’ll have to lay out the terms first and then show how they relate to a couple of examples. And one of these examples is not even a game!

Once these abstract categories are in place, however, I’m ready to fulfil my promise of getting to some detailed analysis next time. So let’s stride onward.



I propose that in lieu of place, we use the term static elements and in lieu of action, we use the term dynamic elements. This allows us to keep our vocabulary from our model from the first week, where we agreed on looking for formal elements in design, and it lines up very well with a part of video game heritage that is often overlooked in analysis.


Video games are computer systems and are basically made the same way bank software is – through development and code. Since games have a strong basis in hacker culture, though, the formal deployment of system development methods have rarely been at the centre stage of the interpretation of games as objects. Nevertheless, games share some fundamental, structural conditions with other computer programs, one of which is that programs are made up of static elements that are the objects in the systems and dynamic elements that are the possible interactions of users with these objects and how the objects are affected.

In a banking system, for instance, you would have objects representing customer accounts that were static elements, while dynamic elements would be the action that can be taken with these accounts –withdrawing, depositing, etc. – as well as the variables in the static objects that can be changed by those actions – mainly the balance of the account. As a customer, this is how we interact with banking systems, dynamically moving our overdraft from one account to the other to minimise penalty interest rates, while the accounts themselves are static objects.

Summing up the terms

While system architecture is a bit more complex than that in reality, it will serve us well enough for our purpose here to simply state the following on our two types of formal elements:

Static elements: Objects that the player cannot influence, but is presented with as parts of the game world to be accepted.

Dynamic elements: Interactions with objects and any results of these interactions in the game world.


Example time


A simple example of this that relates to games was brought to my attention in a discussion today. When you create a squad in XCOM: Enemy Unknown by Firaxis Games, you have the option of naming them yourselves. The squad members’ nationality, gender and even their classes are static elements, but the dynamic element is the name you can assign and the customisation of their abilities as they progress in level.

The static element is meant to simulate that there are certain things that are structural or technical when it comes to soldiers. They are born with a certain nationality, they identify as a certain gender and they have certain talents and specialisations. This is data that is simply related to resource management and is best kept static to reduce the amount of time a player has to use to manage his or her resources in what is essentially a strategic war game.

However, the point of XCOM is also to depict attachment between commanders and soldiers, and to this end, player interaction is needed. Trying to conjure feeling for soldiers whose gameplay function necessitates portraying them as resources through static elements would be a nearly impossible task involving enormous amounts of content creation, with hours of well-crafted cutscenes and voice-over work.

Instead, the XCOM developers simply inject the ability of the player to name their soldiers – analogous to a commander befriending his or her troops – and make choices regarding their training. This makes it hurt all the more when soldiers die in the field – as they undoubtably will. I have heard countless stories of people reloading to save their most loved soldiers. I, myself, would never have accepted as canon the loss of my best sniper: the plucky redhead Israeli, Willow Rosenberg.

(Yeah, I grew up on Buffy.)

This efficient deployment of static and dynamic elements achieves a high degree of player involvement that goes beyond what pure resource management can achieve and points to what I consider to be the unique offer of well-designed video games: a balance between static and dynamic elements can transcend both.


A short interruption

Next time, I’ll look in detail at an example of how this is done well in a section of a game.

I say next time, because chances are that I’ll be taking time off next week for the holidays, so I’ll probably see you all again in two weeks.

Season’s greetings to all!



I’m an associate professor at the Dania Academy of Higher Education in Grenaa, Denmark. We offer two AP level educations focused on game development, one for programmers and one for designers. I teach a flurry of different analytical disciplines, and I will be blogging about various forms of analysis from gameplay and narrative analysis of games to marketing analysis and even occasionally object oriented analysis in relation to game development. My focus is on making analysis a practical skill. I hope to produce insights and lessons for use in further design, rather than analysing for pure fun and knowledge – though that certainly also has its place. Oh, and a warning: I have a weird background for games – philosophy and the study of religion – which may bleed through from time to time. I will try to blog at least once a week – always on Thursdays, occasionally also on Mondays.

Related posts