Defining Awesome

Remember me posting about a QoS emulator made for RakNet which I used to simulate high ping? Well I lost it in a disk format and now I can’t find it anywhere on the internet. Does anybody by chance have this piece of software?

I just got signed up for the IndieWeekend over at QubeTubers.com for a live interview. If you want to listen it’ll be in 15 mins: Saturday 6th August 2011 at 4:00am EST. That should be 10:00am GMT. Meet you there.

Some requested a definition of good/bad code in the thread below.
Archont is right with “good code” : works as expected. But I have a slightly different view.
Suppose you want something expected to work on a release date (can be a major release in 6 months or just a patch in 3 days).

Good Code:
Any code that moves you closer to the release date.

Bad Code:
Any code that moves you further away from the release date.

With this we see that if you don’t set a release date you cannot measure how good or bad is your code. So your development time increases infinitely because you might spend time rewriting and “perfecting” code that already works. Of course there are some companies that say it’s done “when it’s done” (like Valve, Id, 3D Realms RIP). I believe they just don’t announce a release date. I’m sure someone disciplined like Carmack sets release dates that are kept even for himself (like setting milestones). There is a paragraph in “Master’s of Doom” where it’s noted that Carmack after releasing Quake locked himself for a week in a hotel room to experiment with some technology. Doing that sets a deadline of 7 days. After that you expect to have something awesome working. It doesn’t matter what is inside the source code or how it looks.

My favorite release date approach is a deadline of 1 day. When I start work on that day I say to myself: today I will make a physics engine or today I will make a particle engine. I work only on that during that day and usually at the end I have something working. Code made this way is usually the best code I make. If I tweak it or add stuff later it usually makes the code worse and less elegant. Doing a big chunk of code in 24 hours makes you remember the whole thing in your head. So you work the whole code in your head. The next day you will forget most parts of the code. If you return in a couple weeks there is nothing left of your understanding of the code. In 1 day it is possible to understand every bit of the code.

Try it, instead of working on every piece of the game from time to time. Just take one segment of the game and try to code it in 1 day. If you fail, erases it, and try again.

Soldat is good because it has shit code. It wouldn’t ever be good if it had good code. Why?

http://the-witness.net/news/2011/06/how-to-program-independent-games/
Presentation by creator of Braid. I could have done a similar presentation, lots of great stuff here.

Check it out at 2:20 –http://www.youtube.com/watch?v=zK0IKeAoGDU

Most comments below my last post are amazing. Thank you for them. I decided to post one little gem here from Snow:

“I mentioned Mare and Raigan. I was chatting with them once and we all came to a simple conclusion. If you are creating a game and you want to focus on fun. Sometimes it’s best to set a bunch of restrictions first. You already did this with Warmonger. You take out the pen and paper and limit yourself to just simple shapes and say you pretend like you’re designing the game for an old 8 bit console like the Atari 2600 or the NES. So you have memory constraints, graphical limitations and even audio limitations. This forces you to only focus on what is important in the game to convey what the game is about. Say it’s a game set in space. Given your extreme limitations, what would be the key elements required in the game to first make it look like a Space themed game? Second, what’s going to make it fun? Well you have your given elements: Stars, a spaceship, astronaut. Then what? A moon, aliens, weapons, etc?”

About 2 months ago I came to an important realization. Actually I don’t feel I thought of it, it sort of found me. These are game design principles. Universal and guaranteed to just work. The holy grail of game design.

This isn’t anything new and I feel no ownership over the ideas. I did though, come to my own understanding of these principles and it changed how I perceive game making.

It started because of my random interest in random stuff… read more »

Some people have found out about my secret hobby. I will announce everything very soon. I will explain what has been going on during the past month and what the hell is up with Link-Dead. There are countless reasons why I have been sitting quiet and I will explain everything in the tiniest detail. I am very surprised myself at what happened.
Stay tuned.

I finally compiled a version of Link-Dead under Linux with working graphics and sound. So this is the same as the PC version! If somebody wants this please e-mail me or ask on the forums. If you donate I will send you the link.
Next system to conquer – Mac OSX!

I’ve been working further on improving the map editor to accomodate the new bump mapping rendering. I got some initial tests working, nothing fancy, because I’ve drawn it myself. I’m waiting for a real artist to draw the tiles.

In the meantime I’ve been figuring out some changes I want to make in the next release. Here are some things that I’m pretty sure of, but discussion is of course welcome.

1. 30% smaller characters
There is something off with the scale in the current maps. The character should be actually larger I think. But I am not going to make him larger. I made him smaller for a test and it feels awesome. I don’t know why but I want it this way (maybe cause it feels more like Soldat?). This decision means all maps will have to be redone. This isn’t so bad because they would have to be redone anyway with the new shading technique.

2. Default 135 degrees FOV; out of view field painted black
FOV will stay as default. I think it is essential for good tactical combat.

3. Teammates FOV adds to yours
This option will be essential for making the FOV much better. Basically you will see what your teammates see. It will be a variation on 360 degree FOV and no FOV at all. Because if there will be lots of teammates you will practically see the entire map.

4. All weapons and items will be redesigned for the new game mode called “Intrusion”.
This is the game mode I initially designed for LD, where two teams have to attack their bases. Some of the weapon and items were made for the Huntdown gamemode. I’m not sure if cloak for example will fit in the new game mode. All of this needs careful rethinking.

That’s all for now. I hope to have some screens soon.