npruehs on LinkedIn

I’ve just finished setting up my LinkedIn profile – feel free to connect to me!

On Dictionaries and Events

This month featured two really intense coding experiences, one of which was a prototyping week that Christian Oeing and me used to start an own software project. The other one was the Daedalic Game Jam, and I want to summarize the learnings of both events in this post.

.NET Dictionary Lookup Performance

First of all, I got to learn how to work with the less obvious functions provided by generic .NET dictionaries. Consider the following code snippet that is actually taken from code that I’ve written before the prototyping week:

This code actually performs two dictionary lookups in order to retrieve a specific value: One is made by ContainsKey, while the other is part of the dictionary indexer used to retrieve the value. You can prevent this by using TryGetValue instead:

TryGetValue will try to retrieve the value from the dictionary and return null if it fails to do so. According to official .NET documentation, TryGetValue is more efficient in case you often try to access values that turn out not to be in the dictionary.

Another speed-up could be achieved by changing the way I iterated over dictionary entries. Take a look at the following code snippet:

This foreach loop iterates over all keys of the dictionary, and looks up the associated values after. However, if the whole dictionary is iterated over anyway, we can do completely without lookups:

By iterating of the key-value-pairs themselves, we can access the content of the whole dictionary without spending time on a single lookup.

Exceptions During Event Queue Processing

One week later, at the Daedalic Game Jam, I used an event system for processing user input and game events.

So far, so good. If any new events have occurred, all of them are processed by passing them to the appropriate listeners (using TryGetValue 😉 ). Additional events that occur during event processing are added to the newEvents list, preventing concurrent modification issues and maintaining the correct processing order.

However, this method might cause severe problems in one case (and did so during the game jam, actually 😉 ): If any of the event listeners throws an unhandled exception, this will cause the event processing loop to break and never recover! If ProcessEvents is called in every frame, it will fail at the exact same event every time. Even more, the same events will be processed over and over and over again, because the system never gets to clear its event queue.

Clearly, handling errors should be in the responsibility of the specific event handler in this case. However, if any co-worker of yours just forgets to do so for any tiny exception that might occur, your whole game will break and you can’t do anything to recover in that case. Thus, it might me a good idea to wrap the eventListeners(e) call with a try-catch-block, logging any exceptions the listener causes and at least go on processing the remaining events and clearing the queue.

Twitter Digest 4

Tim Schafer@TimOfLegend 10:10 PM

Panic! I can’t type a question mark without bringing up the keyboard shortcuts menu! Ahhhh! I can never ask another question!

I can only state facts! And yell! This is actually great! Because I know everything! Oh wait? Banging on the keyboard? Fixed it???

If all of life’s problems could be fixed by banging on the keyboard, life would be simpler. And noisier around the office.

Oh crap. It’s happening again! Banging on the keyboard does nothing! Nothing! Everything I learned in the last five minutes was a LIE!

I’ll miss you, question marks. Will you miss me

Markus Persson@notch 8:24 PM – 19 Jul 12

I’m so indie I forgot to push my git commits from the office.

Tim Schafer@TimOfLegend 8:53 AM – 6 Jul 12

Hey wait, before you go to sleep: I bought a dishwasher yesterday. There, now you can go to sleep.

Markus Persson@notch 8:29 PM – 19 Jun 12

I will not stand back from the doors. That’s how the robot uprising will start.

My lawyer is asking me to not encourage people to stand their ground against moving metal machinery.

John Carmack@ID_AA_Carmack 2:42 AM – 17 Jun 12

It is remarkable that I can have the correct technical book in front of me, yet find an answer faster with google than turning to the index.

Three

Past weekend three teams created three games in about three days at the first Daedalic Game Jam. I was the only programmer working on Worlds of Combo, a completely hand-drawn 2D single-player puzzle game based on Unity3D.

You can play the game in your browser right away – what are you waiting for??

Done-done

As most of us know – but tend to forget in the most crucial moments – there is a subtle difference between getting things done and getting things done-done:

“Hey, Liz!” Rebecca sticks her head into Liz’s office. “Did you finish that new feature yet?”

Liz nods. “Hold on a sec,” she says, without pausing in her typing. A flurry of keystrokes crescendos and then ends with a flourish. “Done!” She swivels around to look at Rebecca. “It only took me half a day, too.”

“Wow, that’s impressive,” says Rebecca. “We figured it would take at least a day, probably two. Can I look at it now?”

“Well, not quite,” says Liz. “I haven’t integrated the new code yet.”

“Okay,” Rebecca says. “But once you do that, I can look at it, right? I’m eager to show it to our new clients. They picked us precisely because of this feature. I’m going to install the new build on their test bed so they can play with it.”

Liz frowns. “Well, I wouldn’t show it to anybody. I haven’t tested it yet. And you can’t install it anywhere—I haven’t updated the installer or the database schema generator.”

“I don’t understand,” Rebecca says irritably. “I thought you said you were done!”

“I am,” insists Liz. “I finished coding just as you walked in. Here, I’ll show you.”

“No, no, I don’t need to see the code,” Rebecca says. “I need to be able to show this to our customers. I need it to be finished. Really finished.”

“Well, why didn’t you say so?” says Liz. “This feature is done—all coded up. It’s just not done done. Give me a few more days.”

On the one hand, we got developers telling you the feature is done while there are still some crucial steps left. The feature might still be buggy or not yet tested, or it just works in a local sandbox – but “the code is done!”

For reminding myself again and again how to really finish a feature, I created a wrap-up checklist that is available at my Grab Bag of Useful Stuff. The list summarizes all steps I adhere to after my code compiles and runs, but before it is committed to version control, such as writing unit tests and API documentation. The checklist has been mandatory at my company for a few weeks now, and it increases code quality and uniformity by a great deal.

On the other hand, some engineers tend to overdo it. Optimizing your code saving every tiny bit of CPU time and memory should never be your goal unless you’re working on very critical parts of your code base. Clearly, most of your code will never be performance-critical anyway, because it’s event-driven or even just used once at initialization. Try and focus on getting the job done, and start optimizing as soon as it’s really necessary.

Oh, and should any project manager or lead programmer ever happen to ask you how long you’ll need for the implementation of a new feature: Please tell him your guess for getting it done-done 😉