Anders Elfgren

Announcing CAKE - Character Animation Kickass Editor

2009-12-10T21:54:00.003+01:00

I've had in mind a while now a project unlike what I usually do. I've wanted to make an XNA library for 2d animations, suitable for for example creating animations for a stick figure type character, or indeed any 2d character.

A week ago or so, my friend Victor, who I pretty much always do my games with, suggested that we do a game for a new contest that's out there (can't remember the name or url off-hand). I suggested an idea I've had for a while: basically a game where the PC constantly runs jumps and does cool stuff from left to right on the screen while potentially fighting off baddies and stuff. The inspiration for the game is one of the last scenes in Wanted, where he's running through the factory shooting down people left and right. Good stuff. :)

So, CAKE. If you ask any of my friends what I like, you're likely to hear "Cookies". And cakes and cookes are kind of related. And the words that make up the acronym kind of makes sense. So there you go.

So yeah, I pretty much instantly started working on an editor that could produce animations for the game. I started by rigging the skeleton as a ragdoll, essentially, using the 2d XNA physics engine FarSeer, but that had some complications that were just too annoying. I didn't really want to build my own skeleton code and inverse kinematics because it seemed like a lot of work. But I started doing some math on paper and realized that it wasn't very hard at all.

So, here it is, in its current state of glory:

It is neat, isn't it?

While it can do the most important stuff, here are some of my plans:

Get it up on google code under some nice license.
Create an accompanying animation library with support for transitions, blending and more.
Wrap the current gui in a "proper" WPF application. I really don't want to try and code guis with a bunch of widgets using XNA.
Mirrored animations/rigs.
Tutorials
More datadriven.
Separate rendering code from animation code.
Use all of the above to create a cool game. :)

Wish me luck. :)

Is promoting alternative medicine evil?

2009-12-10T20:29:00.002+01:00

I've been meaning to write this blog post more or less ever since I finished my last one. It ended along the lines of "these people claim their acupuncture can cure lots of stuff - that's evil!" It felt a bit strong, I guess, and is easily misinterpreted as "alt-med practitioners are evil!", which isn't how I feel.

It's not the people who are evil. I'm sure the girl in the counter is very nice and no doubt believes in that what she's selling works.

It's more about the general notion of not using the scientific method in order to verify claims which, when it comes to medicine, actually is kind of evil, I think. It's evil because I believe that it causes people to choose treatments that aren't effective over ones that are based on science and thus potentially are effective. Note that I don't think that science based medicines are always effective for everyone, but I do believe that the chance to get a better treatment increases.

Acupuncture in Edinburgh

2009-11-24T18:43:00.000+01:00

This kind of pissed me off.

I went to Edinburgh the other day and took a stroll in the St James shopping center. I noticed a desk with banners saying something like "We can cure lots of problems", and there were examples of low sperm count, among other things. I looked a bit closer and realised that they do it using acupuncture and herbs.

I walked up to them and took a pamphlet, in which they list a whole bunch (~100) of diseases they claim they can cure. The asian girl behind the counter asked if I was interested in anything. I asked them "Do you actually claim that you can treat all of these with acupuncture?" to which she replied "Yes". I'm generally unconfrontational, so I just told her that I wanted to think about it first, and left.

Now, as far as I understand, the evidence for if acupuncture works or not is unclear at best. If there is anything it can help with, it's back or neck pain, but I don't think there's any conclusive evidence for that even. And I mean help with, as in "do more than the placebo effect". I could have called them on that, but I didn't. I don't really have anything to back it up with except from what I've heard from the SGU, or read on Science Based Medicine. Unlike homeopathy, which is just ludicrous, it's not hard to imagine how acupuncture would actually work, "scientifically".

What I don't like is that I am sure that they haven't looked into the science at all before thinking it is ok to tell people that "Hey, I've got the cure for you!". That's dangerous, stupid, and just a little bit evil, I think.

My impressions of NEoN

2009-11-23T23:42:00.002+01:00

NEoN, in case you don't know, stands for North East of North, and is what I think they call a "Digital Arts Conference". Basically, it's the closest thing I've been to to a games conference. Perhaps excluding SGA evenings, if they count. (I don't think they do. But they're fun. :) ).

This year was the first time NEoN was arranged so there were some problems, but on the whole I'd say it was pretty cool. Ok, lets go through it.

The bad (not necessarily superbad, just bad enough to warrant a note)

The audio was kind of crappy. Sometimes, one of the loudspeakers would give off a buzzing sound when the talker was talking. Extremely annoying. When Bad Luckey was interviewed, it was almost as if he didn't have a mike. It's not that he talked quietly (which he did, and that's ok), it's that they could've cranked the volume up a bit.
I got interviewed on Saturday morning about what I thought so far but either I sucked, or they forgot about it, or they haven't had time to upload it yet, or something else entirely, but the interview is nowhere to be found. Give me my minutes of internet fame!
The food. It was ok, but nothing more. Ok, the bacon and egg sandwich on Saturday morning were really good. But then, they had bacon.

The Friday talks (in order)

Realtime worlds. Shame David Jones couldn't do the talk, but Colin and EJ handled it really good. Saw some things I hadn't seen before. I enjoyed it because it gave me kind of the same feeling I had from working at Avalanche: "I work for a cool company, on a cool project - awesome" :)
Paolo Barone on Microsofts up-and-coming techs. Cool stuff, though admittedly I've seen most of it before.
The Bad Luckey interview. While the questions were good, and the interviewer also good, Bad was quite unenthusiastic and unfortunately not that good of an interviewee. Maybe he was just tired or something.
Al Mooney, showing off Adobe tech. If it weren't for the fact that it was a good and funny talk ("PEARLS" was a gem!), I would've almost been pissed off because it was nothing but a sales pitch for Adobe's new products.
Eaon Pritchard's (workshop) talk about ads and marketing using new/social media. Started off a bit slow, but I really enjoyed it. He said some things really worth remembering.
Mark Daniels, New Media Scotland... I'm not sure I remember this one actually. Sorry!

