The goal of the Game Designer should not be to stage the game.
That is a goal of a theater/movie director, a choreographer or even a writer.
Game Designers should design what the player can experience and come up with game mechanics that will allow him to do that.
Let me give an example. read more »
I need to clear my mind about some things and ask my long time readers for some opinions.
You might have read the latest post on the King Arthur’s Gold blog. It’s called Adventures, Overworlds and the Full Version. If you have been following this devlog then you’ll see that there is nothing new there. I’ve talked about these ideas here and here.
Why didn’t I do that with Link-Dead?
Because I was struggling with a solid foundation. This time, with KAG, I have a solid foundation and can build upon it.
Or can I?
read more »
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.
This is a post for coders.
Here are 4 useful inline routines to decrease the size of a float by 50% (from 4 bytes to 2 bytes). I use them to pack every float in the game that doesn’t need big precision. Actually none of them do. So positions, velocities, cursor points are all packed (starting from the next version).
typedef unsigned short u16
typedef signed short s16
typedef float f32
// packs floats in the range of 0.f -> 32776.f/base;
// in this case base = 100.0f so range 0.f -> 327.76f
// when packing floats in this way you need to make sure they stay in this range
// that is the cost of packing
inline void packfloatu16( f32 x, u16 &y, f32 base = 100.0f)
{
assert( x <= 32776.f/base );
x = min( 32776.f/base, max( 0.0f, x ) );
y = x * base;
}
inline void unpackfloatu16( u16 x, f32 &y, f32 base = 100.0f)
{
y = (f32) x / base;
}
// the same routine as above for signed characters
// this is very good for packing velocities, since they rarely
// become very large
inline void packfloats16( f32 x, s16 &y, f32 base = 100.0f)
{
assert( x <= -0.5f*32776.f/base );
assert( x >= 0.5f*32776.f/base );
x = min( 0.5f*32776.f/base, max( -0.5f*32776.f/base, x ) );
y = x * base;
}
inline void unpackfloats16( s16 x, f32 &y, f32 base = 100.0f)
{
y = (f32) x / base;
}
If assert() doesn’t work on your system, replace it with ASSERT or whatever the equivalent is. You can also remove it entirely since it is only for debug.
