Monthly Archives: June 2009

If Ideas Are Worthless, Then Prototypes Are More Worthless (If That’s Even a Word)

I’ve expressed my interest to board games, and they have helped me to appreciate the value of ideas. Prototyping and rapid game development is really good step away from plans and concepts. I really like the idea of prototyping ideas.

With that being said, I hardly think that ideas are worthless. On the contrary. Some ideas can be really valuable. For example, the Thee Hundred project (that lists all sort of funky ideas) is filled with all sort of ideas. True, alone the value of those ideas and mechanics might be close to zero but the fact that this guy has openly shared the ideas makes them much more valuable. The ideas can become inspiration to people. Some people might borrow these ideas and use in their own games, thus adding the value. These ideas are not worthless, even though there’s no direct execution.

Similarly, in board games. There’s tons of ideas and mechanics available. The ideas that board game designers get can be very valuable: the next dramatic change can open doors to new forms of playing. Cooperative gaming looks like to be one really interesting mechanism (although nobody notices that it’s been here forever: solitaire, which is always played so that one player controls the cards and the four guys behind his back act as advisors…). When people get new ideas about how the mechanism can work, and share the ideas, the ideas themselves become valuable.

The ideas can help developers to get more done, and explore new things.

Of course totally alone – ideas that sit in some corner without use – are close to worthless. But, similar thing can be said about prototypes. Sure, prototyping is a great aid in almost any project work (whether it be board game or video game projects or anything), but prototyping in computer programming can be expensive. Board games are easy to prototype with just using pretty much anything you have at hand. Video games are harder to prototype: sure, many turn based can be somewhat prototyped with pen & paper for example, but real time video games might often require some sort of programming (or experiments from other games).

So, while ideas might be worthless… prototypes actually can be less valuable (or more expensive to say it differently). Time spent doing a “idea prototype” in your head can be very little (especially when you use the hours when you sleep…) but putting programming hours into rendering some sort of mock-up view means spending time. And spending time is expensive.

If prototype is useless, then you’ve just wasted quite a bit of time (and money). If idea is useless, you can brainstorm to get 9 more for the price of one prototype (just random number).

Bottom line is…

I think that the next guy who (1) wants to make a new fantasy MMO, (2) and haven’t done any games before, but (3) just needs 20 people to join his team could use a wake up call from the world of prototypes: putting together an online pong could give him bit of idea what he is going to face.

On the other hand, developers who think that (1) ideas are worthless and (2) prototypes rocks, could consider the fact that a hybrid model could work better: first get 20 ideas, then prototype 5 without a computer, and then make a mockup proto from 1. Repeat five times and you’ll eventually find a winner.

Petri Purho from Kloonigames mentions that “90% of prototypes are crap” (his 10th prototype was Crayon Physics by the way).

Instead of prototyping in computer, I think it’s first good to think of ways to prototype without programming anything new.

Your thoughts?

Two Really Good Links (With Loads of Game Design Material)

Killing Bugs Is Rewarding

5 Replies

I mean bugs in code, not in real life (I’m such a wimp that I hardly ever kill bugs, but rather move them away from our apartment).

Anyway, I mentioned that I finally managed to isolate and fix the nasty bug I had in my game. To me this was amazingly rewarding. I’m really glad you guys helped me out and suggested ways to do things (thanks for that), and I’m especially glad that I finally managed to locate the problem.

It was a huge reward, and got me thinking about game design…

… In some games, you want to give small rewards to the player as soon as he does something right. I think that’s fine, but I must say that I’m proportionally happier now than I was when I added the first perks in the game. I felt good about adding a perk system, but now when I got that really nasty bug squashed, I was thrilled.

Small tasks bring small rewards, big nasty challenges bring big rewards.

Of course the (game design) problem here is: how do we ensure that the big nasty challenge isn’t too big challenge – something that stops us from trying.

Interesting Pricing Model (“Sell Development Version”)

3 Replies

I see in one thread about different indie games, mentioning a pricing model where players could purchase development version for discounted price (that helps developers get money during the development), and get the upgrades (and the final version) for no additional cost. I think that’s pretty interesting idea for pricing, but of course comes with some questions:

What can you promise? If you promise to provide more than you eventually will, do the customers get money back – or were the customers just buying the development version? How do you communicate this to customers (and ensure that people don’t assume that all new fancy ideas will get into the game)?
How you keep people interested? Providing a proper schedule where you add new stuff frequently (every week? month? 6 months?) can help this, but how do you ensure that people will keep playing the game?
How do deal with the customer support? Handling a community, sales, support, ideas and everything takes time. How players will be able to influence the development? What communication methods you will use? How much time are you willing to spend into this?
How low can you afford to go? A rule of thumb is that discounts are good for bringing traffic in campaigns, and good for volume purchases, but keeping low prices might not be as good for revenues as having higher prices. It can work, but this type of thing could be considered. (Yes, I’m opening the can of worms here).
How do you know when the game is “ready enough” to be sold? (Answer is: you really don’t before you put it online…)
What if you change the game so that some new feature makes people irritated? If they bought the game for specific feature X, and now you introduce not so fun feature Y (not so fun for some player), can the customer ask for a refund since he was thinking that the feature X wouldn’t be touched?

All these questions can be answered (and have been by some indies for example), and I’m also dealing with some of these in my own zombie game’s development – so certainly this was an interesting approach into selling the game. There are potential problems, but it sure is a nice way to fund the game right from the beginning.

Opera Unite – “Platform” For Games?

7 Replies

Opera Unite (“a Web server on the Web browser”) looks really, really interesting concept. These guys are making it easy to share stuff between platforms, and I of course immediately thought “how to make games with this?”

