I have heard people say that programming can be fun. Even, I have said that I enjoy programming. Is it possible to say that programming is similar to a game experience from the perspective of the developers?
In the nature of engineering there are somethings that works like games, for instance:
- in both there is a goal.
- in both there is a way to lose, which is meant to be avoided.
- in both there is a set of possible actions you have to do at each moment, and the correct execution of these leads to the goal.
- in both there are factors that maybe random.
But that looking at an academic point of view of games, it doesn't tell about how much you can enjoy programming, it just says that it is possible. Programming may be seen as a game, but it may as well be just be a bad game.
Is programming adictive?
Think about how the most addictive games (or may be I should say compulsive games). Those games are not about joy, they are about keep people comming back, no matter if they like doing it.
The mechanics of these games is simple: it's a roulette. It works the same way people gets addicted to casinos, because it give you random rewards with the potential to be big enough to pay for what you have lost. You just can't leave the casino because the next one may be a winner.
Do you hate it if you leave a casino machine just to see that the next person to sit down wins the big prize? Well, you may hate it if that happens. You better stay there until you win. That's the core of the adiction.
¿Example of these games? The industry has learned to do this in a very sutil way, they place monsters in the game, which you may or not kill, but if you kill them, then they will drop money and some other random items. Those random items have value (even if they are virtual) because you took the descision and effort to beat a whole monster to get it! If it's hard to get, you will appreciate it.
Does programming have this characteristic? Well, yes and no. You do not program by pressing "sword button", "sword button", "sword button". But there are some repetitive parts of programming... which you should not be repeating that much.
But you can fight monsters, which are optional in most cases. These monsters are optional because you may as well download something already done. You know, do not reinvent the wheel. These monsters are algorithms and data structures. If you implement a datastructure in a reutilizable way then that implementation has value. It has value because you implemented a whole algoritm! and what takes affort has value. What programming is lacking is the random part, which makes programming less adictive than it's casino counterpart.
Inmersion
Inmersion is a key characteristic of role playing games. That is to become the player a part of the history. This gives to the player the power to change the outcome of the game, and to see and enjoy the effects dynamically.
To have inmersion in a game, you want a game that reacts to the player. A game that behave like it were alive, and also that lets the player change it. These enviroments makes the player feel and become part fo the narrative.
There are two kinds of programming enviroments that exhibit this characteristic:
- Those with a REPL (Read - Evaluate - Print Loop), such as Python, which have an insterface similar to a terminal that lets you run commands on the fly. It's like the software were growing as you write it.
- Those like Visual Basic, that let you build software graphically, it enhance the constructive part of us, and supplies the need to leave legacy for comming generations. It's like creating the software from building blocks.
Please allow me to mention, that any language can be of those kinds, because the magic is done at compiler level, in fact, currently C# is both of those two kinds I mention above... in Mono C# have a REPL, and in Visual Studio it has both Form and Class Diagram designers. (In Mono there is a Form designer too).
Cooperation and Competition
Most games have one or the other, to be fair, those games with both are usually better. In competition we learn to defend ourself while reaching a goal, this is one of the objetive of playing in the nature, to teach the new ofprings how to defend themselves. In cooperation we also learn to survive, but from a hard enviroment or some other threat that requires to work as a team.
Beyond the instincts level, Cooperation and Compettion allow us to share emotions with our co-players, that makes stronger links with them, and creates synergy. Combined with Inmersion, this becomes an strong tool for human relationships.
In programming we may have both, Cooperation and Competition. Although Cooperation is what is mostly promoted in the industry, Competition will never disapear. Also Competition in programming as competition in more physical enviroments is becoming a kind of sport. For example there are regular competitions and Internet sites dedicated only to that matter. Fo example TopCoder and Google Code Jam.
Learning
Believe it or not, learning is a crucial part of playing. But not in the old classroom sense. To have things to discover and explore allows us to develop our investigation skills, and also give satisfaction to our never ending curiosity.
As mentioned before, the porpuse of playing is to learn to do things. It's usual that children play with toy versions of things they will be using when adults, such as cars for example. There are some toys that parents give their children to mold their behaviour (even if they do not know what they are doing, new toys mold their behaviour), for example there are toys meant for girls, which resemble what the society expect from girls when they grow up (such as cooking? and... choosing a boyfriend with a car?).
Beyond those impositions, toys have the power to teach in two ways:
- Constructive: allowing to explore interactions and pruposes of the things
- Desctructive: allowing to explore internal mechanics by taking that toy apart.
Programming also have that learning component, you can learn on a constructive way, by trial and error. Or in a desctructive way by discepting in open source software, just to see what happens if. Or in a more pasive way, just reading code.
Reputation
It's hard to find something more attractive than status. People have a need to find friends, couples and support by third party, this guaranties to stay alive in the old jungle. Today it's about getting more rewards, and a better car. Status is also atractive for dating, but that's another matter.
The point is that everybody want some level of status, and what is status? status is visibility of those monsters you have killed, so every body knows you are somebody. That you have a name.
Building a reputation in software is usually very hard, the end user doesn't care, bacause for them you are hardly more than the name behind the feature. But between developers the thing is a bit easier. But let's think about this... if I want reputation I should show what I have done, and that means that others may learn from it, and even take it for their profit.
It's a hard decision for many. Do you want to share your source code?
If you do... Will it give you money?
I can asure you that it will give you reputation and you will enjoy it. About money I can't be that sure, but it won't hurt to only reveal somethings and keep others closed from the public.
Conclution
Programming may not have all the components of a game, but it have those needed to allow people to enjoy it. It still lacks some important aspects, like keeping highscores. But it's proven that it's all comunity and developer enviroment magic. It's not about the hardware or the language you choose, but it's the tools and the people that will make the diference between enjoying or hating programming.
