Shadows Finished

I’m always pretty lazy during Yuletide. There is hardly time left to work between all these celebrations and events.

Nevertheless, I’ve finished drop shadow rendering yesterday:

Read this if you are interested in how this sausage was made.

What’s Next?

The next big points on my to-do list are:

• reactivate adventure mode
• online highscore board
• create real game-play in available levels
• finish graphics in available levels

I don’t know which one should come first. The order basically depends on the time point I’m going to switch over to closed beta. The alpha phase should end in the near future. That means Nordenfelt will start to cost a few bucks. It will be a fraction of the final price. Purchasers will get full access to an exclusive area where they can download all versions and can take part in the further development process. Finally they get the full game for free when it’s done.

Going beta at the end of February seems feasible. After a year building the engine it’s time to leave the demo state.

I’m looking forward to welcome you in the exclusive beta area!

Cheers,
Thomas

2010 is coming to its end. Time to recapitulate what developing Nordenfelt tough me so far.

What Went Right

Early Showcases

The best way to know how your game will perform in the wilderness is by sending it right there. At the beginning I was afraid showing ugly test graphics and features which won’t make it into the final version. I thought people would laugh and ignore my project immediately. But that never happened. There’s the phrase “no interest in how the sausage is made”. Not true, at least for game development.

Dumping Thoughts on the Internet

Posting thoughts, feelings and lessons-learned gives your product a human touch. It shows people that you are not a cold, capitalistic corporation but a human being. They will remember your best/worst hour if you share it with them. And they will remember your game.

Learned How to Handle Feedback

Feedback is a double-edged sword. It can improve your game or push it off track. Don’t follow each advice. Most of them are well-intentioned but may not marry up with your own vision. Finally you can’t be everybody’s darling.

3rd-Party Libraries and Tools

What should I explain here? Simply save work time by using external libraries and tools as much as you can. Don’t reinvent the wheel.

Data-Driven Content

That’s a common trade-off: should I hard-code this or define it in an additional file/database/whatever? The former is the fast solution at short sight but the latter becomes apparent to be the better choice in most cases. At the latest tweaking for game-play will extrude many properties in a bunch of files. So why delay it?

What Went Wrong

Lack of Exact Vision

In the shmup genre some distinct game mechanics evolved over time. There are game-play styles like danmaku, maniac or memorizer. Scroll movement can be vertical, horizontal, isometric, inside an arena, etc. From the very beginning I knew that Nordenfelt will become a vertical shooter. Reading about all the different game mechanics and scoring systems soon confused me. What I should go for? Each time I’ve settled for one game mechanic I became aware of two new ones. As long as there is no clear goal you can’t follow the shortest path to it. It’s that simple.

No Clue About Visual Style

In the early days of Nordenfelt I wanted it to have sprite art. It’s the graphics style I like the most in shmups. Some investigation into this visual style made it clear that sprite art would be the wrong choice. Modern high resolution monitors and the cumbersome nature of sprite art made it hardly applicable for me. Prerendered 3D models were the simplest solution I could imagine. This insight took nearly 2 months. In this case my lack of artistic experience wasted many hours.

Less Design Results in More Redesign

Quick and dirty hacks may solve problems immediately. In the long run they become hurdles where you have to jump over each time you alter code around it. Soon they become real show-stoppers. So you have to fix them by redesigning this part of code. The longer you wait the more work (exponentially growing) it will be.

Back-End Features

One of my favorite interests is procedural content generation. I’ve planned using PCG heavily in Nordenfelt. So I started off by implementing algorithms for building levels, distributing enemies and concatenating these levels to an appropriate story. It was really fun… for me! But the game-play did not profit from PCG. Therefore I switched over to handcrafted levels. IMO it’s important to be able to design levels by hand first before you can write algorithms mimicking the design tasks. The human factor won’t disappear from creating game-play in the near future. But PCG can boost the boring parts a lot.

Forging Nails Yourself

When you want to do every part of the game yourself don’t be surprised if everything lasts longer than planned. Forging your own nails can be rewarding work but buying them in a hardware store saves you a lot of time.

goto 2011;

That’s it for my very first year in my career as indie game developer. I hope you enjoyed the journey so far and keep following me here, at www.blackgolem.com, on Twitter or Facebook for another year. We will meet again in 2011.

Happy new year,
Thomas

Nordenfelt 0.3 is coming and it will have a new level and new enemies.

The whole procedure of designing/modeling/texturing/rendering of level parts and enemies is sooo time consuming. These tasks are millstones around the neck in times of feature testing. Therefore I’ve entered “MS Paint mode” (again). Rule of thumb: graphics must be as simple as possible but have to represent the intention.

Second level, MS Paint graphics

The primitive shapes and gaudy colors may bring you eye cancer. But hey, they are functional! Improved test graphics won’t be as distinguishable and may be kept in the game forever for compromise. These ugly geometrics will never survive ’til final release. Critics would eat me alive!

The testing focus of version 0.3 lies on gameplay. Graphics will follow – in beta versions, starting before 2011 (hopefully).

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

Hi! This is Thomas (aka hermitC) from Black Golem and this is the new blog for the upcoming Steampunk shoot ‘em up Nordenfelt.

Site Changes

Some of you may have visited this website before. The former layout was a simple information panel with a newsletter subscription form. BTW: Feel free to subscribe to the email newsletter. You can find the subscription form on the right hand side of this blog. Subscribers will always receive news first!

This blog is dedicated to players, testers and finally customers. Everything concerning the progress of Nordenfelt’s development will appear here. Everybody is welcome to comment on the development state. Nordenfelt relies on your feedback. Playable demos of the game will be published regularly. The first version (v0.1) can be downloaded from the download page or directly here.

The Game

Nordenfelt is a vertical shooter for Windows, settled in an alternative world where Victorian art and science meet modern views on technology. This combination is widely known as Steampunk. If you have no clue what Steampunk is, this illustration may give you an idea:

The picture contains many Steampunk basics like Victorian fashion, giant steel constructions and advanced mechanical vehicles. It shows an alternative path in time where the culture and science of the late 18th century was never ousted but developed to their maximum. The fictional aspect of Steampunk is a great challenge. Everything is possible but it has to work within the physical rules of old knowledge.

Concluding Words

I hope that some fans will gather here. Your input is important. So let’s make Nordenfelt an enjoyable game!

Cheers,
Thomas