Slow progress is slow.

[Bear]

I've been working on and off (mostly off) on the roguelike game for years. 

First attempt:  Made an architectural mistake because I was playing and experimenting instead of properly thinking about how to organize a major project.  It got harder and harder to make progress, and I worked on it more and more seldom because it was frustrating. Finally I realized that I'd made a fundamental error of design that made reliable memory management impossible (yes, I'm using a non-GC language - on purpose).  Threw it out.  Over  a year later, I started again.

Second attempt: Excessively simplified design didn't allow me to do things much more interesting than early angband variants were already doing them.  I worked on it less and less because It got boring.  Eventually decided that if completed it wouldn't represent an improvement over existing games and set it aside.   Then I got sucked into a full-time job for several years, did nothing on roguelike front.

Third attempt:  Excessively baroque design made content too hard to manage.  Got the whole thing written, but realized at about the 10th complete monster definition that I had created a system in which I'd just spent six weeks on Goblin Villages, mostly creating things and interactions that players would never see or care about.  And that the baroque features allowed monster types individually valid, to be incompatible with each other.  Thought about that for a while.  Vaguely intended to improve it but spent a very long time for the right idea about how to fix it to strike, and it never struck.   Eventually I guess I  stopped thinking about it.  A year or two later the hard drive it was on crashed, and I realized I didn't have a backup of the code.  But considering everything, maybe that was for the best.  Started over completely from scratch (well, not completely; I did reuse my line-of-sight code, map representation, and a few other things).

Fourth attempt: Now happy with my architecture.  Working very carefully.  Design draws heavily on the "learning experiences" of the past.  Everything I want to do can be done.  Everything that can be done can be done without introducing conflicts.  I built a good really good plugin code interface; just drop the source file into the plugin directory and recompile; you never need to touch any existing code, worry about conflicts, or manage diffs or patches.  Built a sort of "engine without content", then took a couple years off after growing completely disgusted with someone in the community and what I saw as a general breakdown in civility and discussion.  But eventually I dusted it off and continued because, well, becoming disgusted with one antisocial idiot and the deaths of a few forums shouldn't be something that stops me from doing something that is fun in itself. 

Now finally I'm back at the point of starting to add content, a lot of it is 'category' content (poison, f'rex) that is as much an addition to the engine as to the game, and will be eventually depended on by other content (venomous snakes, poison arrows, potions etc).  Other content is 'ubiquitous' content like, say, doors.  They have to be done, and they have their own complexities, and they're their own category, and they're basic enough to be considered part of the engine - but they're not 'category' content that other things are going to depend on.

Today I added the first (to this architecture) normal monster.  It's a little tricky, because this monster (which happens to be a wolf) is defined in a plugin.  Plugins get called at game startup and essentially work by adding entries to tables and registering callbacks.  So, a landmark of sorts.

There is a little bit of 'baroque' going on with the architecture - in a way that results from making things very general.  The whole architecture comes down to just a few kinds of thing, Events, Actors, Properties, and Triggers.  First there are 'events.'  Any thing which causes a change in the dungeon is an 'event'.  And an 'event' can add more events to the schedule.  The entire game consists of loading the Game-Start event into the schedule, then repeating get an event, do the event, until the schedule is empty. 

All creatures, items, terrain features other than floor and walls, and even the player character, are 'Actors'.  Most events affect Actors.  'Actors' have an unbounded table of 'Properties' that describe them.  Among these 'Properties' are a few special ones called 'Triggers' which are checked before and after the actor is affected by an event.  If there's a trigger that responds to that event (and that actor's role in the event), it results in code being executed. 'Trigger' code can schedule new events, modify scheduled events, or set properties, etc.

Each event can set off triggers, and triggers can schedule further events. These triggers can be set arbitrarily on the actors that an event affects.  For example, when someone puts on blink boots, that's an event.  The blink boots have a trigger that schedules an immediate action when they are the object of a 'wear' action.  The action they schedule sets a trigger on the wearer which will go off anytime the wearer is the subject of a 'walk' action.  Now whenever the wearer walks, another action which teleports him a short distance in the same direction is scheduled immediately after. 

