Disney Closes Game Publisher LucasArts

They made Videogames history and I have good friends working there. Worst news of the month.

Good job, Mickey Mouse, die.

Source

GDC 2013 Mon Amour

I have a love-love relationship with the Game Developers Conference, since 2006 when I had the chance to give a talk and experience first hand the joy of talking in front of a flock of super techie people staring at me and waiting for my first slip up (and they happened). At the end of that talk I was rewarded by a guy from NVIDIA with a compliment I still cherish: "Fran, I loved how you talk, the rhythm, your pauses, that was good man". I blushed and I was too embarrassed to reply that my manner of speaking was nothing else than heavy jet-lag kicking in and making me literally fall asleep on stage every few minutes. A job well done.

This GDC was ok, mainly because I met some old good friends, from Georg Backer to +Ury Zhilinsky, to the guys at Crytek Kiev and Frankfurt: I can't say I miss Frankfurt, but it was good to see them again.

The talks I attended were ok, nothing spectacular. Clearly mobile gaming is a big big topic, but, from the purely technical point of view, being told in 2013 how blooming is implemented feels a bit old: basically mobile graphics is where desktop graphics was around 2006, it needs the big guns to step in and show these kids how to do shit. The mobile GPUs, though, are getting pretty darn fast: ARM reported that mobile GPUs are almost on par when it comes to computation power with console GPUs (again, about 5 years ago tech), but lose big time when it comes to available bandwidth: accessing external memory takes a lot of power that is a scarce resource in the mobile space. Last take away from this talk: in mobile, deferred GPU kick the proverbial ass.

That leads us to the NVIDIA talk and Tegra 4: Tegra 4 looks very powerful on paper, but it also looks like it could easily be used to warm up your cold winter nights in Europe. An immediate rendering architecture with non-unified shaders is not what you can call power efficient. But it's fast.

But enough with this technical mumbo-jumbo and let me introduce the absolute protagonist of GDC 2013, the undisputed star of the moment, the return of the king... suspense... PROJECT SHIELD.

Applause please

I thought that Microsoft Surface was a pointless device, but Project Shield wins easy-peasy the first price for pointlessness: it doesn't make any sense whatsoever, it's gimmicky, it's ugly, it's cheaply built, I had the "pleasure" to hold one and it felt as it was made of plastic. In fact, it is made of plastic. And it's butt-ugly. Opening the screen makes a weird sound as the hinges weren't properly oiled.

How they can think anyone will buy this is beyond me.

Final word about John Romero, who I met the last day while walking out of a restroom (please, no jokes): this guy rocks, he's nice, approachable, funny, and bright as the sun. He was the highlight of GDC 2013.

I want to learn game programming #2

I tried to scare you away from your foolish desire to learn game programming in the first episode, but if you are still here it means I haven't succeeded just yet. Let's explore, then, what resources are at your disposal if you really want to venture along these treacherous paths.

If you are an absolute beginner and you have never written a line of code before (no worries, we have all been there at some point), you can start here:

• http://www.codecademy.com/tracks/ruby
• http://www.codecademy.com/tracks/python
• http://www.pygame.org

Once you get yourself acquainted with the basics and with solving little problems, you can move down the chain and look at lower level languages such as C#, Java and Objective-C, three C based languages which introduce a higher level of complexity and control over the code you are writing and the concepts you are manipulating. Very unfortunately Microsoft killed XNA, an excellent C# game framework; you can still grab the latest copy of XNA Studio and play with it. It's highly recommended:

• http://msdn.microsoft.com/en-us/library/bb203893.aspx

If you are more of a Java person, you can follow the next tutorial, that will take you from absolute beginner to making Space Invaders yourself! Who doesn't love Space Invaders?

• http://zetcode.com/tutorials/javagamestutorial/

If you are coming straight from the web developing world and you dream in Javascript, there are options for you too, here's a good introduction:

• http://www.devx.com/webdev/10MinuteSolution/27134

And keep an eye on Lanica, these guys are creating a mobile game engine driven in Javascript, coolness all round. You can read more on Lanica's Blog. 

