.kkrieger 96kb FPS

[batmanuel]

Saw this on ./

An FPS that weighs 96kb and doesn't look all that bad.

http://theprodukkt.com/

[laters]

I just don't understand how so much can be contained in a 96 KB package. 8O

[megaman]

just tell those guys to develop farcry on a floppy! :D

[batmanuel]

I haven't tried it yet, but plan to!

[ignus]

1- its a beta so its probably like 1 room
2- they must be using some super duper compression
3- looks purty but its prolly just a trap, it'll actually d/l 46 different viruses onto your pc ;)

[laters]

1- its a beta so its probably like 1 room
2- they must be using some super duper compression
3- looks purty but its prolly just a trap, it'll actually d/l 46 different viruses onto your pc ;)
Hmm... You do make a good point about that. I scanned the heck out of it before I ran it, and while playing the game there was no in/outbound network traffic, but that still doesn't mean that it can't be a malicious program.

[batmanuel]

1- its a beta so its probably like 1 room
2- they must be using some super duper compression
3- looks purty but its prolly just a trap, it'll actually d/l 46 different viruses onto your pc ;)
Hmm... You do make a good point about that. I scanned the heck out of it before I ran it, and while playing the game there was no in/outbound network traffic, but that still doesn't mean that it can't be a malicious program.

I think I read that all the graphics are generated at run-time, so there is no need to download it all...

How did it play?

[laters]

1- its a beta so its probably like 1 room
2- they must be using some super duper compression
3- looks purty but its prolly just a trap, it'll actually d/l 46 different viruses onto your pc ;)
Hmm... You do make a good point about that. I scanned the heck out of it before I ran it, and while playing the game there was no in/outbound network traffic, but that still doesn't mean that it can't be a malicious program.

I think I read that all the graphics are generated at run-time, so there is no need to download it all...

How did it play?
Gameplay-wise, it's nothing I haven't seen before. 6 different weapons, 4-5 different enemy types, simple enemy A.I., etc. What's really amazing is the fact that the map itself is huge. It is made up with convoluted corridors and spiral staircases, as well as one big circular room with lots of structures. Also, there are tons of moving brushes including sliding/sphincter doors, rotating conduits (of some sort) on the ceilings and walls, several different (what seems to be) bump-mapped textures, and most importantly, dynamic lighting effects and shadows. The game takes about a minute and a half to load, which may be due to the amount of decompression it has to do, but once loaded, the quality of the game in terms of graphics is on par with Quake. The sound effects are pretty crappy, but given the file size, it's understandable. The game itself is nothing new, but I think the fact that it can be compressed into a 96 KB package is simply unbelievable. Why, it's only 4 times the file size of my avatar, which is also a compressed file. Something doesn't make sense...

[Dawg]

Its not a matter of decompression that causes the game to load slowly. It is that all the textures are being created procedurally. They are NOT stored staticly in the program but are created anew each time to run it. I assume the map(s) and the sound effects are similarly created upon execution.

IMO, it is a great concept for installer programs but I would want to avoid the slow startup that is occuring on each run. That is, use this procedural encoding technique with the installer to create the static library of textures (etc) that can be accessed by the game once installed. You can greatly increase the amount of textures that comes with a game by storing them as procedures. Not that any game designer would need to do this. But more MP games are coming with editors for creating new maps. Might as well include a slew of textures that were created but not used in the stock maps.

I am not sure how practical this is to do on a large scale though. I have not d/led the program so I can't comment on layout and the like. It certainly sounds impressive though.

Dawg

[CMontyBurns]

read the notes from the guys who created at /. very insighted as to why they did it and how

[batmanuel]

Its not a matter of decompression that causes the game to load slowly. It is that all the textures are being created procedurally. They are NOT stored staticly in the program but are created anew each time to run it. I assume the map(s) and the sound effects are similarly created upon execution.

IMO, it is a great concept for installer programs but I would want to avoid the slow startup that is occuring on each run.


That's what I was thinking, too... the novelty of creating the environment on the fly is pretty cool. How neat would it be if every time it generated a new "level", it was also created on the fly according to a rule set... every time you launch it ... new level to play.

Also has some neat implications for MP play.... no more long map downloads, the server just sends you <100k of procedures, you generate the map and build static files (as dawg described).

Anyway, some slick stuff. I hope this place gets this technology used in other games, it could make online gameplay better by requiring less data be downloaded or sent during games.

[ignus]

Its not a matter of decompression that causes the game to load slowly. It is that all the textures are being created procedurally. They are NOT stored staticly in the program but are created anew each time to run it. I assume the map(s) and the sound effects are similarly created upon execution.

IMO, it is a great concept for installer programs but I would want to avoid the slow startup that is occuring on each run.


That's what I was thinking, too... the novelty of creating the environment on the fly is pretty cool. How neat would it be if every time it generated a new "level", it was also created on the fly according to a rule set... every time you launch it ... new level to play.

Also has some neat implications for MP play.... no more long map downloads, the server just sends you <100k of procedures, you generate the map and build static files (as dawg described).

Anyway, some slick stuff. I hope this place gets this technology used in other games, it could make online gameplay better by requiring less data be downloaded or sent during games.

there have been dozens of 'randomly-generated on-the-fly' dungeon crawler RPGs, especially for PS2. i personally hate them cuz its a PITA to find your way around!

[megaman]

shut up ps2 boy,

ramdom generated dungeons kick arse. and from what u said, u hated evolution right?

[Dawg]

I would not expect a random dungeon to be particularly good to play or to look at. I think that the maps using the procedure generation would still be designed as a normal map and then converted to procedures. Otherwise, the colors, lighting, design and so forth would be a mess. Theorhetically, one could create an algorithm to balance colors and minimize lighting problems, but given that so many maps are created by hand with these problems, I imagine that devising the algorithms necessary is all but impossible.

I love playing on random maps for Civ II... but that is a different genre of game.

Dawg

[ignus]

shut up ps2 boy,

ramdom generated dungeons kick arse. and from what u said, u hated evolution right?

god yes i did >< i had it for DC and prolly only played it for an hour.

hated Dark Cloud 1 for PS2 even more though ><