The Saturday talks

Alice Taylor talked about how she's bringing BBC TV education to the internet and being quite successful at it. I really enjoyed this talk - it was great. :) I especially liked when she said, and I'm quoting from memory, so, uh, don't quote me, "Forty percent of kids in the UK today are atheists - which is amazing!" and something about "teaching kids about nonsense such as astrology". My skeptic heart got all warm and fuzzy! I didn't know they were responsibly for the Science of Scams web site, which is pretty cool since that means it's government funded and stuff - I guess?
Dr. Joe Halliwell.. uh... don't remember, sorry!
Simon Parsons. For some reason I don't think I liked this talk. It might just've been that I wasn't listening to what he was actually listening due to hunger/tiredness. But I just got the feeling that I didn't really agree with what he was saying.
Colin Anderson, Denki. Great talk! Funny, smart. Essentially about how ideas aren't what's important: it's the team. His "proof" was Pixar: their ideas are kind of crazy, but they still manage to do it, and do it extremely well.
Richard Scott, Axis Animation. Good talk, though it might have been better if it was more of a talk and less of showing movies they've made.
Tommy Tallarico. Best talk of the conference, I'd say. Very inspiring - he essentially got into the games business by driving to LA (or something) with nothing, being homeless and sleeping on the beach until he stumbled upon a job because he happened to be wearing a games t-shirt. His talk was straight from the heart, with no slides or anything. Also, he said religion is a bunch of bullocks. Thumbs up!

I wasn't entirely sure after Friday that I thought it was worth it (£115 I think), but the talks on Saturday were really good and I'm pretty sure I'll go next year if I have the chance.

Why I don't believe in creationism, homeopathy and astrology

2009-11-23T21:44:00.000+01:00

I've noticed that, when reading articles, columns, blog posts, or watching debates or clips about, for, or against creationism (aka ID), I could see why people would believe it.

From my point of view, it is obvious that the earth is five billion years old - or whatever - and that believing that it is only 6000 years old seems stupid and ignorant. Every evidence I have heard of points to this fact. Geology and astronomy point quite a big finger at it.

I have of course heard 'evidence' for it being six thousand years old; the Noahs flood being the cause of the Grand Canyon, for example. When it comes to dissing evolution (which is intimately related, even though it kinda shouldn't be), I (and many with me) have probably seen 'em all.

But for some reason I tend to think that creationist arguments are crappy arguments. The same goes for other 'theories', such as astrology. Or medical claims such as homeopathy. Why do one group of people think one thing, and another think a completely different, mutually exclusive thing?

One side, at least one side, has to be wrong. And it is not even the case that one side is sure enough that they call it a fact, and the other side are just kinda sure but still sitting on the edge, waiting for the evidence. (Obviously, those exist as well, but ignore them for now). No, both sides not only think, but know that they are right.

How can anyone be so sure about anything, when a HUGE group of people are sure about the opposite?

I guess that's where skepticism comes in. As a skeptic, one tries to understand all the evidence before coming to a conclusion. Hearing and learning about logical fallacies so that you don't argue in the wrong way. (Topic for another blog post :) ). But it is not about throwing up your hands and saying "Beats me! Noone could know!". Its saying "Look, obviously you can not be certain about anything, but the evidence do point in that direction, so that is what I think seems like the best bet right now". Even a skeptic can be extremely certain about something, it just takes a large amount of compelling evidence for it.

Ok, so why do I think that skepticism is the way to go - and why am I skeptic of the things named in the headline, and not their opposites? (Lets ignore that there are more than one opposite to creationism for now as well).

It's not because I believe scientists to be perfect human beings that are always right. It's not because I think that science is done in a lab and that that in it self would give some credence. It's not because someone has analyzed everything mathematically and come to an undisprovable (or whatever the correct word is..) conclusion.

Here it is: Because I think the scientific method is the shit.

You're probably agreeing with me, or thinking "Wait, wasn't that all the things he just listed?". No.

I remember when I was in chemistry, or possibly biology class in high school. My teacher explained that science is based on empirical data. I didn't know what that was, but when he told me that it was about relying on statistics and tests, I felt a bit let down. "That's no way to prove something", I thought, hoping that science had more to do with logically deducing facts given certain other facts. But even though I've seen rocks fall a million times, I can't use that to prove that rocks will always fall!