Adding content given this setup is -- tedious, but not because of irreducable non-automatable complexity.   Much nicer than last time, anyway.  A few convenience functions and so forth will streamline it a lot; right now I'm still at the stage of figuring out what the repetitive tasks I need to automate are. 

So anyway; progress is being made.  It's just slow.  It seems hard to me to understand how quickly others are working; I feel like I spend a week or two fairly frequently just waiting for inspiration about what the RIGHT way to do something is. 

[Danakh]

Ideally, if you define both wolf and fox, not much would change between the two.

Cannot you define some meta monster ?
Like Standard close combat monster (monster that can only attack in close combat). Then wolf inherit from this monster and only redefine some properties like movement speed.

Later, when you improve your game, you can add a new meta monster like "monster that fight in pack" with AI behavior that flee when alone and fight when with other monsters of the same kind. This meta back inherit from close combat monster and then wolf inherit from this new meta monster

On a more general purpose. I found it is often (not always ) a bad idea to throw all the code away. Maybe your first project, but not 3 f them. The key is to have a playable thing as fast as possible, and then improve it when you need a new feature, step by step. Refactor your code all the time.

[reaver]

I can sympathize with the slow progress. Being a bigger project than a toy one, it's not unreasonable that it takes time, especially with a job etc. The more you spend on perfecting your engine, the more time it takes away from making the game. You'll never get a perfect engine (hey, it's software), and even if it's near perfection, chances are almost nobody else is gonna use it seriously (besides peeking at functions), unless you spent at least as much effort in documentation, clear APIs, language that people want to use etc.
So, get on with making the game. Adom or nethack or angband or whatever did not spend 90% on engine and the rest in content and mechanics, it should be much more balanced, as it's supposed to be fun for the person playing. In order to make it fun, well you're in software and you know how it goes, "release early, release often".

Anyway, my 2c.

[Krice]

then took a couple years off after growing completely disgusted with someone in the community

Off from development? That's dumb. It's as I would took off from development, because I find some random person disgusting. Who makes that kind of decisions?

What comes to development there are two ways to do it (and everything between). First way is plan features, content etc. and then write code for them. Second way is first write "engine" for possible future content and then try to add that content. I believe the best way is really something in between: you need a good engine to add content easily, but you should always have a plan for the game content in the first place. The technical details are less relevant than the gameplay.

[Bear]

Working on the engine is making choices about what kind of effort I want working on the game to take.  I'm making it for me, and won't be disappointed if nobody else uses it. I am documenting it with a "modders guide" but that's as much notes for a future self as it is for anyone else. And besides, the engine actually holds my interest, so it actually gets worked on.

Yes, there's a certain amount of abstraction going on.  The 'wolf' definition allows me to see all the things that are getting done for this kind of "normal" monster; now I'm going to go make an initializer or two that take a few parameters and do them, so that in the future it's all easy to do with a single call.  It's a DataDirected design rather than ObjectOriented; so rather than "inherit from a class and specialize" I have "use the same initializer and customize."  But it's very similar in terms of development. 

And no, becoming disgusted with the community and lack of civility didn't mean I quit programming; it just meant I spent a few years working on completely different projects with completely different communities instead, both having to do with language - which is another enduring interest of mine.

[Krice]

I'd like to add that people who get disgusted about some strangers on the internet they don't even know are disgusting themselves. It's sad, really. Those kind of people can't wrap their head around some people being assholes. Deal with it, this is humanity.

[Bear]

But it is simple enough, even on the internet, to find venues populated by those who have more pride than disgust in their humanity, and so seek to be better rather than worse.  Fault no one for preferring such venues nor for seeking to participate in them.

If I allow myself to participate when too angry, I am likely to say or do things that degrade rather than elevate humanity.  And humanity is too important for me  to permit myself to do that.  It is better to be part of a healthier community elsewhere than to contribute to a problem.

[tuturto]

But it is simple enough, even on the internet, to find venues populated by those who have more pride than disgust in their humanity, and so seek to be better rather than worse.  Fault no one for preferring such venues nor for seeking to participate in them.

If I allow myself to participate when too angry, I am likely to say or do things that degrade rather than elevate humanity.  And humanity is too important for me  to permit myself to do that.  It is better to be part of a healthier community elsewhere than to contribute to a problem.

Well spoken.

[Krice]

It is better to be part of a healthier community elsewhere than to contribute to a problem.

Maybe you should then get the fuck out of here and go to some Christian forum. Those people are like you, they are just better than everyone else.

[reaver]

(Shitty talk as usual)

Just stfu please.
Bear, use ignore and be happier.

[koiwai]

My programming habbits are quite similar, with long periods of doing seemingly nothing, thinking about the game systems and how they should interact. However, no matter how enjoyable this process might be, finishing and releasing something is also very important.
My first relatively successful game was Curse of War - a rather simple project actually, but I was lucky to get some attention from the Linux community, and some nice people joined to help me make the game better. I've got a good (and maybe surprizing) lesson that even a simple project like that takes quite a lot of extra work after the main programming work is done.

Let me share my thoughts on how to speed up super-projects (if it is possible at all  ):

1) Start with the most important core game mechanics. They must be fun to play, and they should work really really well. Everything what makes the "meat" of the game (e.g. Combat(!), Skills?, Generated contents) must be there as soon as possible. (This is probably my main criticism to URR: while it is an admirable game/art project, and I agree with the author on many things, it is still not clear to me, will it eventually become a game or not; I wish he succeedes).