If you have a shiny Mac (why wouldn't you have one?) and think that mobile gaming is the future, download Xcode from the App Store, it's free! Xcode is a difficult environment to learn for a beginner, make sure you cut your teeth with something simpler before having a go at this beast. Once you have Xcode on your Mac, redirect your browsers to the following tutorials and code away:

• http://blog.teamtreehouse.com/an-introduction-to-objective-c
• http://maniacdev.com/2010/08/beginners-iphone-action-game-tutorial/

Beware, here we are entering the realm of serious programming, approach with care and make sure you master the basic concepts first. Objective-C is not an easy language, it's a C dialect that will make you scratch your head several times about object ownership and such. Approach with extreme care and Keep It Simple.

Last, but not least, the rising star of indie game development is Unity 3D: it's a powerful, component based, visual editor for games that can target several platforms easily. It's been used extensively, lots of tutorials are available and scripts can be written C#, Python or Javascript. What's not to like? It takes from where Microsoft left XNA and improves on pretty much everything. It's also an absolute must if you are a visual person.

Point your browsers here now, you'll thank me later:

• http://unity3d.com/unity/download/
• http://answers.unity3d.com/questions/12321/how-can-i-start-learning-unity-fast-list-of-tutori.html

Everything you have learnt earlier will come very handy when you are creating your first game with Unity3D.

While you are learning, don't forget to keep things simple, focus on solving problems and learn the ideas behind what you are doing. Don't get paranoid about writing fast and efficient code now, it is not as important as many seem to preach, or, better, it is not important now for you.

But most importantly: have fun. Choose a language, choose a set of tools and create something simple you like and you know you can finish: the most important skill a programmer can possess is finishing what you started. That alone will get you a shiny, glamorous job in the Game Industry some day.

I want to learn game programming #1

So you really want to learn game programming, and you are asking where to start. I've been on the receiving end of this question so many times, that I tend to answer in autopilot. Let's get the scare talk out of the way first: making videogames is neither glamorous nor will it make you (or me) rich, it just so happens to be our passion.

It's hard work, there's a ton and more knowledge to build up on the technical side before even trying to attempt making a very simple game, and, after that, there's a lot more to learn about how to interact within a game team, with colleagues coming from different nationalities and working in different fields (from programmers to artists to producers to... managers). Work hours are long, depending on where you ended up they are even longer, the dreadful promise of crunch time in the hope that the game will be shipped on time is an always looming menace, with the little solace of the faint hope of a bonus at the end of the project (that practically very rarely or better never materializes). Speaking of money, game programmer is a very low paid job compared to other engineering fields.

If you are here to make money, move away. There's lots of good blogs on the web that teach you databases.

Are you still around?

Next question to answer is: what programming language do I learn?

Quick answer: not C++. Pretty much anything else is fine, but if I have to choose, I'd go for either Python or Ruby, two high level, dynamic languages that take most of the gritty details out of the way while you build up your confidence in writing code. At the beginning especially, you need to focus on learning how to solve problems in a simple manner and how to manage complexity: programming is hard, programming is a blend between engineering and art, programming is a creative and artistic endeavor. Mastering the Art of Programming, being games or any other engineering field, requires years of practice and not everyone will likely succeed: Keep It Simple must be your mantra.

Why not C++? Because it's a bloated, difficult, over complicated, extremely powerful language that will keep you bogged down forever in details that are completely irrelevant to learning programming. You will have to master it one day, but that day is not today.

... to be continued

VFX protest

Making visual effects for a movie is surprisingly similar to making a videogame: the workflow maps very closely, both need graphics engineers, modelers, animators, technical artists, producers, more or less the same process. Historically there has also been a fairly consistent exchange of professionals between the two in the last ten years. I've always looked very closely at the VFX industry to gauge what might happen to the Game Industry, for this reason the news of the VFX protest struck me pretty hard: it's about time there's a protest!



To cut a long story short, many of the visual-effects makers of Life of Pi, who made the creative vision of the award winning movie possible, were let go without compensation for them or their families.
These people are not cheap, they bring with themselves years of technical and artistic expertise that is extremely hard to build up, they work hard, long hours, weekends after weekends with the promise of a bonus after the project is done; a bonus that very rarely materialize. More often than not they are trimmed at the end, by a very competitive industry that is not sustainable in the long term.

Rings a bell? Yes, the same happens in the Game Industry.

Like the VFX industry, the Game Industry is very badly organized, with lousy project management demanding crunch time after crunch time even when all evidence accumulated in a hundred year of research on the matter suggest that it is counterproductive. And like in the VFX industry, workers are let go easily at the end of the project.

People working in the VFX industry and in the Game Industry need to draw a line in the sand, organize themselves and demand sustainable business that rewards who give life to the next Life of Pi or the next LA Noir.

How? Give me some feedback.

XNA is dead - Oh noo!

Actually it's been dead for few weeks, but it took me some time to get over my mourning for what has probably been one of Microsoft's best ideas. The API was well thought, clear, nicely designed and, most of all, simple yet pretty versatile.

So they killed it.

I used to teach XNA Studio at the University back in Germany, my students loved it, I loved it because I could visually show interesting game programming concepts in a very slick environment that could target Windows, Xbox 360 and Windows Mobile, with some very good assets management for small games thrown in the mix. it was a great tool to learn game programming.

So they killed it.

I bet they needed resources to focus on Surface.

Playstation 4

And so Sony announced the Playstation 4. The first thought is that the cell processor wasn't that revolutionary after all. The second thought is that indeed the cell processor sucked precisely as foretold years ago. In fact they announced a PC.

The actual show was very much underwhelming, set aside Alex Evans who is always a sexy beast: Alex, I miss you and our late coding evenings and our chats at the hairdresser in Guildford, my man... I don't miss the english rain though.

But the really scary thought is that my Macbook here will outperform this PC, i mean, this console. My iPad will almost as well.

I must not mention Apple on this blog... I must not mention Apple here...

My biggest hope is that Sony doesn't go bankrupt after launching the PS4, cause I have almost 10.000$ invested in Sony photographic gear: I love my A99V and my Zeiss lenses, please Sony, don't die.

In a galaxy far far away...

... I moved to California to work for Apple more than a year ago, which partially explains the total lack of content in the blog for quite a long time. It also means I don't make games anymore, so writing about games making hasn't felt so pressing for a while. This begs the question: what am I working on now? I can't tell you. Apple wouldn't be Apple if I could happily spill my guts on any blog and tell you exactly what I'm doing. All I can say about my job (aside the fact that it is by far the best job I've ever had) is that my office has no window. Nada, zero, not a single ray of light can penetrate inside (or come out, what interests the most whoever designed the building).