I've changed my mind about that now. I've realized that testing and evaluating is the only way of finding out whether or not something is worth believing in or not. (Obviously, sometimes you don't know much but you have to make a decision and just base it on your intuition or gut reaction, but the those aren't the types of issues I'm talking about here)

Here's a crash course in the basics in the scientific method.

1. You have an idea.
2. You come up with a way to test the idea.
3. You test it.
4. If it seems to work, the idea gets a little credibility. If not, it loses some.
5. You figure out how to toughen the controls, or how to test things differently. (Basically, you make sure that the result you were looking for didn't come from something else)
6. Go to step 2.

If your idea turns out to pass a lot of tests, then it gets a lot of credibility. If it passes MANY tests, it might even become a theory.

Well, that's the gist of it - there are more things to the method (falsifiability, peer review etc.) but in principle: If you had a good idea, it will generate positive tests, otherwise not.

I don't have to believe scientists because they are scientists. I believe them because by using the above method, you will find sooner or later find solid answers. And there's no other way of doing it - that I know of. Maybe aliens have mastered another method that works for them, but I highly doubt it.

It doesn't really come down to who I believe. It comes down to who I believe actually do use the scientific method.

Tools: "Design As You Go"

2009-08-24T22:38:00.006+02:00

This is a reply to this IGDA blog entry.

The problem discussed is that time is often not given to designers of tools to prepare a proper design before a tool gets implemented - instead the developer is left on its own to try and realize what he or she thinks the tool is about, hoping that in the end, when the users get it, they'll be happy and say "Yes, this is exactly what we wanted!".

Tools teams very rarely get the full support of management, and game teams can’t be stalled waiting for tools to be completed. The unfortunate sentiment among those in power is that there’s no time for tool design. Get it done and get it done now.
The programmer has a vague idea of what to do, and without ever writing it down or validating his thoughts with the end users in any formal way, begins to implement the design from his own mind. He still thinks about it a great deal. Perhaps 75% of his time is spent thinking and only 25% is spent typing. There are probably still many unanswered questions, but as the tool begins to take shape, some answers may start to become more obvious one by one. The tool seems to practically design itself, but in reality, design is going on quite informally.

In my experience (three years of tools development at Avalanche Studios), it is VERY difficult to understand all the requirements of a tool before you start to use it, or even starting the implementation. Often while writing the core code structure for a new tool, I come up with questions such as "Wait a minute, here's a case we haven't thought of, I wonder how this should be handled". It's not necessarily about finding problems you hadn't thought of, it can also be that you realize that something can be done in a much smoother way (user interface-wise), e.g. "Hey, wouldn't it be cool if..."

The way I found myself working at Avalanche Studios (I currently work at Realtime Worlds) was to begin, of course, by talking to the designers before the tool was designed. Or in fact, be part of the initial design/requirements phase - often, as a programmer, one can see things in different ways and come up with new (and sometimes better) ideas for the design.

But to have the interaction between you (as a developer) and the designer stop there, is to fail. Whenever I made a new tool (or fixed/improved an old one), I'd be talking to the designers several times each day to discuss it, show them my progress and adjust the implementation and design thereafter. It's not uncommon to utter phrases like "After looking at the code that I'm using, I've realized I can solve it this way instead - it will work like this and that instead, and it will take me this and that much longer (sometimes shorter!) time to implement, and these are the ramifications of doing it that way".

Obviously you should always spend some time before implementing a tool to make sure that there is a thought behind it, and that you know what the requirements and design is. I do however think that the time can vary a great deal depending on the circumstances.

I also don't mean to say (if it sounds like it) that the changes to a design always originates from the coder, looking at his implementation and having an idea. Often - again, in my experience - the designer will change his or her mind after seeing the tool, realizing that it wasn't quite what he or she was after! That is, no matter how much time you spend on figuring out the requirements before you start working on the tool, you will always find something that you will want to change afterwards. Finally, since changing a tool after you've implemented it is a waste of time, doing the code-designer dance every day is the best way to reach the target with a minimum of wasted time.

The context.

2009-08-11T14:19:00.005+02:00

This post is about a concept so simple that it writing a blog post about it really seems like a waste of blogging, but I think, really isn't: The context.

Now, I'm sure that there are many names for it, but that is the one I've heard and am using.

Let me start by describing the problems that I've had during my time of writing games. I'm going to use the example of what games I've written for PyWeek looks like, because they are (by necessity :) ) quite simple in their architecture. However, the context concept can be used in a game of any scale, or written in any object oriented language. A common way to update a main loop for my games is to do something like this:


while True:
   deltatime = self.timer.getdeltatime()
   self.graphics.update( deltatime)
   self.physics.update( deltatime )

   for actor in self.actors:
      actor.update( deltatime )

   if self.stateManager.gameFinished():
      break

print "game quit"

Now, this works fine. But later in the process you realize that you have an actor (say a LaserTurret) that requires access to the graphics module, because it wants to shoot a laser, and you don't want to throw a call to glLine in your actor update loop, because it's supposed to handle game logic and not have to know that you're using OpenGL, right? The solution?

You modify the update function in your Actor classes to take an additional graphics parameter.
You make sure that your actor classes (or maybe just the Laser) gets a reference to the graphics module on creation, and then stores it for use during the update loop.
You make graphics into a Singleton, or something equivalent - like a global variable.

The first is a pain in the ass, if you have a lot of actor classes, which so far I have tended to have. The second one means that you have to modify the initialization of actors and perhaps make a special case for the LaserTurret, and you have to store the reference to graphics - probably not very expensive (memory wise), but still, if you have a thousand turrets... The third solution is just plain ugly. ;)

Also, both solutions have the problem that the next time that you want to access something from your actors, you'll have to do it all over again.

So, the real solution: Pass a context to the update functions. As I said, this is so simple that it shouldn't need mentioning, but I've worked on many games and have used all of the three solutions listed above, and I for some reason I never thought of using a context. So what is a context? Well, it's just a class that contains whatever you would like your systems and actors (or whatever you call them) to know about during their update - and even their creation/initialization.


class Context:
   def __init__(self, deltatime):
       self.dt = deltatime

#....

context = Context( self.timer.getdeltatime() )
#.....
while True:
   #.....
   for actor in self.actors:
      actor.update( context )

Now, if you want to make sure that your actors have access to graphics, simply add graphics to your context and you are done! Just that simple fact makes contexts a better solution than the three listed above.

One objection could be made that in the first and second solution, you can make sure that different game systems only have access to the things that they require access to - for instance, lets say you have a CloudSystem that is responsible for moving some clouds around on the sky, animating them depending on some various states but other than that not really interacting with anything else. You would perhaps like it to access graphics, but not physics. Well, and I'll get back to this, you can have multiple context classes!

This is especially useful if you are making a threaded game. Perhaps you don't want something mucking with the physics world while you're updating it? Well, if you had made physics into a Singleton, you wouldn't have much control over that, other than telling yourself and your teammates, and hope for the best. The same basically goes for storing a reference to it.

There are a couple of ways to solve this with a context, but to take an example, you could split your actor list into two: One that doesn't require access to physics, and one that does. Then create two context classes and pass the appropriate instances of them to the two lists. Another solution is for the actor class to get an additional function, say UpdatePhysics and pass the context with physics to only that function. Thus, contexts can be used to restrict access!

When I first heard the name context, I thought that it was a bit of a strange name; but in fact, it is a very good name, and here's how I think about it. When you pass a context to an update function, you're telling the instance that "Here! This is what you need to know about the world and the parts of it which you may examine and change. You don't need to know where it came from, and you don't need to know anything else about it either for that matter! This is your context. "

To clarify a bit more why it is a good name: It turns out that there is one more thing that makes using a context useful. You can essentially sweep the rug out from under an actor and replace it with another rug before it notices. As I hinted, the object shouldn't really know anything about the context, except for what it provides. At least this feels quite natural to me, but perhaps it is not always practical, but lets imagine that in your game the context user doesn't need to assume anything about it. You could then have, say, a ProgressSystem that shows how much of the level has been completed in a progress bar on the screen. If it's update loop simply took the context, compared the number of killed monsters versus the number of total monsters, convert it into a percentage and show it. When you change the level, you don't need to create a new ProgressSystem, you don't need to call self.progressSystem.setLevel( self.level ), you wont have to do anything except modify the context so that it refers to your new level.

Now, some of the examples I have used are a bit silly, but ignoring that I hope you've seen the light.

Firefox plugins that rox

2009-08-05T13:40:00.002+02:00

Here's the plugins for Firefox that I use - some are good, some are invaluable.

Download Statusbar
FabTabs
GooglePreview
PDF Download
Split Browser
Tree Style Tab
Undo Closed Tabs Button
URL Fixer
WOT (Web of Trust)

If there's only one plugin I could recommend, it's Tree Style Tab.

Good bye Avalanche Studios, Hello Realtime Worlds!

2009-08-02T10:52:00.005+02:00

So today is Sunday on the last week of my employment at Avalanche Studios. I started working there on the 2nd of May, 2006, and it's been awesome. Totally awesome. It was my first (non-summer) job and I learned *so* much there. Unfortunately, we had some bad luck with the economic crisis and had to do cutbacks, and when I wasn't let go when people who had worked longer than me, the union complained and here I am. I guess this is one occasion where the union made no-one happier.

Here's a list of who lost out because the union got involved:

Avalanche, because they lost me.
Me, because I lost Avalanche.
Everyone who competed for the jobs I applied to.
Sweden, cause I'm no longer generating taxes.

Here's a list of who gained:

Realtime Worlds.
The union, because they can pat themselves on the back for doing what's right. ;)

So, about Realtime Worlds - why them?

Well, here's why.
When I found out I was being let go, I sent out applications to Blizzard, Obsidian, and perhaps some more. To my utter delight (I went around the office high-fiving everyone) Blizzard got back to me and asked when I could have a phone interview with them. Well, I told them and never heard back from them. In retrospect, what I apparently should have done, is to give them specific times and not just say "anytime is fine". Didn't hear from Obsidian but I think they're having a project cancelled so no biggie there.

I went to Bioware's site and tried to apply there, but their application process was horrible (had to register via EA's job site) so I said screw them - a shame really because working at Bioware would be cool.

