First horde tests

Spent day for implementing steering behaviors for horde.

Recast navigation + avoid nearest neighbor (with prediction, OpenSteer style) + avoid near walls



Recast navigation + avoid nearest neighbor (with prediction, OpenSteer style) + avoid walls only after collision + avoid dynamic obstacles

It needs time to update nav mesh (usually nav mesh updated with 0.5 sec intervals), so sometimes bots can go throw obstacle. Maybe for moving obstacles I need to use same steering behavior as for another bots.

Does it look natural? Or need some enhancements?

http://forums.tigsource.com/index.php?topic=8625.0 very funny about indies

finally understand, what is Velocity Obstacle.
it's freakin simple ))

print of the source article helps a lot

it will be hordes of zombies!!!

Recast navigation + steering behavior + wall repulse force

path following force + steering behaviors + wall repulse force

red line - path from Recast
grreen line - resulting velocity
blue line - wall repulse force

Simple steering behavior

I added yesterday simple steering behavior
for bots. Movement became more realistic than
previous direct path following. Now bot has
velocity and acceleration, and it tries to move
along current path line.



Remaining task - dealing with walls (current bot position now
not exactly on the safe path), moving obstacles.

simple optimization

If you have vector assignment in your code,
use Swap member function of std::vector, if
you will not need source vector anymore

it will save you one memory allocation

void SetPath_Dirty(vec3& path)
{
m_path.swap(path);
}

Lighting abilities of my engine

Deferred shading (plus Doom3-like lighting for slow hardware),
more than 1000 lights (without shadows) possible simultaneously,
soft shadow maps for omni lights, attenuation maps, fog,
bump maps, specular maps, ambient etc.

Recast dynamic navigation meshes

Some examples of using Recast dynamic navigation meshes in gameplay

Memory management

Usually C++ uses linked list to holding free memory chunks, so searching for free chunk is not fast. Especially for small objects. So I decided to optimize allocating of memory using special pool allocator. All small objects in engine have base class, which get and release memory from pool allocator. 3x times optimization for memory allocation (small objects)

Look Andrei Alexandrescu Modern C++ Design and in details here

Loading of materials

My previous demo had very long loading time (~4 min). There were many big textures there (usually 1024x1024), most of it in tga format.

To fix it, I changed format to dds, pack mips to texture and moved loading of textures to separate thread. Moreover, only near textures (~50 meters - engine parameter) are loaded and during moving, textures outside of that radius will be unloaded. Small versions of texture (64x64 usually) are used instead of full versions on a distance.

Results - 3-4 sec for loading current outdoor level (~800 000 tris), unlimited number of textures on a level, all in separate thread, important for today's multicore CPUs.

Ideas

i broke my brain in search for fresh game idea. It's not so easy, as i think.

There is one stupid idea - a atomic bombing in details. In first part you will be pilot of a bomber, after that - civilian, escaping from town. Burning people, death everywhere. Something about how bad is it. Short game especially for IGF. Kind of interactive movie...

All in real 3D, with details... maybe for IGF in 2D, as they like ))

Great article about indie game PR

http://gillen.cream.org/wordpress_html/?page_id=693

plus http://thegameprodigy.com/zero-budget-indie-marketing-guide/#more-118

Optimization

During tests, my game has average 40 fps on GeForce 9600 with Intel quad core CPU.

That version was sent to IGF.

Several days ago I found, that all shadows on level are drawn every frame. After searching in source I found commented for debugging line of code, which increase speed twice! So fps becomes ~ 80. After switching off grass and NPC sensor system (which do search for enemies 5 times per second) fps becomes 400!.

So first of all I implemented correct instancing for a grass ( and cut off all cards without support of Shader model 3). Next step - faster sensor system for nps.

Now average fps is 160 but there are a lot of ways for improvement.

Little Zombie Susie gameplay

First several minutes of gameplay

i didn't show all gameplay in the trailer, just for a mystique.
But there are many things - puzzles, based on creating ways
for your npc, mines, automatic weapons, fights with humans,
eating cows etc in the game.
I will post pictures and videos here.

New video for IGF

I hope to finish gameplay in near 2 weeks

first screen from my new game - Little Zombie Susie!

Recast navigation plus Havok physics engine

Demonstration of the Recast navigation plus Havok physics engine

Explosions and weapon for zombie

Trying to finish demo for IGF competition (1st november)...

Winner!

AAAAA! I am winner of Intel Level Up 2009!

First place in Best Game Optimized for Intel® Graphics

and second place in Best Threaded Game!

and judges was most famous game developers and designers on the planet!

http://software.intel.com/en-us/articles/levelup-judges/