On top of changing job, country, continent, I got married last year with an awesome woman, +Lina Mosashvili.

Better photographic proofs of the event are available on request, including a video that shows my skills in dancing traditional georgian dances. Quiet a feat.

After such a plethora of information that have nothing at all to do with game programming, the second burning question of the post is: will I keep writing about making videogames? Most probably not, but changing the name of the blog is not an option (too lazy), but I can probably still write about software engineering in a more general, and synthetic, way... and, no, I will not write anything about Apple.

One more thing, I opened, together with my better half, a Fine Art Print online store with a collection of my best photographic work: having been a graphics programmer for so long, I wanted to remain somehow in the field. Somehow. Click on the photo and give it a look, there's some good stuff.

tk

Definition of Done

Marcello is considered a brilliant programmer by the team, willing to tackle any task is set upon him, he writes lots of very complicated code in little time. "It will be done in a couple of days", he likes to declare right before diving into his magic. Few days later you can find him typing effortlessly on the keyboard, immersed in his thoughts: "A couple more days, it's going to be very cool".
Some time later, he finally announces triumphantly: "It's done!". The new code is immediately committed to the main line ready to be tried out by designers, eager to cut their teeth with the new shiny piece of technology they were impatiently waiting for.

The new code crash the build.
This story is far too common in our world, but i wouldn’t blame the programmer, often very passionate about his work, so willing to please the hungry designers. The pressure to deliver features is often enormous, bugged and untested features are released, more time is spent fixing past features than developing new ones. And pressure piles up.
I blame the lack of a clear  Definition Of Done, that is able to define without ambiguities when a feature is ready to be deployed to the rest of team and go into production.
The final goal of the Definition of Done is to increase the rate at which working features are produced by the programming team in the long term.
The most common Definition Of Done that I've encountered in the Industry (and often used myself) is something similar to:
It's done when I wrote the code and it works on my machine.
This Definition Of Done is far from being unambiguous: in fact it means different things for each member of the team. To begin with, it's not clear what we mean here by "it works". Have I tried any possible condition in game? Or it works just in my testbed and I'm assuming it works in the game as well? Has someone from QA done a play through? Has he smoke tested the entire game or just a level? Has someone from the design team tried to use the feature? Does it actually do what the designers need? Do all automated tests pass? Is there any automated test at all?
And what about code quality: can code be changed easily if something doesn't work (and it will not work) or if something needs to be modified later (and it will need to be modified)?
Too many open questions without clear and unique answers to make this definition safe for the team. When a feature is "done", the content creators or other engineers can work on it with confidence, knowing that the chance of crashing or not doing what was asked for are minimized. Not zero. Just minimized.
A more useful Definition Of Done is a checklist of activities that needs to capture, more or less closely, the following concepts:
Uniqueness. A feature is "done" at the same stage of development regardless of who has been working on it.
Automation. Criteria can be checked automatically by tools, impact on actual production is minimal.
Quality. Code quality and implementation quality are guaranteed.
Agreeability. The entire team has to agree and stick to the Definition of Done, including designers and management.

