Wide screen, narrow thinking
August 26, 2010 by Dino DiniIt is the saddest thing of all…
August 23, 2010 by Dino Dini… is when the deluded, in anger and desperation, spread more delusion in an effort to to shape the world to fit their minds, without regard to the suffering it will eventually cause.
When we see this happening, it is the duty of all of us with some grip of reality left to say “Enough!” and demand the delusion cease.
Abstration: Adding stuff that does nothing?
August 20, 2010 by Dino DiniThis post is inspired by a tweet this morning suggesting that abstraction is simply a way of making code that does nothing but call code that does. Of course I disagree. Abstraction in computer programming creates code that does something very important… it abstracts. Following my philosophy of “right tool for the job”, then abstraction is the tool you use when you want to be able to hide details from higher level functionality. There is more to writing code than thinking about the steps the processor takes to execute it.
The world of programming can be split into roughly two; those programmers who understand the tool of abstraction and those who do not. In my experience, programmers who properly understand the tool of abstraction and its uses are a minority, even though all programmers use abstraction in some shape or form.
To demonstrate what abstraction is I like to use a real world example: good old fashioned post. When you write a letter to someone, you execute a delivery transaction by placing the letter in an envelope. Upon the envelope you write instructions for its delivery. The postal service is then able to deliver the letter without concern about the contents of it. The machines and personnel that execute delivery really do not care about what the mail contains, only the instructions for where the package of information should go.
The above scenario is very similar to software abstraction. The letter has an implementation (the contents) which is encapsulated (in an envelope). The encapsulation has an interface (the writing upon it) that implements a protocol (the address).
Can you imagine a world where letters were delivered according to contents? Where to decide what to do with a letter is was necessary to read it? Think about all the reasons why this would not be a good plan, and you will have your explanation of why we place letters in addressed envelopes. Although one could say “Envelopes are a way of adding more paper and information to a letter that is not needed by either the person who writes it or the person who reads it”, it would hardly be a fair statement, would it?
Of course, abstraction is not without its pitfalls. Let’s take a look at some of the issues.
First of all there is the problem that we have duplication of information (which translates to more memory usage in computer programs, something that usually want to avoid in low level coding). The identity of the recipient is probably both on the letter itself and also on the envelope. This duplication is a common cost of abstraction, although sometimes you can create clever solutions (a plastic window on the envelope that shows you the address on the letter – the equivalent of providing a constant reference to a part of the implementation).
Additionally, the abstraction increases the weight of the letter (which may be considered a loss in performance).
Further there is an interesting cost that you may not have considered: The envelope actually adds some complexity, and thus creates opportunities for things to go wrong that could not otherwise. The address may be incorrect for the contents, as an example, resulting in the letter being delivered to the wrong recipient. The letter may shift in the envelope hiding part of the address in the plastic window (if one is used). The delivery address may be mistaken for the return address and so on.
Do these disadvantages mean that we should not use the addressed envelope tool? Of course not. They are far outweighed by the worse things that would happen if we did not use addressed envelopes. Such things as:
- Privacy (it is not desirable for everyone to be able to read the contents)
- Integrity (if the letter is not protected in an envelope it may become damaged by elemental factors and handling)
- Speed of processing (although the protocol adds complexity and use of resources, it speeds up the process of delivery through use of a standard protocol that is independent of the contents of the letter)
- Simplicity (the life of the postal worker is made much easier by removing information they do not require in order to execute their jobs)
Of course, you may say that programming is different. Well it turns out on analysis (at least it turned out after my own analysis, why not do your own analysis to see if I am right) that even though every programming problem is different, there are issues that arise commonly in all circumstances. By studying the example of letter delivery (if one can get over any prejudice such as “Why on earth is a computer programmer going on about the postal service”) you will learn about abstraction and then be able to apply this to software abstractions. Which brings me to a final advantage of abstraction: fitting multiple complex scenarios into a single unified abstraction is a great way to become versatile. Why? Because you develop a general purpose pattern that can be applied to situations you have never encountered before.
Abstraction is an orgnisational tool that can help you maintain flexibility as complexity increases. If you follow my posts, you may recognize this from a previous post called “Beware the Bemusing Triangle”. In it I described the robust FLEXIBILITY – COMPLEXITY – ORGANISATION triangle. To maintain flexibility in an increasingly complex world, one must get organised and abstraction is the most powerful tool for doing so.
Of course you can go too far. Memos in an office of 4 people do not require addressed envelopes, for example. But this is simply a case of using the right tools for the task. Generally, the more complexity, the greater the need for abstraction.
In video game programming, the most popular programming activity appears to be graphics programming. The irony is that this is probably the least complex part of a video game, compared to asset management, behavior management (also known, inaccurately as AI) and user interfaces. All stuff that many programmers find boring or at the very least “not sexy”, but all stuff that is absolutely essential to shipping a game.
Well, if you are a graphics programmer, layers of abstraction are likely to get in your way, but it is misguided to think that means abstraction is bad. It is not a question of whether or not to abstract, but where to abstract.
One programmer I worked with a many years ago kept moaning at me because I was using virtual methods in a console game. “You can’t do that, it will run like a dog! It will break the cache! blah blah blah blah”. Of course, I know this. I know it because I am a rather experienced programmer (30 years) who has worked on all kinds of platforms, configurations and processors. But I also know that virtual functions are a great way to keep his hacky, messy code away from my code. And I also know that it is far easier to take working, but slow, code and speed it up by adding hacks, than it is to hack from the start and get it to work. So created an abstraction layer using pure virtual classes. I developed the gameplay on a PC. Most of the PC code shipped in the console without modification. The threatened disaster of virtual function cache breaking did not appear. I did not even need to optimise everything.
How did I do that? How did commit the cardinal sin of using virtual functions on a processor that hates virtual functions and get away with it? Simple. I chose where to abstract carefully.
Sure in the depths of the rendering pipeline, virtual functions would be a bad idea. But at the object level, where there may be only 10 or 20 objects being manipulated (or even hundreds), the performance cost of a thin abstraction layer that provides code organisational advantages can hardly be measured. The abstraction I am talking about is at the level of “Place this game object at this location”.
“Hey, Fred”, (real name concealed to protect them), “You know those horrible virtual functions I am using? They are only called a total of about 1000 times per second. That’s a few cycles cost once every millisecond. So this performance impact you keep talking about can hardly be measured. Meanwhile the code works. So please get off my back”.
So next time you have a lead programmer, a colleague or even a teacher speak about the wonders of abstraction, do yourself a favor and try to put any prejudices you have about software engineering away. Remember the letter. Remember that the great programmers find a balance, and that you will never find that balance if you dismiss half of the equation out of hand. You can never choose the right tool if you are unaware of the tool that solves your problem. And you can never learn to be a better programmer if you are prejudiced against the paths that will help you.
Twitress
August 19, 2010 by Dino DiniSome of you might know that I enjoy inventing words. I just made up Twitress which means “A series of tweets over a period of time showing the progress on a project under development”.
OK, so if you want to see the video twitress for Player Manager, follow me on Twitter
Here is a recap of the first two tweets:
Early wip for new football game http://yfrog.us/bg9lez after a few weeks part time. Basic architectural framework complete.
A tiny step further http://yfrog.us/mvgv9z
The return of Player Manager?
August 16, 2010 by Dino DiniYes, I am working on a new game. This is the sequel to my 1990 game Player Manager that I have been waiting 20 years to do.
Why so long? That’s a topic for another day. What I want to post here is a progress report.
Why now? Because someone whom I gave an introduction to game programming (in an attempt a long time ago to train an apprentice) recently declared that he would be extremely willing to help me work on a new game. He’s David Athay, who now lives and works in the US.
Yes that’s all it took. Someone to say “I’ll help” who could and would actually help… with actual programming. It’s a psychological thing really. Sure I could code it all myself, but… I don’t want to. It’s a lonely road… and I am sick and tired of wrestling with APIs… I want to make games.
Games that I can sell. For actual money. In a world where most of the audience want everything for free, and would be quick to point out “there’s more to life than money”. Money is life. Without it I die of starvation and exposure. I would be quite happy if I could earn enough to live on. iPhone may provide some glimmer of hope there. Maybe.
Of course, both of us are doing this in our spare time. There is no funding, or salaries. The project at this stage is only a few weeks old.
David is working on iPhone primarily, since the current idea is an iPhone product, and like I said I want to actually spend my time working on a game, not learning Objective-C.
I am, however, building the game on OS X, because it is a lot easier to develop on a computer platform rather than messing about with the iPhone development kit. In order to achieve this, I am using the Allegro library which serves my purposes well. I have a representation of the game running natively on OS X.
David maintains the iPhone version, and does the appropriate integration to make sure that everything I do on OS X ports to the iPhone.
This is not as difficult as it sounds, because I have developed an architecture that hides the game code from the platform. So in theory, a simple recompile for iPhone is all that is required to keep the games in sync.
What have I done so far? Well I dug out the old graphics for the Megadrive game Dino Dini’s Soccer (a.k.a GOAL! on Amiga and ST). I recreated a pitch map out of the tile set. I gave these to David who quickly implemented them on iPhone.
I have set up my own custom IDE around the Emacs editor and ported my CoreLib library (with vector classes, debugging functions and string classes and so on) from MSVC to GCC.
I have ported and extended my Property Tree system (more on that in a future post) so that I can make appropriate parts of the game data driven.
I have ported my PROC system (this is a software threading/hierarchical finite state machine/event driven system for managing complex behaviors… it actually allows one to write scripts directly in C++… again maybe more on that at a later date).
I have created various classes to abstract away platform specific details.
Right now, I have a scrolling pitch with some sprites… and am about to add the sprite animation system.
The game is going to be 2D for a few reasons. First of all, 3D is simply not as good as 2D for this kind of game. Secondly, I am using existing 2D graphics so that I don’t have to find an artist (at least for a while). Finally, I want to focus on gameplay as quickly as possible. This is going to be an iPhone game after all, I am not trying to compete with FIFA or PES in terms of graphics. I want to get going with creating the gameplay and tuning it, because that is what I love to do when I make a game: I focus on the gameplay above all else. It has worked for me in the past too: The graphics on KICK OFF were appalling. Yet it beat off all other games in the UK to win the Industry Dinner award for “Best 16 bit product” in 1989. Yes, it even beat Populous. Perhaps there is a lesson there.
Back then, the computer systems were heavily constrained: 8Mhz 68000 processors and 128K of ram. I wrote everything in assembler out of necessity, and hand optimised critical areas of code in order to keep the game running at 50 FPS.
Things are very different now, not only in terms of computer hardware, but also in terms of my skills. For the past 10 years I have worked on getting the best out of the C++ programming language, and I feel I have reached the point where I have figured out how to get the most out of it: it actually turns out to be a fairly limited set of patterns and design heuristics that enable me to do 90% of everything I need. So, especially since computer hardware is so much faster now, I am using a proper architecture which will hopefully allow me to develop the game quickly, while of course making it easy to port to other platforms. Flexibility is a key part of my strategy.
I am also, for the first time since 1995, working in a completely Microsoft free development environment. Just saying that makes me feel good. Kickoff, Kickoff2 and Player Manager were developed on the ST (cross assembled for Amiga). GOAL! and Dino Dini’s Soccer were developed on a 486 Dell Unix box. This was Unix before Linux came along. I loved that Unix environment: so powerful, so robust. This is back in 1991: it had a 1024×768 display, 300MB hard disk and… I think 8MB of RAM. You don’t want to know how much it cost. But it was worth it; it paid for itself easily.
However, since about 1996 I have lived with the hell known as Microsoft. Although I always had a unix box handy, they have always been used as servers. Problems with hardware compatibility, the necessity of PC development and so on meant that I was stuck with Mr. Gate’s efforts. These past 14 years of servitude to Mr. Gate’s empire have not been fun. And I have had enough.
But a great thing happened: Apple adopted Unix in OSX. Unfortunately I did not pay much attention until (spurred on by the idea of iPhone development) I got my first Mac last year. Sick and tired of how my PCs would keep going wrong and seem to slow to a crawl and take 10 minutes to reboot … I tried to use the Mac, more to get out of the rut than anything. Now… I consider it my primary machine. Yes, it is what I always wanted: an all round usable versatile computer with lots of commercial software and hardware which runs UNIX. I ain’t going back now… except of course when I have to (for example when teaching).
No doubt this will have many of my students (and some colleagues) shaking their heads. Hey, but that is normal. I’m used to it. At least there’s a context to it now, perhaps. I love UNIX. So I love my Mac.
Anyway, I digress.
I am making a public statement that I am developing a new game, in part to make sure I actually do it. But I have no idea how long it will take at this time. It’s early days. About 21 or so in fact. Stay tuned for more…
Welcome back to the days of… typing…
August 16, 2010 by Dino DiniThere was a man who decided once that what people really wanted on computers was not to have to type.
This obsession with not typing went to extremes, but let’s be honest: people who use the computer a lot learn to type, so I am not so sure that this avoidance of typing is actually sensible.
Yes, goodbye to nice easy to edit files, hello to screens and screens of dialog boxes where you have to click precisely at the right spot and then move your hands from the mouse to the keyboard and back again… and again… and again…
Computers have turned from machines that you “speak” to in words, to machines that you communicate with by pointing. “Over there!” you suggest as you swing your arm to move the mouse as it falls off the table.
I believe the mouse was both a blessing and a curse; but when you look at Microsoft’s treatment of it, you have to wonder whether the blessings are worth it. The obsession with not using text files for configuration of your computer for example. Just try configuring your network adapter IP address. No… you can’t just type in 192.168.1.1. You have to put 192 in the first box, then 168 in the second box, and…. and then if you need to copy the IP address, you can’t. You can’t paste it either.
Pointing is all well and good for some tasks, such as moving windows around, resizing them, selecting them and so on… but using them to execute commands, I am not so sure about. Take the start menu for example. I don’t know about you, but I don’t want to have to search for an application, I want the computer to search for me. Macs have a nice search feature: type in a box and it will try to find the thing you are looking for quickly and easily. Microsoft have followed suit. Well done, computer industry! You are moving us back to the command line, only dressed up.
I have recently gone back to using emacs instead of more “modern” editors. It is a wonderful feeling. Because everything is language based, it is really easy to configure and extend functionality and so on. Because everything can be done from the keyboard, I don’t have to keep moving my hands around. Because there are no gigantic dialog boxes, I don’t have to wait for ages for them to appear.
Oh and there’s no more of that visual studio curse, the property dialog box. I dread to think how much of my life I have wasted waiting for that thing to appear. Or wasted trying to reconfigure a complex project, one tab page at a time. That dialog is so complicated that it ruins the disk cache and slows down recompiles. And there is no way to easily copy settings.
OMG, I have this brilliant idea! Why don’t they replace that dialog fiasco with a text based configuration file, where you can see everything at a glance and copy and paste whole configuration sections? Oh right, sorry it exists already… silly me. It’s the ‘make’ utility that existed since forever.
I am experimenting with ditching that whole “GUI based IDE” thing completely. So far, it is going well for me. Now that I don’t have to point, and search and switch between dialog boxes, and wait for them to open, and wait for them to close… now that I can just pull up a configuration file in an editor and search and replace, cut and paste and save backup versions… now that the computer resources are not eaten up by complicated bloated dialogs… now that I can work faster and actually reap the benefits of faster hardware not dragged down through more bloat… ah… heaven.
Grow up or Blow up
August 14, 2010 by Dino DiniComedian Imran Yusuf (twitter) tweeted recently about a woman from the audience who loved is show, but said that her father “Hates Muslims”. He suggested she buy him his DVD for Christmas.
Got me thinking. The situation of the world and every human being within it can be summarised in the following choice:
Grow Up or Blow up
Yes it really as simple as that. Anyone who hates Mulsims should Grow Up before they Blow Up. If they do not, their anger will feed anger until one day something will blow up, and the suffering that results will be in part upon their heads.
But of course, this does not just apply to hatred of Muslims. It applies to hatred of any generalised group of people. Christians (whether Catholics or Protestants), Jews, Policemen, Video Game Developers, Gays, believers in God or believers in no God, Women, Men and any of thousands of poor groupings of people that get a whole load of hate vibe flying in their direction every second of every single day.
Any of you out there that holds such hatred in their hearts needs to Grow Up before they Blow Up. It’s a choice.
Growing up is a choice.
So, for pity’s sake, let’s all grow up shall we?
Are video games Art? (yes that old chestnut again)
July 30, 2010 by Dino Dini“What is art?” appears to be one of those impossible to answer questions.
Except that it isn’t. To me it is perfectly clear what art is, and when you accept the definition I have in mind (and I maintain that no better definition exists; please prove me wrong if you can) then it becomes unarguable that video games are art.
To understand art, one first must explore what art has that non-art lacks.
It seems clear to me that we as human beings have two sides, almost literally. See Jill Taylor’s brilliant TED talk on that subject
The left side of our brain appears to be concerned with language, logic, intellect, reason, boundaries, time and causality.
The right side of our brain is concerned with everything else, pretty much. The right side does not care about time, or boundaries, or logic (as in a sequence of reasoned steps), causality, boundaries, intellect or language.
The left is the computer within us. The right is something else. Something that cannot be explained by intellect. It is concerned with the experiential, and confounds the intellect with such simple questions as “what is the colour blue?”.
Sure we can state what the colour blue is in terms of language; for example dictionary.com says:
The pure color of a clear sky; the primary color between green and violet in the visible spectrum, an effect of light with a wavelength between 450 and 500 nm.
That really does not explain what blue is, however. It does not explain the experience of blue. The left brain can’t help too much, here.
Yet, in order for someone to convey what blue is with language, the left brain must translate the words for the benefit of the right brain.
What has this to do with a definition of art? Well, let’s look at a poet’s attempt to describe the colour blue:
What is Blue?
A little boy once asked me,
“What is blue?”I wonder how such a question should be answered,
As it doesn’t say,
But after deeply thinking,
I come up with a way.I bend down low,
And begin to speak,
Ready to give him,
The answer he seeks.“Blue is a sapphire sky,
On a hot summer’s day,
It stimulates the senses,
And lets you melt away.”“Blue is the ocean,
Deep and crystal clear,
It draws you in and reminds you,
Of what you hold so dear.”“Blue is a bird,
As wild and as free,
It never fails to give you,
The comfort that you need.”“Blue is a forget me not,
Blowing in the wind,
It heals and protects you,
Even when the lights are dim.”“Thanks!” he said to me,
As his mother came up behind,
He took off his sunglasses,
And I saw that he was blind.by Mary
From a left brain point of view, the poem is certainly using a lot of words in a highly inefficient manner. Intellectually, one can argue, the poem does not say very much. And intellectually this is probably correct. But all those words are not appealing to the left brain. The left brain should simply translate it and shut up.
The reason for all those words, is that there is an attempt to convey something that cannot be conveyed solely intellectually. Language is such a poor tool for this purpose that one has to almost dance around the subject and reveal it not through what is said, but through what isn’t said.
And that is the key to answering the question “What is art?”.
Art is communication that is not purely intellectual.
If the communication is purely intellectual, such as “I want for a walk in the countryside and saw a field of daffodils”, then it is not art.
If instead we say:
I WANDERED lonely as a cloud
That floats on high o’er vales and hills,
When all at once I saw a crowd,
A host, of golden daffodils;
Beside the lake, beneath the trees,
Fluttering and dancing in the breeze.Continuous as the stars that shine
And twinkle on the milky way,
They stretched in never-ending line
Along the margin of a bay:
Ten thousand saw I at a glance,
Tossing their heads in sprightly dance.The waves beside them danced; but they
Out-did the sparkling waves in glee:
A poet could not but be gay,
In such a jocund company:
I gazed–and gazed–but little thought
What wealth the show to me had brought:For oft, when on my couch I lie
In vacant or in pensive mood,
They flash upon that inward eye
Which is the bliss of solitude;
And then my heart with pleasure fills,
And dances with the daffodils.
… then we are engaging in communication beyond intellect and are firmly in the domain of art.
The poem is of course by the appropriately named William Wordsworth, written in 1804.
Certainly, there can be various levels of art; a communication might be almost entirely intellectual with a touch of art or almost entirely art with a touch of intellect. But let us be clear: Intellect and Art are two orthogonal axes in communication between human beings. And thus we can clearly understand what art is.
So, to answer the question of whether video games are art, one actually needs to ask:
“Do video games communicate to the game player something more than what is purely intellectual?”
And the answer is a most emphatic yes; video games are about the experiential as much as they are about the logical. Clearly the ratio of art to intellect varies from game to game, but this is true of all other media already labelled as art.
So when you next see a game player absorbed in a wonderful world of make believe and experiencing things that they could probably never experience for real and feeling the impact of it all in a way that pure intellectual communication could not convey, you will be witnessing art.
Joel Dinolt at the IGAD Never Ending Conference 3: State of the Industry
July 15, 2010 by Dino DiniJoel’s second talk at the June 2010 IGAD Never Ending Conference.
This concludes the videos of the talks. I hope you enjoyed them, and please keep an eye out for the next Never Ending Conference which will be scheduled late October/Early November 2010.
Auto tune – Volume War – Drum ‘Machines’ and the death of music
July 11, 2010 by Dino Dini“Resistance is Futile” was the cry of the Borg, when they were about to assimilate you. I agree with them.
That may be science fiction from the Star trek Universe, so you may think it is nothing to take too seriously, right?
Wrong. The Borg are already here. They have been invading music culture ever since the first audio manipulation technologies become available.
The Borg quest perfection. They value this above all else. They value it above individuality, because there can be only one perfection. They value it above emotion, above humanity.
Their hive mind is concerned with the transfer of information; the efficient means to an end; the continuation of the perfection they create, the fitting together of all minds into one homogeneous existence. They assimilate all species in order to further they aims of perfection.
In music, individual expression, performance, humanity, soul, spirit, that X factor… the very things that mark out a great performer from a nobody or a great performance from insipidity is the ability to communicate an individuality. What makes a great singer great is not that they can sing in tune. It is that when they sing they communicate the essence of who they are.
The increasingly reliance on technology to support the living and breathing of music is rather like the assimilation of human being by the Borg. Music is measured, tolerances are reduced, everything is sterilized and sanitized for the consumption of those who have been fed this sterile food since birth and know nothing different. The beat runs like a machine, the intonation of singing voices strapped firmly to the notes on a piano, the volume at max all the time….
Music is an artistic communication medium not just communicating a composition, but also a performance in the moment. It is about being there. It is about bringing that feeling and emotion that cannot be expressed any other way to the surface. It is about sharing individuality and through that finding the common ground. It is very exciting.
But the Borg are here, and before long I fear that nothing will remain of the true nature of music, except a few isolated pockets of people who still try to make music rather than have machines make it.
Even live performances these days are pitch corrected, if they are performed at all.
Truely I am sick at heart; we are human beings, not machines; but the Borg will take over and the true essence of music, and perhaps humanity, will die…
Bye bye, Loius…
Hello the Borg:
It’s ok. I know, resistance is futile.