I also went to an interview at Starbreeze which is a little bit more close to home. :)

Around this time I got an email from Realtime Worlds telling me basically "Hey, found you on LinkedIn, are you interested in a tools job?". Well, yeah, so I sent them the CV. :) I also got in touch with Lionhead through a friend's recruiter, and thought that Lionhead would be awesome to work at - I'd heard that it was a good place from several friends. So I was excited about that and had a phone interview with them on the same day as I had a phone interview with RTW. The interviews went great and a little later Lionhead asked me to come to them for an interview in person.

I also got in contact with Codemasters through a friend who works there and went there for an interview which went really well. As did the interview with Lionhead - I had a really good time and liked the interviewers. Later that evening, I got an email from RTW asking me to come to them for an interview as well and they had booked the flights and in the process gave me a small vacation - pretty sweet. Whereas Lionhead asked me to book the plane tickets myself, RTW booked the tickets, arranged for a driver to pick me up (and drop me off) at the airport, and made it so that I went there on Tuesday, had the interview on Wednesday, and went home on Thursday. I'm not sure if it was intentional or not, but it did give me time to walk around town (Dundee, Scotland), talk to some people and generally relax and just enjoy myself. I'm not saying that Lionhead did a bad job by letting me doing the ticket ordering - just that RTW was awesome!

