The last 3 weeks led me down a rather bumpy road. After completing a few minor but motivational tasks I hit a road block. It was a problem of show-stopping nature.

Deploy System

In the last dev log entry I’ve mentioned working on an auto deploy system. It’s done and follows this simple scheme:

1. get Nordenfelt‘s  latest version from SVN repository,
2. compile it,
3. archive it and
4. upload the archive to the web server

I start to like scripting common tasks like deploy, directory cleanups an the like. Even if the scripted task can be done within seconds by hand, double-clicking a script file takes a fraction of a second, is less error-prone and needs less brainpower.

Desura

I’ve contacted Desura regarding alpha funding. They were positive about it but wanted a little more media to show. So I started working on a second level type: lava.

It will take a while ’til I can craft good lava levels. This collage is just an “outtake collection”, resulting from learning how to draw lava stuff.

Making Level Generation “Dumber”

When I was experimenting and testing the new lava tiles in-game I hit the initially mentioned road block: the level generator started to crawl. The increased number of background segments combined with the exponential growth of combination possibilities killed the performance. The problem was that too many, yet necessary rules where taken into consideration for stringing together level tiles to a complete level. A few optimizations made it faster but it was the overall algorithm which had to be changed finally. The solution was an easy one, derived from thoughtless human behaviour:

I know it when I see it.

The new generator code cranks out dozens of possible levels WTTM and a final decision maker algorithm chooses the best solution. Imagine a crowd of apes assembling prefabricated houses and one smarter ape who decides which one comes closest to habitable shelter. Sounds primitive? Yes, it is. And it works. 🙂

Outlook

The jump to Desura became more of a low hop. So next time I want to tell you “Nordenfelt is on Desura”. Fingers crossed.

Cheers,
Thomas

P.S.: Get real-time updates via Twitter feed @nordenfeltgame.

The release of Nordenfelt 0.6 is coming close. The equipment tech tree is still missing and there are not enough bosses yet. Nevertheless the first beta version is within sight.

This happened since the last dev log entry:

Gameplay Tweaking

I’ve spent quite some time on improving the gameplay. The biggest issue was (and still is) the difficulty of the generated levels. Several factors like bullet speed, frequency, shot patterns, enemy density and the player’s weapon strength have to be balanced properly. I’ve integrated a difficulty system which determines for different difficulty levels how fast bullets travel, how many and which enemies can enter the screen, etc.

It’s an issue under continuous treatment.

Level Segments

A few new background segments were added to the game:

Crop circles are on the way. 🙂

I also dabbled in drawing a river segment. IMO it turned out not that bad, maybe a little “naked”:

The water stream is not animated. The funny thing is: when you’re playing the game the down-scrolling background creates the illusion of moving water. The eye simply sees what it wants to see.

Fighting Embarrassment

Most game developers (or stuff producers in general) will know this feeling: You keep improving your product because you think it’s not good enough to get published. I had this feeling back in 2010 as I have it today. I see it as some kind of stage fright.

I’ve started two counter-measures. The first was sending the “please fund me” email to Desura. When they say “yes” the ball is rolling and I have to release on a regular basis. It’s no big deal, just getting started is the tricky, frightening part.

The second procrastination killer is an auto deploy system I’m currently working on. It’s simply a sequence of scripted steps to fetch the latest version from Subversion (yes, I’m not using GIT), compile it, pack it and upload it to the web server. When deploy is just a double click onto a script file there is no excuse to not do it.

See next time.

Cheers,
Thomas

P.S.: Get real-time updates via Twitter feed @nordenfeltgame.

Much happened since the last dev log entry. Level backgrounds got finished, boss AI was extended and the level generator grew up a little.

Rural Level Segments

I’ve created several seamless background segments showing rural areas. You may guess which game inspired me for this level type. 🙂

Most effort went into figuring out how to create the details, e.g. how to draw paths, tricks for making the segments seamless or how to create proper water. After figuring out the procedures for drawing the details it became easy to crank out new level segments.

I’m quite happy with the quality of the new background segments. Finally I’ve reached the point where I can make backgrounds of sellable quality.

Boss AI

The first boss got an AI update. Now it has two attack phases with different behaviours.

The most time-consuming task was the debugging. The turnaround times for tweak-compile-play-analyse can be quite long when you’re using C++ and (way too) complex AI code. I’ve considered using a script language for faster turnaround times but decided against it. Integration and porting of the AI would have taken longer than struggling with the C++ AI code. Maybe the next boss will get script support. Maybe.

Level Generation by Blueprint

The level generator got a new feature: level blueprints.

The old generator version took a set of enemy formations, background segments and assembled them according to a specified difficulty. The result was a random sequence of enemies battling in various climate zones within the same level. This testified the narrow “intelligence” of the generator algorithm. So I gave the generator a set of blueprints which instruct it how to assemble sequences of enemies and which background segments make a good level together.

Lives

A big flaw of Nordenfelt was the restart at death. Just one hit was enough and you had to start the level from scratch.

There were different solutions to fix this issue:

• continues,
• lives,
• health bar,
• no death at all

Finally Nordenfelt is a non-linear game and you can play the levels in any order you want. Therefore continues would have been senseless. No death at all would have killed the basic challenge: beat the level. The finalists were lives and a health bar. When you lose a life and can go on right from where you died then there is no difference to a health bar. This is why I decided for good old lives.

Cheers,
Thomas

P.S.: Get real-time updates via Twitter feed @nordenfeltgame.

It’s time for a Nordenfelt status update. On Saturday my dev machine went belly-up so I have time to write a blog post while waiting for the new machine. 🙂

Procedural Level Generation