2) The engine should not be more complex than is necessary to implement those core features. Of course, it must be flexible enough to permit adding new functionality, but if it is an order of magnitude more complex than the game, I should switch to programming the game itself. (And, btw, game engines as separate projects are no good by themselves, unless they have a dedicated group of people who are using them for making actual games)

3) Try to find game mechanics that can be easily and efficiently implemented! Probably, it does not sound like very fun, but it may actually turn out to be a great improvement to your game. On the other hand, struggling to implement some dream design feature may become a reason to detest and eventually abandon the project.

4A) The game contents should not hamper the way the game is implemented. I try to generalize the game, and factor out specific details. It takes time to do it right, but at least you would not get stuck at a later stage with some unmaintainnable structure.

4B) On the other hand, avoid unnecessary layers of abstraction. All game components must serve some purpose. OO code tends to look funny, with infamous god classes, and everything is an object kind of thing. As John Carmack said: "Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function."

5) Essentially, I think, it is important to make the game grow steadily. When all components are developed simultaneously. Then, you have many things to work on, so you are not getting bored (I remember Dwarf Fortress developers were saying something like that), and you find bad design decisions early on, when you still can change them.

There is nothing new, but I think, it still may be interesting to those people who want to program something big.

[Bear]

I started with a few firm ideas in mind as to game mechanics and UI.  I don't think I've done anything yet with the engine code that isn't directly in support of these things.  My basic gameplay idea is to make the (so far three) classes play as differently as possible. 

First I want to have a spellcasting class that actually spends game time casting.  By this I mean in contrast to physical combat where you make an attack and it takes effect instantly, the spellcaster will choose to cast a spell - then time passes and other creatures take their turns, *then* the spell goes off and it's the spellcaster's turn again.  So you have to think ahead and choose carefully for spells.  On the other hand you have the option of following-up your (delayed) spell attack with an (instant) physical attack that will take place immediately.  Also spellcasters will be drained of magical power (and fae or magical creatures physically burned) by any sustained contact with iron or steel.  So I expect a lot of them to have wooden staves or silver, bronze, or obsidian daggers as their primary weapons. 