I had the interview, which ended with me giving a small presentation on Candy Time, of which the interviewers said something like "That might've been the best presentation I've seen on an interview" which was cool! They said they were usually pretty quick and would get back to me soon. The next day I was at the airport and decided to check my email - and they had given me a job offer!

The next day I got an offer from Lionhead as well, and a bit after that, a promise for an offer from Codemasters. I contacted Starbreeze and they then got back to me with an offer as well, so now all I had to do was pick and choose.

This is how I basically reasoned:

Lionhead: Awesome place, great game I'd be working on, liked the people. But, I was a little afraid that I was only going to code C# and that I wouldn't see much of the game engine - i.e. just making tools.
Codemasters: Has friends there, liked the people, game seemed cool, but, I hadn't heard as much good about it as Lionhead and RTW. (Note - I haven't heard bad things, but I've heard a lot good about LH and RTW). Plus, working at Lionhead just seems cooler! Sorry :)
Starbreeze: I've got a lot of friends there who wanted me to come work for it, it's closer than any of the others, and the work I'd be doing there seemed really fun! But, I felt that this is my chance to try something a little bit more exotic.
Realtime Worlds: Seemed like a really nice place, they have something like 20 different nationalities which is cool, their tools sounded very varying and interesting, their games seems really interesting, and Dundee was awesome! Oh and I liked the people there, too!

It wasn't an easy choice - though it was mainly between Lionhead and RTW. In the end, why I picked RTW was perhaps my gut feeling more than anything else - I just really liked being in Dundee.

Starting a new game project

2009-08-02T00:59:00.004+02:00

Inbetween playing Civ IV and Bionic Commando, and cleaning/tidying the hell out of my apartment, I've been thinking more and more about starting a new project. I've got various ideas in my head for what I want to do, and right now I'm settled on starting the implementation of one of my most favorite old ideas, what I call "Real" - basically a roleplaying game that emphasizes realism in the belief and hope that that will be fun (of course) by employing new tactical choices and actions that doesn't necessarily make sense in a 'traditional' RPG system.

Anyways.

The techs I'm going to use are these:

Python-Ogre, because it's the fastest way to get a 3d game up and running. Perhaps XNA can be matched in speed, but the power you get from Ogre is something you'd probably have to spend a lot of time implementing in C#.
Git, because it's the new hip thing and I wanna try it out. ;)
Pylint. Well, I'm gonna try it anyways.
Eclipse with PyDev, because I don't think there's a better Python API right now.
Windows.

It's a fricking huge project so I'll have to try and implement one feature at a time, I guess.

One of the most interesting parts about making games, in my opinion, is the "core architecture" which kind of binds all the parts together. In short, stuff like the game loop, game states and transitions, and how you make sure that the graphics module doesn't know shit about the physics engine, etc. After creating a lot of games I'm starting to get a hang of how I like to do it, but I always like trying new ways to see if I can find something that works better.

Hopefully I will feel like writing more about that soon. :)

Candy Time and a possible explanation for crashes

2009-06-14T12:49:00.003+02:00

I just read this entry on Shawn Hargreaves blog, and I think I know why Candy Time had problems with crashing every now and then.

We'd spent a lot of time optimizing it using Microsoft's CLR Profiler. We managed to get the memory allocations during gameplay down *a lot*. I think in the end, the game allocated < 500kb during one level, which isn't that bad I think.

However, we still got crashes on the Xbox when we tried to play sounds.

From the blog entry:

There were two problems:
Because the Play method did not know whether you were going to store the return value, it had to allocate a new SoundEffectInstance each time, so fire & forget sounds created garbage.
The only way we could tell the difference between fire & forget vs. create & configure usage was by noticing if the garbage collector tried to reclaim a SoundEffectInstance that was still playing. But .NET garbage collection is not deterministic! This worked ok as long as GC occurred regularly, but the better optimized your game was, the less frequently GC would run, in which case fire & forget sounds might not be reclaimed often enough, so the system would run out of voices.

So, it seems CT might have crashed because we didn't allocate enough memory...? :D It would be interesting to rebuild CT with XNA Game Studio 3.1 and see if it really would fix the problem.

Communicating with an C++ application from a web browser

2009-05-06T22:00:00.004+02:00

Ok, here's my first post with some real code tips and tricks. :)

A while back I was asked at work to make it easier for our designers to "connect" the errors in our export logs with the actual objects in our tree view in our world editor. Our first idea was to hash the internal paths of the objects (they look something like {GUID1}/{GUID2}/{GUID3} ), show that hash in the export log, and allow the designers to copy it and paste it in some dialog in the editor.

Luckily, I got a better idea before I had time to start. If you've used Spotify, or played our game The Hunter, you might have seen and clicked on links that looks like spotify:track:0IjAJpQ7gkXjgtTxqyJSfZ.

