This project has some features that have been unfinished for a long time - for various reasons. I thought this message count thing was going to be the next one, but in just a few minutes ago it was fixed. What I now often do when I get a difficult problem is that I close my computer and get some paper to plan how to fix it. Surprisingly it works often than it doesn't. Planning on paper is free from any distractions and you can literally visualize the problem by drawing it if it's something you need to do.
When I look at the list of unfinished features I have to evaluate them again. And again.. but it's difficult to make a decision to delay the feature or even worse - remove it.
You bring up an issue that plagues us all as developers. Which features to cut and which to keep? It's a good thing you aren't letting feature creep set it too heavily.
ReplyDeleteAny tips on how to decide what to cut? I know I have trouble making cuts.
I think "trick" features are those you can delay or even remove. The kind of features that don't play important role in the gameplay. When you plan features it helps to understand how much they require work or can they be implemented with the current engine. If not, how much the engine needs to be changed?
ReplyDeleteI have a good example with hidden items in Kaduria which had some kind of source code from the old version where some hiding places were simply terrain tiles. But it's obsolete now since you can hide items only inside other objects. Things like a bush can be also a container (of hidden items). It's a different way to do it so I had to remove the old code and for now there are no hidden items at all. Working with "legacy" code is sometimes like this, you have to remove something which doesn't work properly with the current engine.
Good advice.
ReplyDeleteMy main problems stem from thinking too big and always wanting to add more features. Just have to focus on the core mechanics and get them working well before I throw in more stuff.