I'd like to see a project that uses GA to generate rooms for a Roguelike that present a fair and interesting challenge to the player. The genes could be the kinds of things a player encounters in a room (different kinds of monsters, traps, treasure, etc.) and each room could be evaluated on how much health the player lost in it versus the amount of wealth and experience he acquired or something. Ideally, the fitness function would be designed such that rooms that are either too hard or too easy are culled. Then each time you move down a story in the dungeon, evolve the population of rooms to present a new floor with challenges specifically targeted to that player.

It's over!! (Well, kind of. Probably not really, though.)

Thank you for your interest for Authorized Developer status for Nintendo DS.

We have completed our evaluation of your application and are unable to offer your company Authorized Developer status at the present time.

I also thought about an image generator - generating all possible 8x8 sprites with black/white. But it increasing the image size and color count made it impossible to get good images without browsing for years through an ever increasing amount of files...

Heh, yeah, this is something I wanted to write for a while, and then I did the math and realized that for the same simple case you described (8x8, 1-bit color), there's over 18 sextillion (1.8e+22) possible sprites. If you could somehow generate a billion images a second, it would still take almost 600 years to generate them all. For a typical NES sprite (16x32, 2-bit color), it explodes to 1.8e+308 possibilities. Exponential growth rates are fun!

I actually find similar challenges in writing code and composing music. I start with a basic idea in my mind of something I want to create. How a system should work, or how a piece of music should sound. Then I start building it, writing code or arranging chords and melodies. On a good day, it all just works, but sometimes things don't fit together so nicely: my interfaces aren't well-architected, or a harmony sounds dull and trite, or a matrix transformation isn't working the way I thought it should, or I can't find the right chord change to segue into the prechorus the way it sounds in my head. If the problem gets really hairy, I step through one line at a time in a debugger, or try every combination of notes until I find the right ones. And in both cases, I find that the more I practice, the more it comes naturally and I learn to anticipate and avoid the tricky problems in advance.

This reminds me of one of my favorite programming quotes, from the Mythical Man-Month:

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination.

Whether or not a piece of code can be considered art on its own, creating code certainly feels like an artistic endeavor. Which, incidentally, is almost exactly what the quote in my signature also says.

I recently moved to Midphase on a recommendation. They're affordable and the customer service was prompt and friendly even for my basic $8/mo. account.