Well, I thought. Why not make our errors into clickable links that will center the camera, inside the editor, on the erroneous object?

Since I hadn't done anything like it before, I first asked a question on Stack Overflow. The answers I got weren't very specific but got me on the right track. Basically, there are two parts. Or three.

First, the app needs to register itself in the registry, like this. It took some googling to find out how to use the windows register functions, but they were pretty straightforward. By adding this to the registry, your application will launch when a link with your custom url protocol is clicked.

Secondly, the app needs to detect that it's been started from a browser. Obviously quite trivial, just check the command line for "/uri" or however you chose to customize it.

Third, you don't actually want to *start* your application - it should already be running! Instead, when you've detected that you got started from a hyperlink, you need to detect if another instance of the application is already running. After that, you need to pass the command line to it. Here's how I did it:



bool ShouldContinueStartEditor( const std::string& command_line )
{
    // Check if this instance was spawned from a web browser
    if ( command_line.find( "/uri" ) != std::string::npos )
    {
        // Try to find other instance of JustEdit
        HWND wnd = FindWindow( "AV_MainFrame", NULL );
        if ( wnd )
        {
            COPYDATASTRUCT cds;
            NEditorCopyData::SCommandLine data_to_copy;

            strncpy( data_to_copy.m_CommandLine, command_line.c_str(), sizeof(data_to_copy.m_CommandLine) - 2 );
            cds.dwData = NEditorCopyData::ECommandLine; // function identifier
            cds.cbData = sizeof( data_to_copy );  // size of data
            cds.lpData = &data_to_copy;           // data structure

            SendMessage( wnd, WM_COPYDATA, NULL, (LPARAM) (LPVOID) &cds );
        }

        return false;
    }

    return true;
}

"AV_Mainframe" is the name of the hwnd. If you happen to be using WTL, you can declare it like this.


DECLARE_FRAME_WND_CLASS("AV_MainFrame", IDR_MAINFRAME)

Now, in your window class, you need to handle the WM_COPYDATA message like this:


MESSAGE_HANDLER(WM_COPYDATA, OnCopyData);
LRESULT OnCopyData(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& /*bHandled*/);


LRESULT CMainFrame::OnCopyData(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM lParam, BOOL& /*bHandled*/)
{
 PCOPYDATASTRUCT cds = (PCOPYDATASTRUCT) lParam;
 if ( cds->dwData == NEditorCopyData::ECommandLine )
 {
  NEditorCopyData::SCommandLine* command_line = static_cast( cds->lpData );

  const char* internal_path = strstr( command_line->m_CommandLine, "/uri" );
  if ( internal_path != NULL )
  {
   // Do your thang
  }
 }

 return 0;
}

And that's pretty much all there's to it. Oh, this is what the copy data namespace looks like:


namespace NEditorCopyData
{
 enum ECopyDataMessages
 {
  ECommandLine = 0
 };

 struct SCommandLine
 {
  char m_CommandLine[512];
 };

}

Hope someone is helped by this! :D

Conclusions of blogging so far...

2009-04-21T22:37:00.002+02:00

Here's my thoughts on what I've thought about blogging since I started (like, ten days ago..)

I like writing. I used to write more when I was in school (pre-Chalmers), because, well, they make you. ;) But I always liked it. And I'm one of those who always write too long forum posts and emails. At least I used to be, but I'm getting a bit better at it I think.
Writing is good for me. Since I haven't written much except for instant messages, emails and code for a number of years, I've gotten a bit sucky at it. Seems I was much better at English in "high school" (we call it gymnasium in Sweden). This might be a good way to keep my writing skills and vocabulary up to speeed.
Writing about stuff I've given some thought to seems to make things a lot clearer for me. When I'm just throwing thoughts around in my head, it's harder to see the problems with them. This was most noticeable (for me) with my post on a dialogue system. Even before I was finished with it, I realized that the graph I'd drawn and the nodes I had in mind was lacking important stuff. So I'll probably write an update on that later on...
I doubt my blog is very interesting, so far. I mean, for an outsider. Oh well, I'm getting up to speed I guess. If blogging makes my life easier, then that'll probably be good enough for me.
So far, I've been writing stuff down off the top of my head. Perhaps the blog posts would be a better read if I thought them through a bit more first, like I'm sure Mr. Atwood does. Not sure that's how I wanna write though.

Recording the development process of a game

2009-04-21T00:00:00.001+02:00

Pretty neat! Maybe I should do this for PyWeek or the next Ludumdare.

http://www.youtube.com/watch?v=HLFC40lIRA4&fmt=22

Run away little bouncies!

2009-04-20T19:51:00.004+02:00

That's the title of the game I made for Ludumdare. The LD blogpost for it can be found here. I spent about 12 hours in total: 2 hours on Saturday, and then more or less constantly between 13 and 23 on Sunday.

Twelve hours, for one person, to make one game. Pretty cool compared to AAA-games. I'm guessing JC2 will have had somewhere between 2000 and 4000 man months (very rough estimate). Let me whip out Python:

>>> 2000 * 25 * 8 / 12
33333

This means that we put in (at least) 30'000 times as much work into JC2, than I did to RALB. Is it 30000 times better? Well, it isn't really something you can compare, is it? :)

But it does bring me to some kind of quick Post Mortem for RALB.

