Re: .kkrieger [FPS]

Posted by: gaspalorz

« on: 21. April 2011, 14:01:03 »

• Insert Quote

These were just examples what could be changed; you are right that unsupervised "just randomizing" of everything would lead to a bunch of unrelated crap, lowering the quality factor instead of increasing it. I only wanted to hint that emergence (achieved in this or that way) may lead to more or less expected outcomes and if they fit within project's design, they add to the replay-ability. Perhaps not in a FPS, but consider following example, regarding the screenshot above: I want a mechanized arachnid enemy, with a 3-fold symmetry chassis, that jumps instead of walking, can stick to vertical surfaces, and shoots SLOW MISSILES and FAST RAYS from a transparent crystal ball located at its top; it should be generally fragile, move fast and attack only in swarms - its agro factor should be directly related to the number of nearby species -> you get an actor similar to that thing (with different AI). Repeat for different objects and different properties, and you get a somewhat immersive virtual reality. Having a formal language to define the world ensures you won't get something totally out-of-place. I don't want to argue if this may be actually realized in a game, it's just interesting from my job's POV.

Posted by: Kolya

« on: 20. April 2011, 19:46:40 »

• Insert Quote

Yeah, but first person view games are about the quality of the experiences, not the quantity. If you add randomness to the mix you can quickly throw a lot more experiences at the player - and most will be crap.
Randomness is no magical key to replay-ability in this type of game. (I'd argue it isn't in roguelikes either but that the mass of possible events and enemies is the key, which can be much easier created in roguelikes than in a FPS.) Randomness can be cool when used for very specific aspects, but these can be created and tuned for quality experiences without procedural generation.

Posted by: gaspalorz

« on: 20. April 2011, 18:21:15 »

• Insert Quote

Of course it is a resource hog, but the procedural generator under the hood is pretty interesting. Imagine there is a random element tied to some formal language that provides different (but within constrains) gamewold every time you play such game = different looking and behaving actors, weapons, level architecture, lighting, objectives, etc. And yes, I am aware there are multiple examples already like ADOM, AoE, HoMM.

Posted by: Kolya

« on: 20. April 2011, 17:26:55 »

• Insert Quote

kkrieger was technically impressive but conceptually as backwards as a mullet in its emphasis of small size. Data storage and transportation are among the least of the problems a game designer is faced with today. So no one will be interested in making their life A LOT harder just to get a tiny game. That used to be important, but now it only serves as a self-set goal for the demoscene.
Also kkrieger managed its small size on cost of required computing power, which makes the tech unsuitable for small handheld devices that might actually still have less storage space and connection speed but also less computing power.

Posted by: gaspalorz

« on: 20. April 2011, 15:45:53 »

• Insert Quote

.kkrieger

A 2004 proof-of-concept first person shooter game
developed by .theprodukkt

FREEWARE

Image: http://kk.kema.at/files/gfx/full5.jpg

Download from .theprodukkt.

Remember, this is a proof-of-concept game: gameplay is limited to goofing around and shooting monsters. They've promised further releases, but it's 2011 and still nothing changed.

Because the whole game resides in a 96-kilobyte executable (!), I am quoting the readme to explain this:

We do .not. have some kind of magical data compression machine that is able to squeeze
 hundreds of megabytes of mesh/texture and sound data into 96k. We merely store the
 individual steps employed by the artists to produce their textures and meshes, in a very
 compact way. This allows us to get .much. higher data density than is achievable with
 normal data compression techniques, at some expense in artistic freedom and loading times.

Very educational. Naturally, they have also achieved this filesize by simplifying models and maps, eg. through symmetry.