07.02.2014

Abilities is on the move to finalization. This story is getting a bit old, but managing abilities would be main player activity. So, it should be done very well.
GoodSir sent me mockup of interface. I began implementing in to the game. Screenshot in a day or two.
My list of detected bugs and defects grows, it means I'll have a "defect fixing day" soon.

Future history of Fallen

It is the sketch part of “About Fallen” page. It would be edited, steamrolled and placed there.

I plan to make this blog real citadel of Fallen, until it would need personal site.
Don'd hesitate to point me something or ask question. It would be really helpful!

History of Fallen the Roguelike

Fallen was completely different game or better say games during its development.

I want to write here short story of this project.

Wish it would be interesting for everyone, who like roguelikes, roguelike development. Would be helpful to roguelike developer to avoid my mistakes and at least, but not the last, would help me to put everything together.

So.

The development of the project, that eventually morphed into Fallen had begun in very late 2008. Maybe 28-30 of November, maybe December. Frankly, it would be better to say, that I have started it in early 2009. Also, it doesn't mean, that it was in development for all this years. At least one year, 2011, I didn't even touched it.

From the very beginning I was the only developer of the game, full of plans and rather inexperienced for the project of that size. Both in programming and game design. I thought, that my previous vast experience of “hand-made” ^_^ board and small computer games would be more then enough.

Of course, I was wrong, but I'll write about it.

First of all, the design document wasn't a design document at all, it was mere “coll stuff” list. Like, we would have golems, labyrinths, robots, lot of items, materials, global map, realistic combat, poisons, factions, bodyparts, wounds, pain, craft, wood, demons, nuclear war, fruit trees and cookies.

Doubtlessly, it was a death march project.

The waves of understanding.

Wave of team

I think, it the most important one. That help me to endure others. I was doubtlessly lucky that GoodSir to join the team. Feel of friend's shoulder, brainstorming, support, art, teamwork etc.
As I wrote for many time, without team, Fallen would be one of many “died in defunct” roguelikes.

Wave of code

Programmist. You need at least one skilled programmist for your roguelike, no exceptions. Sounds rather obvious, isn't it?
Roguelikes looks like really easy program, until you try to make one. There are lot of cross linked data and you have to keep it running smoothly.
It could be you, member of your team, you found, hired, enslaved or mesmerised. But you need this person!
Reading McConnnell's books when you already have bulk of smelly Cobol-style code, could be rather painful. I knew lot of projects, that died on this stage and, it is really pity, would die.
Fall From Heaven the Roguelike (old name of Fallen) gone the same way. Except I was stubborn enough to revive it for many times.
I'll put myself together, overcome terrifying shame and post my old code or “the best” parts of it. Maybe, it would help you to avoid my mistakes. I wish it to be so!
You can learn programming or make roguelike, but not simultaneous.

Wave of game design

Writing a design document after a couple of years of active development is cool tradition of Russian gamedev (c).

My philosophy of game design is that you can create the greatest algorhythms -- but it's in vain if you don't have a REASON to have them.
For example, the Roguelike "Fall From Heaven" had a couple of relatively working versions. It had tons of features, lots of places to visit, monsters to fight, neat pixel art, and etc. There's one thing wrong with it, though -- it was unplayable. This overwhelming swamp of features ended up being boring and useless.
I asked myself a funny questions -- "Why is Fall From Heaven the Roguelike not fun? My previous games were hella fun, but they had 1/100 of Fall From Heaven's features!".
Answer beat me with ugly stick. Lot of features doesn't mean fun. Useless feature would take your work as any other, with one exception – it contributes nothing to aspect of gameplay.
It was the moment, when I armed with big rusty knife, started to cut feature, balancing and reworking the remaining one.

But. Poor project architecture stroke on this stage. It was so fragile and overburden, so 80% of my efforts was put to keep program running with new changes.

This can lead the project to couple of ends.

First, the grave one – the very end of the project. We have seen hundreds of them. To tell the truth, I was close to it.
And the second, put yourself together and move on, step by step:

The King has died, Hail to the King

Old project collapsed at the summer-autumn of 2013, under burden of its unsupportable code. Yes, it was mostly technical fail.
I put my best to refactor it, but.. well.. it didn't survived the operation. I took couple of units, nice algorithms and started Fallen Rebirth at autumn-winter of 2013.
It was Paradigm changing decision.

I was always saying: Don't rewrite your project from scratch and did it myself one day.

Frankly, is there any other way to progress? Learn rules and ideas your workspace has, form the paradigms and them move them on!

Want to be creative game-designer and invent something new? Learn existing rules at first, play great games, write down cool ideas, analyse them, don't hesitate to copy, study, be openminded and then be ready to move forward.

Fallen Rebirth.

It is young, but looks promising. It's design document has, maybe 1/50 of “wannabe features” of demised project, but it isn't an overweight monster on a death row.
It is already ten times more playable, then old, full of features game.
The time will show the results, but GoodSir and I will do everything that we can to make Fallen to rise.

Spawning Algorithm

As I promised here, I'll post the details of my monsters spawn/ move algorithm.
What this algorithm is useful for? Well, for example you want to provide constant challenge for player by adding or moving waves and waves of monsters on player's way or you just want to spice up a game play with occasional monsters spawn.
If you don't really care, you can just spawn monster where player doesn't see. It is easy and cheap way, but can lead to "OMG, this red dragon spawned right behind me in room I cleared! It isn't fare!" situation.
If you are okay with it, do it this way. It is no problem in most of roguelikes and still funny.
The problem comes when you have lot of pregenerated monsters or big map to travel, or you dislike "spawned behind" feelings.

So, you want monsters to spawn in front of player, not behind it. It is no problem, lets look.

@ - here is player or player character (PC).
PC can move in 8 directions.
1   2  3
4  @ 5
6   7  8

The easiest way to check direction, where player moved, and place monster in this direction.
For example, player moved to direction 5, so we can place monster to 3,5 and 8.
It looks simple, but it wouldn't work, because PC rarely moves in one direction for long time. PC maneuvering, fighting or exploring.
It woun't be really helpful to save last 10, 30, 100, 90890809 PC moves. Because, it can be messed up, after combat or labyrinth.

What to do? We would use weight based algorithm.
First of all, we will make an array of PC moves for 1 to 8 or Up_Left to Down_Right, if you like it this way.
Then, every time PC makes turn, we decrease all array variables by 1 and when PC moves we add 2 to direction it goes and 1 to close direction.
For example, if PC moved to direction 4. We place 2 points to 4 and 1 point to 1 and 6. (You can extand algorithm and place 3 points to move direction, 2 to closest, and 1 to close to closest. It is up to you.).
Then, when you want to spawn monster you just select direction, where monster appears by using weight based selection (the bigger value of variable the bigger chance it has) from directions, that has value bigger then 0.
It isn't ideal, but simple and would guarantee rather sane monster placement.