Cocos2d
Was it worth it, compared to going with pyglet? I was a bit skeptical at first, seing as how it is more of a framework (and less of a strict API) compared to pyglet. This is of course it's intention, it's just that I like to have control of my games' flow.

And well, to be honest I did try to use as little of it as possible. I created a GameScene which I made sure got a call to it's update function each frame using a Repeat action - the only action I ended up using. From that update, I did all the calling of stuff myself, in the order I wanted to. Except for one little thing; my input class got events at the start of the frame it seems, before my update got called. And yes, "seems" is the correct word, because stuff like that is a bit harder to verify when you're out of the loop (pun intended).

Still, I did like the scene transitions, they allowed me to take my game and create an intro scene and a gameover scene in probably just 30 minutes with some fun transition effect inbetween.

I did some animation frames for some of the objects, unfortunately I didn't have the time to implement them in the game. Too bad, it would've prettified it a bit. :)

For smaller games like this, I'd probably use cocos2d again. If I were to start a bigger Python project I might go for pyglet though. Or of course Python-Ogre, if it had to be 3d.

pymunk
My friend Victor's creation - a Python binding for Chipmunk worked pretty much right off the bat. Only caveat was that it didn't work unless you install it, but I'm guessing that'll be fixed as soon as he gets around to it.

Victor came over on Sunday to work on his game while I worked on mine, that was a lot of fun. :)

The result
Well... To sum the game up: I guess that's what you get for 12 hours of work. The main problem, I think, with it, is that the controls are pretty sucky. I thought it would be a cool blend between physics puzzle, strategy, and action. It would've probably been better with being just one of them.

I'm pretty happy anyways, it was my first Ludumdare and I got to try a new Python game library.

Ludumdare has started!

2009-04-18T12:12:00.002+02:00

Forty eight hours of stressful game creation! Theme for this time is "Advancing wall of doom", and I've got an idea. Never entered this competition before, so we'll see how it goes.

I've also never used cocos2d so that'll be interesting. I've started a little (gotta go to play other games in an hour) and so far it's... too early to tell. :) But it's not going as smoothly as one might've wished. Oh well.

Anyways, my idea is to have basically an "asteroid field" on which there are a bunch of furry balls jumping up and down in anxiety, because there's a huge wall (of something) coming their way. So the player has to steer a space ship around, picking up objects that can be used to build bridges between the asteroids, allowing the furries to escape through a portal, or something.

Current name: Run Away Little Bouncies. :)

Unbelievable regexp.

2009-04-15T22:29:00.000+02:00

Just saw this:

def is_prime(num):
return not re.match(r"^1?$|^(11+?)\1+$", "1" * num)

Wow. :D

A dialogue graph for an adventure game.

2009-04-13T12:57:00.008+02:00

Braid-author Jonathan Blow asked other game developers for examples of how a dialogue system might be stored. Now, seems to have an RPG in mind, whereas we will probably go for a "standard" adventure game, which probably makes things easier for us.

This is how I imagine we need to make ours. First, the requirements.

Each "conversation" should be a graph, not necessarily a-cyclic.
The "main" nodes is the lines which the characters will say, e.g. "Y halo thar!"
There need to be nodes for checking the value of some variable.
There need to be nodes for modifying the value of some variable.
There need to exist a sort of global database of variables.
The variables probably only need to be an integer, although it's possible that string variables could be useful (if not only for making it easier to script).
There need to be nodes for sending events to the game, to play sounds or play animations.

Now, about the database. It would probably be neat if it were hierarchical, in a way. Although it doesn't really need to be stored that way, but for scripting and having stuff like auto-completion in a script editor, it would probably be nice. Consider variables such as these:

village.hasPCentered (0-1)
village.blacksmith.stock.swords.count (0-*)
player.numberOfTimes.hasAskedPrettyPleaseWithSugarOnTop( 0-*)

In an imagined editor, these would not need to be created before-hand in some xml file or whatever. Instead, the user can simply type in the name of new ones. To the designer, they're just strings, and how they are stored in the database isn't really of interest.
That's pretty much what I imagine the editor might look like.

Green rectangular boxes are dialogue nodes. They contain a string, or possibly an id linking to a string. Whatever. It should probably also automatically connect to the appropriate talk sound to be played.
Orange, rotated squares are variable checking nodes. If the variables in D validate, then both C and E are presented as dialogue options for the player, otherwise just C is.
Blue boxes with rounded corners are variable modification nodes. Whether or not these should be the same as event sending nodes, I'm not sure. For instance, multiple conversations may influence the same variable, and if you want a piece of music to be played when the variable reaches a value, you'd either have to add the same event node to all of those conversations. Not sure what the best solution is here.

An example for the above graph might be...

A: PC says "Hello", NPC says "Hello there, want to buy a banana?"
B: PlayAnimation: "CheckWalletForMoney"
C: Nah, not really.
D: If ( player.inventory.money <>
E: Sorry, can't afford it.
F: NPC says: "Ok", PC says: Bye!"

Pretty bad and lame example, but.. Something along these should probably be enough for a classic adventure game. :) Oh, and there shouldn't be a line from B to F. Heh.

A skeptic game?

2009-04-12T12:33:00.003+02:00

I've thought about what it would be like to combine skepticism and game development, and pretty much came to the conclusion that trying to base a game play mechanic on skepticism just doesn't work. Well, it's certainly possible - I had some ideas, it's just that they sounded really boring to me.