I think you automatically "sell out" the minute game development (or any form of art, for that matter) becomes your livelihood. I also don't think that's a bad thing, which is why I put "selling out" in "air" "quotes". Whether your goal is actually to make money or just to make great games (or both, because I don't believe they have to be mutually exclusive), you still have to be able to pay the bills. It's all a matter of perspective: you're not compromising the "purity" of your project, you're making a small sacrifice on your own terms in order to continue making your project.

So it's decoupled from the program flow and doesn't block while the fade completes.

However, how to you control what happens when the fade is done, what the fade fades to?

Like I said, it's completely decoupled, but whatever was responsible for initiating the fade would probably handle that as well. A typical case would be a script to transition between levels, which would look like this in my horrendous INI file script format:

Code:

InstructionType0 = "Command"
InstructionName0 = "fadeout 2.0"

InstructionType1 = "Wait"
InstructionName1 = "2.0"

InstructionType2 = "Command"
InstructionName2 = "transition Level2"

This is where my process doesn't look so pretty anymore. It works for me, though. The "fadeout" command calls the aforementioned UIScreenFade::Fade function, the Wait command blocks the script for the given time, and the "transition" command loads the next level. Fading in would be handled by a separate on-level-load script executed automatically after the transition.

I push a fade screen onto my UI stack and initialize it with target colors and a duration. When it ticks, it updates its color value based on the delta time.

Code:

void UIScreenFade::Fade( const Vector4& StartColor, const Vector4& EndColor, float Duration )
{
m_FadeInterpolator.Reset( Interpolator< Vector4 >::EIT_Linear, StartColor, EndColor, Duration );
}

UIScreen::ETickReturn UIScreenFade::Tick( float DeltaTime, bool HasFocus )
{
ETickReturn RetVal = UIScreen::Tick( DeltaTime, HasFocus );

// HACKY: Getting widget by index
UIWidgetImage* pFadeImage = static_cast< UIWidgetImage* >( m_RenderWidgets[0] );

m_FadeInterpolator.Tick( DeltaTime );
pFadeImage->m_Color = m_FadeInterpolator.GetValue().ToColor();

return RetVal;
}

So it's decoupled from the program flow and doesn't block while the fade completes.

I'm happy because my player weapon system is mostly done. I added a weapon melee bash last night, which meant a few underlying engine changes: a get-all-entities-within-sphere function that I can't believe I hadn't needed yet, and a slight refactoring of animation events so the weapon could get a callback at the moment of impact in the animation. Then I topped weapons off with some recoil.

Now I gotta figure out how much of this I can reuse for AI weapons. I think AI weapons won't share much or any code with player weapons, but they'll both use a common ammo class (which actually does all damage dealing and line traces to determine hits and everything).

Fortunately, we have alternatives. I get the feeling that maybe we're not the target audience of the API, even though Dircet2D is a gamey sounding name.

I get the impression it's designed for people who would write their own game engines from scratch, rather than people who want a quick and easy way to get an app running; but who would actually do that for a 2D game? And anyone who would and could do that could already just implement a 2D engine with D3D, so why?

I mean, I use D3D. I don't mind the verbosity of Windows' APIs (although I also never take code verbatim from their terrible, terrible samples). I guess I'm going against the indie developer grain here, but I don't even really care about making cross-platform games, because I make games for fun, not money, and if you don't have a Windows box, that's a choice you made knowing it would limit you.

But I can't understand this. As far as I can tell, it's an API no one was asking for. It's a solution without a problem. Or perhaps it's a very misguided solution to a very misunderstood problem. In any case, I don't see there being many adopters. And it's as good a reason as any to use this little guy:

Nifty. I was fortunate to be able to pick up VS2005 Profesh at the student discount price just before I graduated, but free beats discounted any day.

Use a curvier posture to emphasize the femininity, and make the hips as wide or wider than the shoulders.



Sorry, not much of an artist myself, but working on it.

I like the last boss's little description above it's name. That was pretty funny too.

I roffled when I saw that. And I liked the way the Floormaster hand circumvented my expectations but in a totally Zelda-ish way. So much win here. Cheers Konjak!

Now I need to try playing with a chicken.

I agree, "Nothing" can be scary but a "Glimpse" can be even more horrifying.

You want to suggest just enough that the player can extrapolate from the glimpse and magnify the horror in his mind. My main problem with fear in conventionally scary games is that the player eventually has to interact with whatever he fears, and when that happens, the infinite potential space of things-wot-are-scary is collapsed into a completely known singularity and the fear is dissolved. It can be replaced by moments of panic each time the player encounters the scary, but sustaining a true sense of dread (a la Shock 2, Silent Hill 2, or the Cradle) means making the player believe there's still more horrifying things they haven't seen.

I wasn't sure Strange Visit would work in the first place, and the final product wasn't everything I'd hoped, but I'm glad to see that it did have some impact. It gives me hope for another scary game that I've been wanting to make for a long while now...

Occlusion is so dependent on your world format, I doubt most audio engines provide a completely out-of-the-box solution for it. I think both FMOD and Wwise (and probably others) do have some support for it, though; it probably just needs to be hooked into geometry information from the engine. They also both have dynamic music systems, although I haven't worked with either to comment on their usefulness.

I'm not sure exactly what you mean by vectors. It sounds like you're talking about what is usually called envelopes.

More importantly, are you interested in making an offline content generation tool or something that reacts to game parameters to modify sounds at runtime (e.g., imagine a heartbeat sound that gets louder as the player gets closer to dying)? Cool idea either way, but the latter would be especially nifty.

And unless someone beats me to it, please introduce yourself in the proper forum.

This is exactly the sort of discussion I'd like to encourage, yet I'm at a loss for words. I think the topic is just too big.

Yes, this. I started describing my game entity architecture twice (a relatively small fraction of overall code base, even) and both times, it turned into an aimless ramble. The basic design is a hierarchy of game entities derived from a base Entity class with support for nice things like serialization and fast RTTI. There's so much more to it than that, though--it's dependent on data configured in INI files, and assets (textures, meshes, sounds, etc.) are loaded through their own managers as needed by the game entities.

I agree with your assessment that it's easy to over-abstract game architecture. I've seen a lot of well-intentioned programmers try to develop a does-everything engine and never actually finish a game because of it. I'm a bit worried that I've fallen into that trap myself, but I'm finally moving from general game architecture to specific gameplay features.

I like this thread idea. Kudos.

My actual main is a bit cluttered, but effectively just calls Game::Main():

Code:

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )
{
Unused( hPrevInstance );
Unused( lpCmdLine );

// Must be initialized before creating any objects.
MemoryManager::GetDefault().Initialize( 16 * 1024 * 1024 );

Game::SGameInit GameInit;
GameInit.hInstance = hInstance;
GameInit.nCmdShow = nCmdShow;
GameInit.pCommandLine = lpCmdLine;
GameInit.Icon = IDI_ICON1;

Game* pGame = new Game;
pGame->Main( GameInit );
SafeDelete( pGame );

#if BUILD_DEV
Profiler::GetInstance()->Dump( FileStream( "profiler.txt", FileStream::EFM_Write ) );
Profiler::DeleteInstance();
#endif

if( MemoryManager::IsEnabled() )
{
#if BUILD_DEBUG
MemoryManager::GetDefault().Report( FileStream( "memory_exit_report.txt", FileStream::EFM_Write ) );
#endif
DEBUGASSERT( MemoryManager::GetDefault().CheckForLeaks() );
MemoryManager::GetDefault().ShutDown();
}

DEBUGASSERT( _CrtCheckMemory() );
DEBUGASSERT( !_CrtDumpMemoryLeaks() );

return 0;
}

Game::Main is much cleaner:

Code:

void Game::Main( const SGameInit& GameInit )
{
if( Initialize( GameInit ) )
{
PRINTF( "Game has started.\n" );

while( Tick() );

DumpUserConfig( FileStream( "Config/user.cfg", FileStream::EFM_Write ) );
DumpProfileConfig( FileStream( m_ProfileManager->GetConfigFile().CStr(), FileStream::EFM_Write ) );
}
ShutDown();
}

NSIS does everything I need (althought that's a pretty small list, honestly). And it's also easy to use.

After reading the discussion in the RAR thread, I've decided that I'll be supplying a simple archive version of any future releases I do instead of only making an installer. Somehow, even though I much prefer archives to installs, it never occurred to me to actually support that.