The best defense is a good offense

 

My students might be moving their first careful steps in the dangerous lands of programming, but the problems I’m forcing them to face week after week are nothing short than “difficult”, even in code that is seemingly simple and straightforward. This week we were working on a sprite engine in C# (XNA), adding some code to select different sprite animations to play, where an animation is defined as an array of images. The sprite keeps track of the index of the current image being used in the current animation. Pretty straightforward…. crash.

Oh crashes happen, it’s part of the game, and we quickly found out the source of the problem:

Texture2D GetFrame(int index) 
{   
  return frames[index];    
}

An exception, IndexOutOfBound, was being thrown when a new animation is selected: the current index is being maintained by the Sprite class, and it’s not guaranteed that the new animation contains at least the same number of frames of the previous one. GetFrame() can, potentially, receive an index that is out of bound.

Solution: Make sure GetFrame() doesn’t fail if the index is out of bound.

Something like:

Texture2D GetFrame(int index) 
{   
  if (index > frames.Count)     
     index = 0;   
  return frames[index]; 
}

This is a very common approach to the problem that in my opinion is not actually solving it, merely hiding the dirt under carpet of an if guard. Surely, it “fixes” the bug, but at what cost: some added complexity (it’s an if, one more branch and one more unit test to write in an automated tested environment), that hides away the source of the bug; the system can still be in an inconsistent state. We are just trying to keep going in the presence of a blatant fault.

The more stable solution, I explained to the students, is to fix the source of the inconsistency, in this case either having one separate index per animation or, more simply, reset the frame index to zero when a new animation is selected: an animation is guaranteed to always have at least one frame, the code is thus safe, it doesn’t need a check in GetFrame() (one less branch) and it won’t crash… ever.

Unless we have an animation with no frames.

This is precisely the behavior I want: if there’s an animation with no frames, I want the application to crash and tell me if it’s in an inconsistent state that I can not ignore. If it crashes, I have to fix it.

Fail early, fail loud

This simple example shows my students a broader approach to software construction: offensive programming versus defensive programming. Instead of trying to prevent a crash by writing lots of defensive code that checks anything that can possibly go wrong (but obfuscates meaningful and useful code in a see of ifs), I prefer writing less code, but make it so execution stops as early as possible in the presence of inconsistent state, invalid preconditions, broken invariants.

In my experience this approach leads to less and simpler code, easier to modify and with less crashes.

An obvious drawback of offensive programming might be a live system, that is used by clients (content creators?) while it’s being developed: ring a bell? It’s exactly how we work in the Game Industry. Although I’m convinced that it produces less down time in the long run (by producing better and less crash-y code), it’s hard to convince an artist staring at a call-stack that this is a Good Thing™.

I’m again very open to suggestions here, how would you tackle the problem of writing lean and offensive code versus making the content creators experience pleasant in the presence of a (undoubtedly more rare) show stopper?

Some ideas:

• User friendly crash handler
  
• Automated unit, functional and smoke testing before release to minimize crashes
  
• Build staging

I played a lot in the past with unit and functional testing, especially in the form of asset testing to make sure that assets are sanitized before entering the system, with very promising results that led to fairly stable daily release cycles; something very much appreciated by content creators. Still that show stopper is hard to sell…

This post is also available on AltDevBlogADay.

A trip to Berlin

I’ve been teaching game programming at the University of Darmstadt for a couple years now: as they say, teaching something helps you clarifying it in your head. They also say that who can do something does it, who can’t teaches it

Last week I called two “volunteers” as usual to write some code at the main computer in front of the rest of the class, gave them some freedom to choose a solution for a little problem we were having in our XNA game. The solution they came up with was good and, then, they generalized it, writing some more code, and then some more code, and then a little bit more code.

I asked why.

We might need it later

I replied.