I checked the system, and there might be possibilities for all sort of multiplayer games for example. If they can share files and stuff easily, then what would stop creating some sort of fancy games for this platform (they actually also mention “games” as one possibility for doing things).

Here’s one pretty descriptive article about this system: Developer Primer.

So, anyone gonna try this out? (If so, what kind of game you think you could do with this. Perhaps some sort of collaborative RPG or turn based games at least)

Update:
Ian gave a good insight why Opera Unite is NOT for gaming (thanks Ian):

Nope, definitely not; and here’s why in a (long, detailed) nutshell http://factoryjoe.com/blog/2009/06/16/thoughts-on-opera-unite/

Read, especially, the section covering the EULA for Unite, it’s highlighted in yellow so you can skim down to if if you’re impatient.

Oh, and hope you have a great time on your midsummer trip!

You can check out the link on your own, but what I got out from it was that basically Opera guys are taking anti-spam approach on this (which is kind of good for people), but by doing this it also makes it little tough place to start doing games if Opera gets to control over things. Reading EULAs is sometimes problematic, and things change… so I wouldn’t draw too many conclusions out of this yet. Read the article and use your own brain.

We’ll see how it goes.

Out-of-town For Some Days

Mr. Bug Hunter

12 Replies

Some days ago I posted some rant(ish) comments about differences between the debug and the release version behavior. Today I’ve managed to find the bug, so thanks you guys for your help.

Programmer Tip: a crash course into “how to debug” can be found from the comments of that blog post.

In retrospect, I think it’s pretty hard to know if this was “my code problem” or “Leadwerks engine problem”. It sort of lies in between. I could argue that the difference between debug mode and release mode was caused by Leadwerks, but in the same time I kind of feel that if I had used a better coding structure, I would have never experienced the problem. I just let you decide whose the blame.

Anyway, here’s the problem and the solution. I try to explain this in a non-techy way right after the code parts, so check this out:

(This was my original code, it worked only in debug mode)

function drawhovertext(entity:tentity)
   if (entity = null)
       return
   endif
   physicalObject = TPhysicalObject(GetEntityUserData(entity))
   drawtext(physicalobject.hovertext)
end function

function update(...)
... do stuff
   entity = campick.entity

   updateappspeed
   updateworld
   renderworld

   drawhovertext(entity)
end function

And here’s the code that works (I’ll explain the difference below).

function sethovertext(entity:tentity)
   physicalObject= TPhysicalObject(GetEntityUserData(entity))
   self.hovertext = physicalobject.hovertext
end function

function drawhovertext(entity:tentity)
   drawtext(self.hovertext)
end function

function update(...)
... do stuff
   entity = campick.entity
   sethovertext(entity)

   updateappspeed
   updateworld
   renderworld

   drawhovertext()
end function

So, basically all you programmer geeks can perhaps read what’s going on but I still want to explain what was happening.

I was basically doing messing with an “entity”, then running “update world (and collisions)”, and then “drawing text on screen using the entity”. This didn’t work.
I changed things that I first “messed with the entity, prepared the hover text”, then run “update world (and collisions)” and after that “draw text on screen using a prepared variable”. This worked.
Also notice that entity was usable all the time – I wasn’t trying to use a “null” entity. It was only a collision of physics controllers (of all characters) that weren’t working.

The entity was no longer used after “collision check”, and basically I could have prevented this by simply “preparing things for render” before doing collision checks, renders and other things – and then simply draw the textual parts (in a “dummy way”) to the screen.

I’m glad that the problem was sorted out (but whose fault was it…?)

Loading ...

The Most Awesomest Game Related Business Idea

6 Replies

Yeh, that title was intentionally written like that. Today I saw this: somebody selling mana potions online.

Somebody has taken 2 very simple things: (1) something existing in the market (energy drinks) and (2) something familiar from video games (mana potions), and combined these two.

I think that’s just brilliant creativity.

Anyone gonna buy & try?

(I have no clue if they are suitable to drink so use your own brain for that, but at least the concept is just great.)

Indies Aren’t Solos

14 Replies

Come to think of it, there’s most likely not a single “solo” programmer in the world. Even the ones locked in dark cabins have are connected to zillion of other developers. We have Twitter. We have email accounts. We have blogs. We have forums. And we have loads of more ways to connect and ask help from each other.

Even if we “work alone” we aren’t developing things solo. There’s loads of people helping us when we just ask. (see for example here – I was pretty amazed to see so many helpful replies).

Pretty amazing.

The Cost of Things

2 Replies

Is your team tracking what stuff really costs? Here’s some things to ponder:

When I shop at grocery store (we go there bit over once per week), I multiply the price with 50. For example, if soda costs like 2 euros, I multiply it by 50, so that I know that it really costs me 100 eur (per year). After that, I think if I really need that soda (answer is yes: I get 2 bottles)
In team meetings – let’s say 5 guys having 2 hour meeting – things can become pretty expensive. If it costs like $50 per hour (just random number), then having 5 guys in 2 hour meeting costs $500 bucks. Before having a meeting instead of thinking “we should have a meeting” you could ask “is this meeting worth $500 bucks?”
When thinking about features, multiply the weekly salaries, and you can easily come with number like for example $20,000 (for some teams, again just one random number I picked from the hat). Now, when you think about adding features (and hear that it takes one week of your team’s time – $20,000 cost) you might want to ask “do we really want to do this”?
And numbers get bigger and bigger when going in larger scale projections.

I don’t want you to get paranoid about anything and freeze (do nothing because everything costs). I just want to point out that sometimes it might be a good idea to think about where the time & money goes.

game producer blog

I bake games. Indie style.