Thanks, Intel!

Here is my current demo (~50 mb).

It contains one level, more graphics than gameplay. I submitted

this demo for Intel Level Up 2009 competition. Try to find

cover before night, close doors, use boxes to build barricades.

Run "best threaded" shortcut for best graphics and "Intel graphics"

for integrated hardware.

I continue work on game, have found talented artist, implement

networking

Dynamic paths in Glow engine

Here is how I implemented dynamic paths in my engine.
First of all I searched available path engines and
didn't find any acceptable. Some costs money,
some wasn't complete enough. Month ago I saw demonstation
of "Recast" library from Mikko Mononen. Library generates

correct paths from triangle soup by voxelization. I was very

impressed, so I downloaded it and added support for dynamic

objects.

Video:

I will upload tech videos from "I know your Deeds"

This one about graphics.

-

Grass, trees, deferred shading,

dynamic sky, clouds, 3 landscape materials with weight map.

Landscape modelled in Phoshop using clouds filter, altered by

hand for house placement. Grass drawn by grass density map,

one per landscape, trees places on landscape in photosop also.

There is special bitmap for foliage, if you draw, for example,

red point, there will be tree in level. Shadows by shadow mapping,

not perspective.

Today I finished game demo for Intel Level Up 2009,

it costs me 3 nights without sleep. Somethings remain

non implemented, but overall picture is good.

I will prepare big video and demo later.

here is small video about dynamic navigation meshes in

my engine

It's based on TileMesh, and fast. Building whole level (300x300) in separate thread in 5 seconds on single core PC, tile size 32. Dont look to fps, this is deferred shading plus old PC

here is how it works:

• render static mesh, memorize static mesh
• render dynamic objects, memorize objects per tile
• when object moved, add tile of old box of object to update list
• if not moved object intersects with updated tile, it will be added to updating tile
• render updated tiles with objects 6) connect tile into mesh (recast lib)

My current game project

I know your deeds challenges players to survive over the course of months and years, trapped in a city dominated by nightmarish zombies. While of course concerned with the ever-present threat these creatures represent, the player will face long-term concerns like obtaining sources of food and water, building shelter from attack, and the overall survival of the human race.
Game Mechanics:
The player begins in a village environment. A full day and night will take place over the course of 20 minutes, the proportions of which will depend on the time of year (i.e. More of that twenty minutes is day in the summer, less in the winter). During the day, the player enjoys relative safety from zombie attacks (at least outdoors), and those encountered tend to be lethargic and confused. Days are typically spent scavenging for supplies and building materials, constructing barricades and traps, and investigating scripted plot points.
Crafting
A crafting system exists in the game, in which players need to collect tools and materials to build and reinforce whatever position they've chosen as their base of operations. Stress is induced in the player as collecting these materials, building, and setting up the barricades and traps will take up more time than they have allocated in a given day, and the attacks that will occur all night wears down these defenses, requiring repairs the next day.
Sleep
Sleep also takes a major position in the game. If the player refuses to sleep, they will begin falling asleep while performing tasks, and generally perform miserably. Sleeping during the day is safer, but sacrifices critical time that could be spent building and scavenging. Sleeping at night means you may be rudely (and suddenly) awakened by a zombie chewing on your throat. Additionally, nighttime sleep is less restful, due to the loud noises going on outside. Going to sleep on a daily basis thus becomes a thing of terror, rather than relaxation.
Freeform
Unlike most survival horror games, there are very few scripted events in I know your deeds, beyond the seeding of background story information and certain key events which are linked to game timeline. The plot is developed by finding items which piece together a patchwork background story, eventually resulting in a method of destroying the zombies en masse. The player can ‘hole up' in any building they choose, and reinforce it as they can. Items and buildings are pseudo-randomly generated in a manner that makes each game unique, but also consistently playable and interesting.
Difficulty curve
As time goes on, more and more of the framework of society begins to fail (for example, initially the electrical grid may still be working, but will eventually collapse), creating an increasingly difficult environment in which to survive, and forcing the player to continually be allocating time to deal with these situations, instead of ‘base building'. Additionally, as time goes on, the zombie threat becomes continually more intense and ferocious.
End Game
The game ends when either the player can no longer handle the zombie threat and is overcome, or the player gathers the information and materials necessary to build a device which will end the zombie threat.
Author of concept - Angus McQuarrie, concept used with permission.

Engine:
The Glow engine delivers realistic environment, covers wide range of hardware (from cards without shaders to SM 3.0), uses multithreading, deffered shading, 3d sound, networking (up to 32 players), Havok physics. Full realtime day-night cycle. It has support for mobility - power indicator, messages about lo power.