But I've been talking to some friends recently about making a point-n-click adventure game, and when I woke up this morning I had some ideas on how to add a skeptical touch to the story. Nothing about the game is defined yet, (I first heard of the game idea this week :) ), but it seems we might go with a space adventure for a couple of reasons - but basically because in space, everything goes. :)

So what I though was... if you're a skeptic you've probably heard the phrase "Keep an open mind, but not so open that your brain falls out", which is pretty funny. :) And I thought that, maybe one of the planets you visit have a species that used to have a culture that were as nonskeptic as possible, going for all kind of pseudo science, and that the finest virtue was to keep an "open mind". Until some bad doctor one came up with a treatment to "cure" skepticism (if that's even in their vocabulary ;) ). And the treatment was something along the lines of opening up their craniums, which led to their brains falling out, and ever since, they are now holding their brains in one of their hands.

From there, they could perhaps go two routes: One being that they understand that pseudo science and superstition is bullcrap, and they turn to skepticism and live happily efter after. Or, they go the exact opposite of where they started, and start preaching close mindedness. :) Exactly how that works, I don't know. :D But I kind of like option #2 better since it's less of shoving down a moral lesson of how skepticism is the best thing in the universe, and more of letting the player think for himself.

Second idea was that perhaps, after the PC wakes up in a spaceship with amnesia and looks out the window, he/she realizes that he/she's smack in the middle of a huge starfleet moving towards a planet. The player later finds out that they're an alien species that are 100% rational - which happens to be bad in this case because they've been told through generations and generations of the True Way Of Life And How To Achieve The Afterlife, and since they *know* that it is true, they roam around the universe "telling" other planets about it. Since this is more of a bash on religion than pseudo science, it's pretty much needs to be very tactfully written. ;)

Anyways, I'm not sure if either of these are good or funny ideas, but there are a lot of fun stuff and quotes you could use from the skeptical community so it might be a good idea to at least think about. :)

Another fifteen minutes of fame as a game developer :)

2009-04-10T20:37:00.004+02:00

I was recently interviewed by the Swedish gaming site fz.se about what I think are good ways to get into the industry and becoming a game developer (this part focused on programmers). Me and three other programmers were interviewed, although separately so I didn't know what the others' responses would be. Turns out, we answered more or less the same things - unsurprisingly really. :) Before the interviews were posted, I was afraid I'd say something completely up the walls.

Anyway, I thought I should clear up a couple of things and answer a comment or two.

I agree with Petter's comment about going to a higher education teaches stuff that you might not otherwise learn yourself, for instance how a computer really works when it's actually shuffling the ones and zeroes around. Learning how to program on your own is completely doable, because you only really need to get started with a simple tutorial and then there's really nothing standing in the way for larger projects. Start with Hello world, advance to Tetris and a couple projects later, you can create puzzle games, strategy games, whatever suits your fancy. But to actually start learning about transistors, NAND gates and what-have-you takes both an additional set of interests, and (I would guess) better googling skills than "C++ tutorial". :)

Another question had to do with what you need to get discovered, and then what you need to get hired. I think it came out pretty clearly, but just to reemphasize: You need work samples - a portfolio. When I got hired, I had perhaps.. six or seven game projects on my resumé, of varying quality and complexity.

In a comment to the article, slartibastfast said that we'd all missed to say one important thing: that in order to get a job, you need balls. You can't just sit around all day working on stuff - at one point or another you just gotta apply for a frickin' job. :) I agree. When I got asked to come to an interview, I didn't hesitate for a second (which is kindof unlike me, I guess. :) ).

dofilusåkaffe said:

It'd be nice to have a job playing games all day. The ultimate job!

There are two parts to this comment. :) First is - most of us (and not just programmers) doesn't play the games we work on during work hours. Of course, if you've implemented a feature you're gonna be testing it to see that it works correctly. You'd be surprised at how little of the Just Cause 2 (which Avalanche Studios is working on) I've played. Of course, it's a big, huge f-ing game to begin with. :)
The second part is, which Angellus already explained pretty well: there is such a position in the game industry and it's called Quality Assurance. And while I'm sure they like their job (I interact with them pretty much daily), don't forget that it actually is a job. ;)

A final note: My answer to what I guessed working in the industry almost sounded like I think it's "just ok". It's not. It kicks ass. There.

The purpose of this blog.

2009-04-08T21:42:00.000+02:00

I think Jeff Vogel said it pretty well in his first blog post:

Hello. I am Jeff Vogel, and this is my blog. I have noticed, over the last few years, that many other successful Indie game writers have their own blogs. They tend to be full of interesting thoughts. I have lots of interesting thoughts too. About game design, about running a games business, about things I feel are funny, and so on. So here they are. I hope some people read them, and that this isn't a gigantic waste of time.

I don't own a game company of my own, but I work for one, and I've been making games with friends literally since I learned how to program. Sometimes I get ideas about games, game design, game programming, and other stuff regarding game development, so hopefully this will be a place for me to write stuff down. :)

I'm also a skeptic. But I'm much more of an newbie and an amateur. On the other hand, it's a very entertaining hobby that always sparks thoughts and emotions. I'll be using this blog to rant about skeptic stuff too.

Blogs with two different topics (in this case: games and skepticism) is rarely a good idea for the reader. Well, so fricking what? This is my blog. ;)