next »

[Retro]

Day 0

Just planning out the following work month to get this prototype done. I've split the work down into circa one-day tasks so this amounts to 29 days of work. I suck at planning and usually massively underestimate the time a project will take, so I'm trying this breakdown method to get a more accurate idea. To change the trend I'm generally overestimating things, so I'm really interested to see how this turns out in practice. It'll probably even out in the end due to unforeseen problems, as it goes with experimental stuff. Still I'll try to be efficient and finish as fast as possible.

project setup

• xcode 4 ✓
• library design (xni, artificial, express) ✓
• project creation ✓

prototype level model

• terrain ✓
• blocks ✓

prototype 2D graphics renderer

• camera system ✓
• display ✓

2D physics engine

• research ✓
• convex-convex collision ✓
• compound objects ✓
• rest stabilization ✓
• friction ✓
• debugging ✓

input system

• block manipulation ✓
• camera navigation ✓

gameplay

• block fixation ✓

block shape experimentation

• brainstorming
• prototyping
• model improvement

water system

• simplified 2D model ✓
• prototype water renderer ✓
• internal water physics ✓
• water-block physics interaction ✓
  • water levels ✓
  • block destruction ✓
• streams system ✓
• prototype stream renderer ✓

physics renderer (debug purposes)

• debug renderer
• system tuning

terrain experimentation

• brainstorming
• prototyping
• model improvement

green - done
orange - postponed to production
red - not needed

I guess no devlog should start without concept art, so here goes my speedpaint.

Also, timelapse:

[zigah]

Good show!

[Retro]

Day 1

I sped through the project setup as fast as possible. I already read the transition guide to Xcode 4 some time ago so I jumped straight into setting the hierarchy of static libraries I'm using:

• XNI - Basically a port of XNA into objective-c. This provides the core features for running a game loop, rendering (via OpenGL), game component hierarchy, content loading, sound, touch input ...
• Artificial - My own general library with things I always need, but aren't present in XNI/XNA. A PrimitiveBatch for drawing graphical primitives (points, lines) to compliment XNA's SpriteBatch is the most useful thing in it so far.
• Express - My rapid prototyping library. It was developed when I was
  
  game development to undergraduate
  
  and it will now come useful for getting this prototype done as fast as possible. Currently it includes basic building blocks for scene objects, a debug renderer and a basic physics engine.

On top of this architecture I set up my game with the following overall class structure:

Today I created the main game class, Gameplay, Level and a basic terrain building block. I added the debug renderer component to finally see that everything is wired up nicely. Here is the end of day 1 with the first screenshot:

[YetiSeekingYeti]

Way to stick to things so far, I know it's super early, but you seem to have a good bit started  .

What's the gameplay going to be like in this? I'm guessing some sort of physics/tetris/tower building thing? I'm hoping it's something along these lines, mainly just because I love those sorts of games.

[Retro]

I'll leave the gameplay to unfold itself as the prototype progresses, but your guess is pretty close to home! If the concept proves to be fun I don't think you will be disappointed.

Today I'm busy working on other stuff (rollerblading my ass off too ), but I'll be back on the project tomorrow with a new update.

[Retro]

Day 2

The basic triangle block shapes have been added for a more interesting terrain. I've then thrown in some balls to test my grid scene structure. It needed some work to properly handle moving items. The red rectangles show with which shapes the collisions are being calculated with.

Also, video:



I've now moved on to building blocks, but first needed to decide how to represent the concave pieces. Now I'm extending the physics engine with a compound collision shape.

[CoreDumped]

looks great.

Any reason why you choose to create your own physics engine over an open source engine (with an mit, zlib, bsd license)?

[Retro]

A couple reasons:

• I've been teaching game development, so I needed to understand how to do a physics engine. Building your own is the best way to do so.
• Since I already had most of the basic stuff done from teaching classes I now don't have all that many things to add for the purpose of this prototype.
• Generally it gives me more headache to adapt higher level engines to suit my specific needs than if I write things myself just the way I want it.
• There was this great talk at GDC 2008 by Metanet's Raigan Burns: Unique Knobs for Indie Games (slides here). He talked how having your own engines gives the unique feel to your game and lets you think outside the box.
• Also, I like seeing balls bouncing around as the fruits of my labor. Keeping the work fun and motivating is very important and I get many bonus points from coding a physics engine feature up nicely.

This is mainly personal taste and it's what seems to work for me. Another developer at Dawn of Play uses Box2D in our other project and he's getting good results with that as well.

[Retro]

Day 3

A quick update today:

• Complex block shapes have been added, consisting of multiple convex polygons to create the final (possibly concave) block shape. This is now more or less ready for implementing convex-convex collision support in the physics engine.
• I also added a camera system for panning around the level and pinching to zoom in and out. This is a must for the iPhone if I am to test how the game will behave on the smaller screen.

The screenshot can only illustrate the new block shapes, but the video below also shows the camera system in action.

Video:

[Retro]

Day 4

