Infinifrag 2

Home --> Programming Projects --> Block Engine --> Infinifrag 2
When I was at RPI I use to hang out every friday night with Zach Barth, Jon Brandvein, Frank Tobia, Keith Holman, and Rob Cooper. We watched movies, played videos games, and also programmed games.

When Zach showed us his Infinifrag 1 (2006 or 2007?) which he had been working on in private, I instantly realized it was brilliant. It was written in python, and was a multiplayer capture the flag game where players could create and destroy blocks. Here is a screenshot from the game:


I chimed in that I thought it would be awesome to make a game like the flash game "Motherload", but in the style of Infinifrag 1 (a 3D block game). At some point not too soon after he asked if I wanted to help him make the sequel Infinifrag 2 and I enthusiastically said yes. This is the story of Zach and me making Infinifrag 2.



The remaining pictures in this page are from Infinifrag 2, which Zach and myself worked on together! That was such a wonderful year in my life (I think it was from one winter to the next), and I felt like I was part of history.

Because we were using my Quad Algorithm, Zach had the idea that to speed up rendering of the mountain regions, we could have the mountains be composed of 2x2x2 cubes, this way the min size of a quad that needed to be rendered was 2x2 instead of 1x1. You can just make out these 2x2x2 cubes in the mountain region on the left.


I made the window, grass/tree, and trunk(wood) textures years ago when I made my parent's house in the game Descent 2. Oh and that texture font in the lower right hand corners of these images, I think I made that. It looks like my craftsmanship ^_^.



While mining to get resources (and getting wood from trees) and building was certainly an important part of the game, there was also an action element. We imagined having two teams, where players collect resources for their teams, and somehow the two teams could combat each other with guns. At the time all of us were playing Team Fortress 2 alot. We imagined that when a player was killed, left behind would be a "frag box" which was another kind of resource. Zach also wanted to have character classes.


We bit off more than we could chew, to say the least. I for example was fixated on this idea that instead of rendering particles for blood, I could instead implement the marching tetrahedra algorithm to render volumes of blood. Obviously I should have been thinking about the bigger picture.



One very odd thing about Infinifrag 2 was that the world was NOT broken into chunks. I was against this for some reason (which did not make sense). Having a chunkless system made view frustrum culling inefficient. Also, the world was very finite: the server would load in a map file storing the blocks of the world (in the format of a list of boxes of blocks of the same type) and then clients could join the server and interact with the world, creating and destroying blocks.

Indeed there was no procedural world generation whatsoever in either the client or the server. Instead, Zach wrote a program (perhaps in python, I don't know) to procedurally generate a map file. This would be run ahead of time.


I did not get my hands dirty with procedural world generation in Infinifrag 2, nor did I do any of it in my game Block Arena.

But in Fractal Block World I wrote over 70,000 lines of C++ procedural world generation which now feels like a badge of honor. Never again will I choose to write this kind of procedural world generation in C++. But I think that there is a future in procedural world generation being specified by Lua files, which is where I would like to see the future of Fractal Block World.



Although I do not have a screenshot of it, at one point the style of procedural world generation was to break the world into chunks (16x16x256 or something) where each chunk had a type, be it "forest" or "mountain" or "swamp" or whatever. Adjacent chunks were likely to have the same type, because the type assigned to each chunk was computed in some preprocessing step, but I am not sure how Zach did that step.




Here I am displaying what quads are being rendered by randomly coloring them. I turned off the Quad Algorithm so that each individual 1x1 square is rendered. I was doing a framerate test.





Here I turned on my Quad Algorithm and I am showing the M by N quads that are being rendered.




Here I am drunk with power, thinking that I can use my Quad Algorithm to take over the world:

Some of my responsibilities for Infinifrag 2 were collision detection and physics (we were not using a library for that). I also wanted to use Quake 2 MD2 character model files, but Zach warned me about it taking too much time. Zach was happy to use sprites, and that is what he did in Infiniminer. I ended up getting those MD2 models working OK in Block Arena. There are a handful of good MD2 models, like Sailor Venus, Sailor Jupiter, and a fairy.



After about a year of working on Infinifrag 2 together Zach told me that he could not work on it any more because the scope of the project was too large. He said I could keep working on it. And so I did, but I gave it a first person shooter twist (Block Arena). But Infinifrag 2 never got released, and that's a shame.

I felt a bit bummed when Zach released Infiniminer shortly afterwards, because I would have loved to help with the project, and I thought that that was what I was doing with Infinifrag 2.

It bugs me that when people think of Infiniminer they don't see me in the picture.

But then again I bet it bugs Zach that so many people think about Minecraft and they have never even heard of Infiniminer.

But this hasn't stopped me from working on block based games since the very beginning. And I think there are quite a few things in the block based genera that we haven't seen yet.