Designing fun levels isn’t easy. Teaching a machine to generate interesting levels is even more difficult. It’s like telling an instinctless child how to behave. Each time it does something wrong you have to intervene and adapt its behavior for the better. E.g. don’t send in the most difficult boss at the end of the first level.

Developing a level generator relies heavily on iterative improvement. I’m no longer that naive to try to estimate when it’s finished. It’s an ongoing process, aside all the asset and AI programming work. I’ll simply abandon the generator when everything else is done.

Assets, Assets, Assets

I’ve switched from pre-rendered 3D models to “hand-drawn” 2D sprites. It turned out that drawing enemies in GIMP is faster than the first-3d-then-render approach. This blue hovering plane was completely done in GIMP – no 3D involved:

The level generator needs quite a lot of different background tiles and enemies to spread throughout the levels. So I’m busy cranking out new enemies, floor textures, building sprites, vegetation, etc. at the moment.

The good thing about the generator is that it integrates new backgrounds and enemies immediately. There is no need to add new assets in levels by hand. This is a nice side effect which enables continuous extension in a rapid manner.

Plans For Desura

In 2011 I’ve asked Desura if Nordenfelt would be a candidate for their alpha funding program. The reaction was positive. The only flaw they wanted fixed upfront was the soundtrack. The tracks were preview versions from audio stock sites and had voice overlays saying “preview” again and again.

At this time I ran out of money so I had to get a job. Desura wanted their alpha funded games to be in constant development with regular updates. I did not want to be forced to deliver this aside a full-time day job. Therefore I’ve abandoned Desura.

Now I’m ready for the alpha program. I just have to get in contact with Desura again. This will happen within the next few weeks. I’ve already set up Nordenfelt at IndieDB, as an entry point to Desura. I’m not active there yet but that will change when Desura greenlights Nordenfelt.

Cheers,
Thomas

P.S.: Get real-time updates via Twitter feed @nordenfeltgame.

The last Nordenfelt dev log is quite old now, dating back to June. Time to continue this “diary”.

What happened during the last weeks?

Primary Weapon Level System

The primary weapon got a charge meter. Destroyed enemies drop charge balls which fill the meter. This way the weapon gets stronger the more enemies are killed.

This feature will be interesting to tweak. Theoretically the weapon can reach its maximum strength and keep it. But there could also be charge decay, lowering the strength over time. Charge balls could be reduced to full pattern kills (e.g. all planes in a formation). There are plenty of ideas for balancing this feature. Let’s see what turns out as best solution.

Tech Tree Work

Unlocking equipment in the tech tree is done by beating specific levels. E.g. availability of the Tesla gun may depend on resource Dilhamid. This resource has to be conquered by beating level X. The order in which levels get played is not linear. Therefore it’s up to the player which levels (s)he wants to play to unlock the equipment of choice.

No More Money

To simplify the equipment complexity I’ve dropped the money system. In the public demo version money is used to buy equipment. The current version does no longer rely on money but on resources. Unlock a resource and the depending equipment is yours.

I’m Full-Time Indie Again

To be honest: I’ve lost my job a few days ago.

It wasn’t that surprising. The game dev department I had worked for got disbanded in September. Since then more and more game devs have left the company. I’ve tried to contribute my workforce to a high-performance project dealing with CUDA, age-old FORTRAN code and petabytes of satellite data. It did not work. You can’t switch passion to another focus, externally specified.

Shit happens.

So here I am, back in my loft where everything started. I’m full-time indie again, armed with more marketing knowledge (from selling my book), more business insight, and a little wiser in general. Will it be enough to survive? Don’t know.

The only thing I know:

I’m happy to be released from the “machine”.

2013 will be a great year. Come what may.

Cheers,
Thomas

P.S.: Get real-time updates via Twitter feed @nordenfeltgame.

A few days ago I’ve finished reading 37signals‘ e-book Get Real. It’s a manifesto how to write better software faster. Most of the content reminds me of the mantra-like agile knowledge infiltration in software management during the last decade. You know, Scrum and the like. This may sound a little pejorative but it isn’t. Get Real is an easy read, no pointless chit-chat and full of useful hints to make your programming life easier. The word “agile” just became a little outworn and buzzy these days.

Anyway, this book made me thinking how to translate the “new feature deploy” points from web development to desktop games. When you’re making a website updating is no problem. Changes to the server side immediately change the client side. Installed software OTOH needs the user’s permission for updates. How to implement this as painless as possible?

In the year 2012 updates should no longer have to be explicitly downloaded and reinstalled. Auto-update is the word. So I’ve added a new update system to Nordenfelt‘s work agenda. Basically it should inform players at game startup that there is a new version available. An optional click on an update button should download the new stuff in the background while the player is blasting his/her way through the levels. The next time the game gets fired up the new version is available. No installing, no additionally running update programs in the background and no annoying pop-ups “you wanna update?”. Hopefully I’m able to write such a slick update system. 🙂

Cheers,
Thomas

As I’ve mentioned in the last post I started writing a book back in May/June. First it seemed to be just a side project but grew to a full spare time hog quickly. Therefore I had to freeze Nordenfelt until the book was out in the stores. As usual, this project lasted longer than expected. That’s the reason why this blog did not get any updates for a long time.

Anyway, I’m happy to tell you that it’s done:

Check it out: www.collisiondetection2d.net

Read the full story about the book here.

At the moment I’m unfreezing the Nordenfelt project. I’ve decided to change the work approach before going on with the game. Things like roadmaps, predefined specs or bullet point feature lists turned out to not work as expected, neither for me nor for Nordenfelt.

I’ll keep you up to date about the next steps here and on @nordenfeltgame.

Cheers,
Thomas