Today I moved into the first bigger coding area, the 2D physics engine. I'm still a little ahead of schedule, but I'm sure I'll lose some time with unforeseen physics issues. There's a lot of things to screw up here, from linear algebra calculations to stability problems. But as for today, so far so good.

First I turned off the mock-up debug renderer and created a basic rendering of terrain and blocks. A nice gradient background helps present the shapes of building blocks better. The screenshots are much better to read now and provide a better impression of the prototype.

Then I continued onto the physics engine, which was extended with collisions between convex-shaped pieces along with some minor details like support for non-origin center of mass.

So far only monolith pieces are supported for collisions, which makes the next logical step to extend the calculations to compound objects (those seen in first screenshot).

[davidp]

Looking sweet so far, keep up the good work

Video showing last screenshot in action would be nice.

[ANtY]

Looking sweet so far, keep up the good work

Video showing last screenshot in action would be nice.

True that,
btw nice progress

[Retro]

Day 5

A video you say? How about this:




Today I've moved to collisions between compound objects. The screenshot shows debug outlines with proper center of mass positioned on both the components (small circles) and the resulting compounds (circle with cross).

The results are not stable yet due to multiple reasons and current work is focused in this area on contact points. I've been doing research in this area, reading a lot of forum threads and papers to get the basic idea. I've started implementing a naive solution, but the results will have to wait for next time.

I've also added two new tasks that I've overlooked in planning. First is friction support under the physics engine and second is block fixation under gameplay, which will transform free (movable) blocks into fixed (unmovable) part of the structure.

[Retro]

Day 6

AKA The Boring Technical Update

I spent the day reading more articles on contact points and how physics engines handle stable stacking ... Only to find out it's not really as easy to plug into my current architecture. I've now spent most planned physics engine time and the results are good enough to move on, even though not perfect.

It became apparent that there is no "juice" to squeeze out of a custom collision engine for this game. All I need is very stable what-you-would-expect solution. If the prototype is to be turned into a full game that will probably justify using Box2D for production quality code. However, as this prototype goes the physics engine behaves nicely enough to communicate the idea.

Stacking multiple blocks turns into a vibrating mess, but that kind of stability was not a requirement in the first place. I need only 1-3 active pieces at most. As soon as you will align the block into position it will turn into a static part of the level, similar to the blocks that make the terrain. That is the next task of development.

I employed a few easy to code alternatives to improve stability and substitute the need for proper friction. Mainly this is done by introducing dumping into the system, as well as lowering the coefficient of restitution and moment of inertia of blocks. I'm leaving the debugging part of physics engine still open as I'm sure to hit some problems once I start sliding blocks around the level.

On to more fun days ...

[Retro]

Day 7

I reached the first milestone of the prototype as I made the first step from a tech demo to an actual game. This is dangerous area because now I can start playing and sometimes 15 minutes pass before I notice I should be moving on with the coding.

I implemented the first gameplay rules that allow you to drag the blocks around and fix them into place. New pieces fall from both sides and through time you can build quite a structure. The physics is still kinda funky, but serves to show the idea of the main gameplay mechanic.

Video:

[RCIX]

That XNI thing looks cool, but.... Where do i download it?
Edit: nvm, found it. The question now is since there's no [english] linking instructions, how do i link it...

[Retro]

Thanks for the interest RCIX. Unfortunately I haven't had the time to translate the linking instructions yet so I'm afraid it's still not really usable for general public. Also with Xcode 4 things have changed a bit and the guide needs to be updated for that as well. How badly did you want to use it? Since I work on the framework on my own time and budget, how much effort I put into the project (beyond what I need for my own games) is pretty much motivation based. With all the projects I have going, whichever catches the most interest is what I'm usually also interested myself to invest my free time in.

[RCIX]

Well, I come from basically pure XNA dev for games, so it would be really nice to start out with something familiar in terms of libraries. I'll know more once I scout out other potential frameworks, but this one looks interesting in any case

[Retro]

Cool, I'll keep you in mind. I can't promise anything and I'm busy this weekend with a web design project, but next week I'm returning to game development and once I get back to using XNI I'll try to steal a moment to write a guide on how to set up a project. Do remind me if I don't get it done in a while though.

[Retro]

Day 8

I don't know what god created on day 8, but I was busy adding in water. Now the game's theme is becoming more obvious.

The first part of the day I spent creating the rising block of water behind the dam. This is done by a flow of water coming into the level and then each block is checked if it also allows water to flow out. The difference of the two flows then accounts for the water level rising.

I spent the second half of the day on visualizing the outbound streams of water calculated in the previous step with a simple particle system. As I imagined this creates a very pleasing effect to look at.

Video:



The final steps are coming together much faster than anticipated, which works out perfect, since I'm going to be busy with exams in June. I thought the water system will need to be much more complex, but it turned out the simplest solution was already adequate for this prototype and I was able to finish it all in a day. Now all there is left is to implement the cracks in the dam, which will destroy the blocks if you leave any holes in your design.