History of Block Games
Programming Projects -->
Block Engine -->
Originally Zach Barth (see friends links on Home Page)
had created the computer game "Infinifrag" in Python (using PyGame).
The game was simple but extremely entertaining: players on however many teams could
either shoot each other with guns or create/destroy blocks which would serve as fortresses.
This game was simple but brilliant, and soon Zach asked me if I wanted
to work on his next project "Infinifrag 2", and I was totally on board.
We were writing Infinifrag 2 it in C++ using SDL + OpenGL.
There were various technical issues that I felt needed to be solved
in order to make Infinifrag 2:
During my spare time one summer (the summer of 2007),
I worked on the first two of these problems
while Zach worked on the other aspects of the game, such as the procedural
generation of "Block Worlds" which was to be the heart of the game.
After collaborating for a semester at school, the project became overwhelming
and we stopped working on it. This was the end of
- Players needed to have momentum,
players should be modeled as ellipses,
and collisions with the world
should be detected and responded to as dictated by the usual
"translating ellipse intersects triangle" algorithm.
- Only the visible surfaces of blocks should be rendered
and rendering in general should be optimized.
- Players should be represented as 3D-character models
(instead of 2D-sprites).
At this point, I began focusing on writing my own code to
render and perform collisions detection with Quake-like BSP files
(to make a FPS game).
After having one or two difficulties with this, I decided to
resurrect the "Block Engine" code I had written for Infinifrag 2 that
performs these functions (because it worked and was good enough for a first
attempt at a FPS).
Zach requested that I change the name of the project from
Infinifrag to something else, so
I called it "Block Arena".
Although my primary concern was working on the technical parts of the engine
that any FPS would have, the block creation/destruction
mechanic was something that the system should also
be able to handle.
While I was obsessing over solving issues 1, 2, and 3,
Zach had created an entire new block game
(from some old code he had written)
called Infiniminer (in Fall 2008).
Although the technical problems 1,2, and 3 were unsolved,
the game had both the procedural world
and the block creation/destruction mechanic.
This game was ultimately responsible for creating the
"block based" game revolution, which many people incorrectly
attribute to Minecraft.
My personal opinion, which was formed after
having many conversations
with Zach at RPI about the gameplay aspects of
Infinifrag and Infinifrag 2, is that Zach is
responsible for creating this genera
and the game Minecraft has, dare I say, "ripped off" Zach.
For the record, when I was working on Zach's project Infinifrag 2,
I am 99% sure that I suggested that one possible
game idea would be to remake the flash game "Motherload"
but with blocks.
He then asked if I wanted to do that and I said sure.
Once he started thinking about the game mechanics for
infinifrag 2, however, it was clear that the game he had in
mind was much more general and mining was only one aspect of it
(there were also trees, volcanoes, etc).
What ended up happening was the scope of the project was
way to large, so he stopped working on it after half a year.
I continued working on the project, but only on very general
things that any FPS game would have
(not on any block specific stuff).
When he released Infiniminer later on
(which had a much more well-defined scope), I was surprised
because I had thought he had completely abandoned the project.
I have always been annoyed
that I was not included in the making of Infiniminer
(especially since at the time I was working on
what was left of Infinifrag 2),
but at this point it is water under the bridge.
Note that the algorithm Zach used to render blocks in Infiniminer
is different than how I did it in Infinifrag 2 and BlockArena.
I believe that Zach rendered strips of squares (that all have the same unit width)
whereas my engine computed quads that have variable width / height.
Although the latter technique in various situations results in less total quads,
many procedurally generated or hand-built block worlds are not
rendered all that much faster by this technique,
so it is not worth the headache.
Also, representing the world to be drawn as variable height and width quads
clashes with the paradigm of breaking the world
No matter what, it is neccessary to perform graphics card optimizations
to render the quads.
Hopefully we shall see a golden era of "Block Based" games!