Second I want to have a fighter class with some tactical combat abilities that other classes don't get; fighters will get accelerated attack speed against creatures they outclass, cover and maneuver bonuses, en passant (move by) attacks while moving, etc.  These are supposed to be things which will frequently benefit even those doing simple "bump combat" without being aware of the position and maneuver bonuses, because they don't involve using different keys or actions than regular "plain" bump combat - they work by giving damage or timing bonuses,  whenever the *sequence* of those commands indicate that the player is triggering one of the specials.  Even those who are unaware will eventually notice certain move sequences like move/attack in the same direction being unusually effective (game treats it as a "lunge" and gives an extra-fast attack with extra damage) and start building tactics around them. When someone is completely aware of the fighter abilities, maximizing the benefit to be gained from them should make combat tactics a more interesting subgame than the classic "bump till it's dead" technique. 

Third I want a thief/rogue class that is interesting mostly because of noncombat utility skills - doors, locks, traps, sneaking, poisons, medicinals, etc.  - and is actually viable in terms of those skills, rather than having to rack up innumerable kills because of an experience/power treadmill driven mostly (or solely) by racking up kills.  Which in turn drives a whole experience mechanic where each actor has a finite pool of experience it can transfer to you, and you get some fraction of the remaining pool for every interaction with it - the thief is capable of having a greater variety of interactions with a greater variety of actors, and will get at least as much experience as other classes get from combat.

Finally, I'm aiming for a fairly small power progression in terms of damage.  I'm balancing on the basis of final "winning" characters, even for a fairly long game, who have less than 8x the hitpoints they had as starting characters.  Which means that shockingly low-level characters, while they will be very likely to get killed if at all incautious and may be stymied by some obstacles, won't automatically be squished like bugs if they dive aggressively. 

[CaptainKraft]

Bear, do you have any games that you've made we can try or maybe parts of your current project that we can play? It would be great to see some of your progress.

It might be fun to take parts of your big project and make some tiny side-projects just to see something through, get some feedback, and slowly but surely build up the modules that you will use for your engine?

No matter what you do, I'd still like to see what you're working on. Getting hand-on experience playing a game is much better than just hearing a description.

[koiwai]

The design sounds great. The rogue class seems to be the hardest, all special/hidden objects must be put on the map in a meaningful way, and balancing may be tricky. However, in principle, even "normal" characters may eventually benefit from such special objects, if, for example, a melee or magic character trains some simple rogue skills too.

I agree that making a playable demo is a good thing. Even if not many people actually play it, there may be some meaningful discussion, the project gets potential players, and it is also an additional motivation for the developer. On the negative side, people may try a half-made game and never actually return to play the final version Or, I don't know, the story should not be released too early, but then again, a limited demo does not have to be a complete game. Anyway, good luck with your project.

[Bear]

At the moment, The surface visible effect is of @ is walking around a cave map and able to fight 'w's.   There's not even a win condition yet. 

Next monster to implement has its own lantern, so I spent today hacking line of sight code to handle multiple sources of illumination and wall squares being light-able from multiple directions.  It needed a fair amount of new code because I don't want wall squares to show up when they are lit from behind.

I drew a line in the sand for the first release version: when I have the three classes complete to fifth level, fifteen monsters each with its own fully-implemented different set of abilities (like the next one has a light source), and fifteen items each with its own fully-implemented effects, I'm going to call that a releasable first cut. 

Poison which I've recently spent time on will support the "giant ants" in my first-cut, but they will have other aspects too, such as a recognizable characteristic nest tunnel structure (which I've coded but not yet integrated into map generation) and a certain level of group tactics which will show up as special abilities and AI, that I haven't started on yet.

Anyway, I picked the first fifteen monsters to be creatures with special abilities, specifically in order to drive  implementing a whole lot of the major game mechanics or 'Category' content.  So, having done wolves, I'm doing other creatures having as little in common with them as possible for the first cut.  Jackals, dire wolves, wild dogs, etc....  later.  First, on to things that require as much of the category content as possible to get implemented and tested.

Maybe the boss monster will be the Hobgoblin king of a local Goblin tribe.