Sunday 29 July 2012

Elitism in roguelike scene

This subject was discussed in the roguelike radio with Hugh "Darren Grey" Grant and Ido Yehieli. What I think of this whole matter is that some people are too keen to accuse others to be elitistic if we even can use that term in roguelike development scene. I think roguelike developers are actually the least elitist group of developers out there. Just think of it. Most roguelike games are not only free, but include open source to share ideas, design and programming techniques. It's not like we were typical software developers with silly amount of money and couple of sports cars. I'm proud of the fact that game development for me is anything else than trying to make money.

There has been some talk about how to make roguelikes more accessible to "average" players. Isn't that kind of thinking actually elitism? I like to think that players are clever, possibly even more so than me. I don't design games for dummies like all commercial game developers seem to do. I want to make roguelike games which are as complex as possible. (Of course it's easier said than done.)

There is something I kind of agree with and it's the discussion about "what is a roguelike". It's a pointless discussion, because the genre isn't strictly defined. Well, other than being turn-based, including permadeath and random content. And role-playing. I think that should cover it. But I think we all know when a game is more than just @ walking on screen or one-trick pony like 7DRL games.

When you try to make games more accessible or try to think what players want you end up creating games like Fable. For me the most important thing in game development is having a clear vision of what you want as game developer and a player. However it's good to keep yourself open to suggestions if there is something in your game that players might hate. Let's not forget that most game developers are not good at what they do. So it's important to learn from the feedback, while keeping your own mind.

Tuesday 24 July 2012

Two problems

It looks like I run into two main issues in roguelike development. It happened with Kaduria and now with Teemu. First problem is the way I'm trying to write "perfect" source code and move from hacky to more pure style of source code. It would be good of course, but it's taking time, moving release date away to distant future.

Second problem is the role-playing system. When you try to develop one from a scratch it's not easy. I think most roguelikes have something like D&D or similar which is taking the easy way. But when you try to figure out everything yourself and build a rpg system it's just chaotic. The current system in Teemu is really simple so it wasn't hard to do, but anything more complex than that means you need to plan and think hard. And as we know, thinking is not something I do.

Monday 16 July 2012

Random monsters

Update scheme and whole GUI class actually is now in much better shape than it was before. The gameplay feels a bit faster.

I've moved on random monsters and trying to create a generic system which then accepts any new monsters added in the data, except special monsters made only in special level themes. In more generic creation there is a need for automatic balancing which prevents creating too many difficult monsters. Or another option is non-balanced and make the game more difficult.

Monday 9 July 2012

Update scheme almost ready

New GUI update routines are now ready, but there is a clean-up of old manual update routines yet to finish. One major thing I noticed was that there was a call to world->Update (now Redraw) which cleared the screen and then redraw everything in each turn. The new version is designed to prevent that kind of stuff which is slowing down the game even it can't be noticed on modern PC. Another thing I need is the actual redraw of elements to have same kind of notification that FOV rebuild has. I think gameview (Level::Show) needs it at least. It could be called Level::Request_Update to mimic World::Request_LOS_Rebuild.

There are quite number of manual updates which have to be resolved by better program flow with less calls to update routines, mostly concentrated running only once per turn. It's time consuming trying to build a "perfect" solution, but I think it's worth the effort.