Here is the new Nordenfelt dev log. This week I was occupied in level asset creation and made decisions on sprite scale and tile usage.

Sorted Saving Order

The editor did not sort the sprites in background layers while saving. Therefore hitting the SAVE button twice for the same level produced different files. This was fixed to avoid Subversion telling me that a level has changed just due to reordered sprites.

Stamp Design for Level 1

As mentioned here I start most of my design work with stamp-sized sketches.

This will become level 1:

Click to see the full sketch!

Scale Factor

The top-down view includes decisions regarding perspective: How far away is the ground? What’s the sprite scaling factor? A high factor results in more details on the floor and turrets, tanks and boats would become very small. I want less detail work and big enemies.

So: the closer the better.

Tiles or Segments?

Nordenfelt’s engine allows using tiles as well as sprites at arbitrary positions. My first intention was to use tiles for saving RAM, harddisk space and artistic effort. What I did not know was that tiles are quite hard to draw when they should not look boring or gridy. Artistic freedom is less restricted with level segments. They are like tiles but spanning over the whole play field width. Segments are easier to draw, don’t need seamless edges and move the level building work over to Blender. This tool became second nature to me so I’m happy to work with it most of the time now.

Level Segment Prototyping

According to this article I made quick-and-dirty asset prototypes and threw them together in Blender. This is a first draft of a farm level segment:

The farm houses don’t have colors, the trees have all the same color and there is a chocolate river instead of a street. That’s prototyping!

If you like this dev log series you may want to stay tuned by subscribing to Nordenfelt’s RSS feed or following me on Twitter at @black_golem.

See you next Wednesday.

Cheers,
Thomas

This Wednesday I have just two points: a new enemy model and a really nasty bug.

New Cannon Boat

This is the first nautical vehicle in Nordenfelt:

Hunting a Stealth Bug

Adding exhaust particle effects to the cannon boat unveiled a curious bug. Check out the following two screenshots:

The upper image shows a boat heading from left to right. In this case the unit has no rotation as the debug display “native rot = 0″ tells. The lower image shows the same boat pointing in the opposite direction, the unit has a 180 degrees rotation. Now compare the orientations of the exhaust particles relative to the boat orientations. Can you see the failure?

Today is the fifth day I’m chasing this damned bug. It’s a really tough beast. Hopefully it will be squashed soon to go on with more interesting stuff to show next Wednesday.

In the meantime feel free to subscribe to Nordenfelt’s RSS feed or follow me on Twitter at @black_golem.

Cheers,
Thomas

Upgrade Triggered Refactoring Avalanche

After collecting all feedback from version 0.1 the first point on the todo list became including upgrades in the arcade mode. That sounded simple. I added a new upgrade object type and integrated it into the collision detection system. Here the first problem popped up: Physical shapes were still represented as polygons, upgrade icons were going to be circular. There was a big “TODO: replace polygons with circles” in the code. OK, let’s replace the polygons with circles. I will have to do it anyway. The avalanche started sliding.

While refactoring the collision code and adapting file formats the latter became painful work. The data formats were simple sequences of numeric values. E.g. a 2D vector was just a pair of numbers and a circle was a 2D vector followed by the circle its radius. The lack of meta data within the files, declaring the meanings of the values, forced me to always reference the corresponding loading source code. That was cumbersome so it was time for the next refactoring step: replacing the old file formats with XML. Next job in the refactoring queue.

The newly integrated upgrades had to load their data from files. They needed sprites, animations and body shapes. The third refactoring job accelerated the avalanche. Hey, I just wanted to upgrade my guns! Oh, wait a minute… equipment needs new upgrade definitions, weapons will have different shoot layouts. Dammit! Next job enqueued!

After two weeks refactoring the hell out of the game all viral tasks were finished. It’s a good feeling that the Nordenfelt engine now has proper data formats, a faster collision detection and upgradable equipment. Now I can go on with the funnier things.

For example modelling the player ship.

The Arcade Player Ship

The poll for your favourite player ship design sketches elected concept G as winner:

Today I’ve made this 3D model from the sketch above. It is not finished yet. Details like plates, frames or rivets are still missing:

IMO concept G is a good choice. It meets the shmup guidelines (AFAIK them), looks steampunky enough and has two Gatling guns! What would our world be without Gatling guns?

Thanks four your votes!

Cheers,
Thomas

There where quite many answers to my call for your player ship favourites. I’m going to start modelling the finalist tomorrow.

If you haven’t chosen your favourites yet: Please drop me a comment here. The current top 3 are:

1. Concept B
2. Concept G
3. Concept F

Click to Enlarge

Cheers,
Thomas

Today I have drawn some sketches for the player ship. Some of them are not complete but the concepts should be obvious.

What’s your favourite design? What are your three favourites, ordered best first? What do you like about them? What would you change?

Click to enlarge

I’m looking forward to your comments.

Cheers,
Thomas