So next weekend you want to go to Berlin, spring is finally coming, time to enjoy a bit of sun, it won’t last long here in Germany. You evaluate all the available options, you may take the train (even if they are so expensive here), or go by plane which is not much more expensive than the train and takes less time, or rent a car which would give more freedom but costs a bit more. You discuss it among yourselves for a while, weighing pros and cons against the cost of each option; the train will be around 200 euro per person, same as the a plane ticket, while renting a car would cost around 100 euro per day plus petrol. You finally choose and you buy a car for 5.000 euro. Why? You might need it later. Maybe you will like Berlin so much that you want to travel there every weekend, or you will need the car to go to Amsterdam instead, or even Or maybe you will not do anything like that, and you will spend ten times more now to go to Berlin than if you just hopped on a train…

 

In our daily life we face this kind of tradeoffs and, with material things, we very often rationally choose to spend less now for something we need now, rather than spend more for something we might need later. I’m ignoring for this post the well proved fact that decisions are not always taken rationally (for a good book on the matter look here). In software we usually take the alternative route, we might need it later, we are willing to spend more now for something that more often than not we will not need later. We do it so often that we gave it a name: Over Engineering.

I believe that this peculiar behavior stems from the fact the cost associated to each line of code we write is not directly evident, it’s not money leaving our pockets. It’s also difficult to estimate precisely, which leads to the false perception that generalizing a solution will actually save time. It will not. Each line of code has a cost over time in terms of maintenance and added complexity, that is paid by the team day after day: if it doesn’t solve a problem that we have now, it’s a sunk cost. It requires a huge amount of experience to foresee that “we might need it later” is actually going to be true, and it also requires having gone through the same problem at least few times, which is not always the case in our Industry: we are on the bleeding edge of technology, uncharted territory, where things are complex by nature. Adding more complexity that is strictly needed is not going to help our cause.

Half jokingly with my students, I showed how they could solve the problem with half the number of lines of code, which will probably mean something like half the number of bugs at the end of the project if the idea is applied consistently.

You Aren’t Gonna Need It

Undeniable logic

One of the biggest mistakes I used to make in my career in the Industry was to think that a logic argument, well reasoned and with plenty of data to back it up was enough to convince reasonable and clever people, the kind of people I work with. An example is my favorite topic (no, it’s not commenting code), automated testing and unit testing: we all know that writing unit tests is a Good Thing™. We all do, right? There’s plenty of evidence and my argument for writing unit tests before even writing code is very solid. I was naturally expecting that after some resistance due to various reasons, the vast majority of my co-workers would eventually give up and embrace my reasoning, if not flat out try what I was advocating. But discussing automated testing here is not my goal now: my point is that very few people could actually see and understand my point. How frustrated I had been before realizing that it was all my fault.
It took years to understand that the undeniable logic in an argument is not enough to convince someone of its validity: it’s as important and most often even more important how the argument is expressed, how it’s told and explained.

John is a very clever programmer, extremely sure of himself, who likes to drill into the details of a problem; his method is tried and true, and he wants to give something else a go by himself before incorporating in his work. He likes to picture a problem and see a solution. I approach John and explain him that according to several studies writing Unit Testing  makes code more reliable and reduces cost of ownership for a code base, so he can focus on the general problem rather than fixing small bugs; doesn’t it sound correct? John thinks “bah” and moves on.
Trisha is a very clever programmer, who likes to keep herself informed by reading about how others in the Industry have solved similar problems in order to possibly produce something better for herself. She likes to think about the big picture rather than wasting time on irrelevant details. She wants to feel a problem before touching the right solution. I tell Trisha that if she tries Unit Testing for herself she will find that her code will be even more reliable, simpler and easy to change when she needs to change the details of the implementation, which is a result that she can immediately see after only few weeks. Trisha politely smiles at me thinking “bah” and moves on.
Things are not as simple as in my example, but we can immediately draw some interesting conclusions from it: in both cases what I told to John and Trisha is true and verifiable, but I failed to understand how they want information to be presented to them, which is radically different! John doesn’t care that others find Unit Testing useful, he wants to try for himself, while Trisha doesn’t want to try something if others haven’t already established it’s viable. John wants to see an argument not hear it, Trisha wants to feel it not see it.
Interestingly, addressing a group of people makes it even more difficult because different personalities are likely to be present, how about:

Writing unit tests before code is proved by different studies to be effective, which is something that you can see by yourself in just few weeks of trying it out, either on some small units or in a big problem that sounds difficult to tackle. You can easily feel the advantages or come to ask me for advice if you encounter problems.

How does it sound?
This realization makes leading a group of people even more challenging: now it’s important not only to have a solid and well thought-out vision, but also to understand the nature of the people we work with, how they want information to be presented to them, how they like to reason and respond to problems. Failing to communicate our vision is our mistake as leads.

Post also available on AltDevBlog.

No Comment

When I interview a new C++ programmer, my favourite question is not about const-correctness or virtual tables, but: "Do you comment your code?". I still ask about virtual tables, but asking about code comments always springs some interesting discussions and gives me a good insight about the level of care the aspiring programmer puts in crafting his code to not only make it correct and fast, but also to make it easy to work with. I witnessed puzzled faces wondering if that was a trick question (yes it is), and one unlucky candidate pushed his luck to a very bold "which good programmer doesn't comment his code!". Me.

More and more love to Stereo-3D in CryEngine [ITALIAN]

The interview is in italian, talking about Stereo-3D in CryEngine and my experience in the industry. The snowstorm in Frankfurt prevented me from flying to Milan, give up? No, I will have nothing of this nonsense! Skype solved the problem.

Straight from my living room… Enjoy.

VideoGamesParty.it

Also you can notice from the previous video that I’m getting slimmer and slimmer. Thanks to the guys at VideoGamesParty.it for their help.

AAA Stereo 3D in Crysis 2 – Talk at 3D In Your Face

I finally got the uncut, uncensored, untainted footage of my talk at 3D In Your Face in Bradford last month. About three hundred people (!!) were attending, it was great fun and quite scary for the first couple of minutes. Luckily the first couple of minutes are missing, but you get thrown in the mix at no cost a full five minutes of Crysis 2 in game!

Enjoy the show.

3D In Your Face - AAA Stereo in Crysis 2 from Francesco Carucci

And don’t miss the slides from the talk.

AAA Stereo 3D

 

Special thanks go to Nicolas Schulz from RnD who wrote the slides on Reprojection and implemented the actual algorithm and the Crysis 2 team for the amazing game. Big kudos go to my partner in crime, Jens Schobel (yes, I will never write your name correct, ever!) for writing the slides together and giving the same talk together in Cologne and Barcelona. I missed you man!

Comments on how to improve my l337 presenting skillz0r are greatly welcome.

No comment

while (IsStarted())
{
    // Wait until there is work to do.
    Wait();

Oh well, I guess so…

Crunch… crunch… crunch... #2

 

Old and very well known article, but it’s worth a refresh cause it seems to be overlooked:
http://archives.igda.org/articles/erobinson_crunch.php

In most times, places, and industries over the past century, managers who worked their employees this way would have been tagged as incompetent — not just because of the threat they pose to good worker relations, but also because of the risk their mismanagement poses to the company's productivity and assets. A hundred years of industrial research has proven beyond question that exhausted workers create errors that blow schedules, destroy equipment, create cost overruns, erode product quality, and threaten the bottom line. They are a danger to their projects, their managers, their employers, each other, and themselves.

NEM 2010 Barcelona – Stereo 3D Talk

I’m going to NEM 2010 in Barcelona in a couple of days to talk about our work on Stereo 3D that is going to be used in the upcoming Crysis 2.

It’s the same talk we gave at GDC Europe in Cologne but with revised slides and some new info.

That’s going to be good fun.

“Video Games Lead to Faster Decisions That Are No Less Accurate”

 

http://www.sciencedaily.com/releases/2010/09/100913121656.htm?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+sciencedaily+(ScienceDaily:+Latest+Science+News)

ScienceDaily (Sep. 13, 2010) — Cognitive scientists from the University of Rochester have discovered that playing action video games trains people to make the right decisions faster. The researchers found that video game players develop a heightened sensitivity to what is going on around them, and this benefit doesn't just make them better at playing video games, but improves a wide variety of general skills that can help with everyday activities like multitasking, driving, reading small print, keeping track of friends in a crowd, and navigating around town.

Enuf’ said. Now I can play Starcraft II for as much as I like claiming it’s for my own good.

Off Topic: Scaloppine Magiche

I’m seriously thinking about turning this blog into a cooking blog. Programming is a creative endeavor after all, isn’t it?

 

 

 

 

 

 

 

To create Scaloppine Magiche:

• get thin beef (or veil) filets
• cover the filets with flour on both sides
• heat up olive oil (olive oil!)
• when the meat is half cooked, poor red wine
• serve with roasted vegetables, and the same red wine to drink

 

Squeezing a lemon instead of pouring red wine works equally well.

Enjoy!