The Role of Planning and Design in Rougelike Development

[damakun]

Hello ! I am new to rouge dev, but not new to programming. I have lurked here and at rougebasin, and I have not seen much discussion about "modern" development practices. Granted, I don't want to shower people with corporate buzzwords, but I wonder what role does OOP and RAD play in Rogue-dev, if any ?

Indeed, I see a great deal of trial by error. How much planning goes into a Rouge, in general ? Are data structures, key interactions, etc. thought out in advance ?

Also, how long does it take to complete a rougelike to the point where it is playable ? How much time does it take to maintain out in the wild ?

On an unrelated note : thinking of using java or a game builder like Torque (the 2d version) - any ideas about that ?

Please let me know if you need me to clarify or give additional information. Thanks !

[PaulBlay]

On an unrelated note : thinking of using java or a game builder like Torque (the 2d version) - any ideas about that ?

There are a lot of roguelikes that use Java.  It may be worth checking out the competition (/possible sources ;-)

http://roguebasin.roguelikedevelopment.org/index.php?title=Java#Java_Roguelikes

[corremn]

Hello ! I am new to rouge dev, but not new to programming. I have lurked here and at rougebasin, and I have not seen much discussion about "modern" development practices. Granted, I don't want to shower people with corporate buzzwords, but I wonder what role does OOP and RAD play in Rogue-dev, if any ?

Most new RLs out there are taking the OOP approach but like most approaches to just depends on the developer and what skills they have. If you are capable of doing OOP then dive in. I think all new rls use the RAD approach because thats the only way to do it from scratch, incrementally speaking. I would guess and say you are a software eng or cis student .
Lots of planning or not much at all will get results. Like I said its all up to the developer, I started just programming cool features will no real plan, but now I plan my games very heavily.  A plan is great if you can stick to it, I cant and I think most developer dont either.  We always shoot of in tangents.  I think if you know what you are doing then go plan crazy, if not then hack away and wait for the inevitable rewrite.
I dont think out any structures in advance, I find it easier to program on the fly.

Roguelike games generally take years to develop, but if you have a lot of time and stay focussed you could probably get a large rogue out in a year, 6 months for a small one.  Then you will spend years maintaining it if it is successful.  You will never have enough time for it though, all roguelikes are efected by lack of time, no matter how eager to dev was to begin with.

Using a 2D game engine is a great idea, I believe you will save some time and be able to add effects/detail that you would never be able to do in a short time span.  OTOH developing it from scratch will teach you a lot more. You can cover the middle ground and use a roguelike game engine.

SO in answer to your questions, it just depends on what works for you..

Good luck.

[Krice]

I wonder what role does OOP and RAD play in Rogue-dev, if any ?

OOP is just one way to go, but I think it's good if used properly. The most important thing in roguelikes or any large scale project is consistent way of doing things, which prevents refactoring. It doesn't hurt to have a good design, but it's actually hard to know what exactly is a good design and how things like gameplay balance is achieved.

It's notable that there have been professional programmers who claim how easy a roguelike is to do, but less those who actually managed to prove that.

[corremn]

It's notable that there have been professional programmers who claim how easy a roguelike is to do, but less those who actually managed to prove that.

However good game design has nothing to do with being a professional programmer.

[Jotaf]

My plan currently consists of a vision of the type of game I want, and not much else. This has got me much further than the previous 50 grand schemes of world domination I once had a great plan for an RPG that consisted of more than 1mb of pure text. All of the features were pies-in-the-sky though. No RAD could ever have done THAT.

I keep a "to do" list but most importantly a "done" list, for motivational purposes It was suggested to me recently and I love it. Periodically I take some items out of the "to do" box and into the "maybe" pile; things that seemed nice at the time but now have grown old and I don't feel like implementing them.

This is all for fun so most of what I do, I do it for the fun of it -- the journey matters, not the end result. The main criteria for selecting the next thing to do is how easy it is to implement and how fun I think it is for me to code. And so I've been ticking items off my to do list like crazy.

A great factor here are the tools I use. Dev in Python is waaay more rapid than in Java, which in turn is moderately more rapid than in C++. RAD methodologies can only get you so far. In Python I can pass lists and dictionaries all over the place without breaking a sweat. And then there's the doryen RL library, which has easy true-color console display capabilities and every RL algorithm you could possibly want. A powerful combination.

So, as you can see, we all know how to pump code like crazy. It's just that, contrary to intuition, RL dev is pretty hard for a one-man army.

[damakun]

hmm - great responses, guys. I figured that a solo Rouge would take up to as much time as a solo RPG, but with much more replayability (which is the attractive feature for me; nothing like slaving away at something that people finish in a few hours and get bored with....) I have a better idea of how to proceed. I forgot about Python and will take a closer look.

One other quick question : is planning in rougelikes sophisticated enough to say how long the game will take ? Say, is there a way to plan on one hour vs. 10 vs. 40 ?

[PaulBlay]

I forgot about Python and will take a closer look.

There are quite a few roguelike games in Python.

http://roguebasin.roguelikedevelopment.org/index.php?title=Python#Roguelike_games_in_Python

Might be worth checking them out.

[Jotaf]

The duration of a game is entirely up to the dev, usually by changing the number of levels. Of course, if there's not enough interesting content in your game, it should probably be kept to a few levels; but as you grow more content it might make more sense to also have many levels.

You can always force it to be a coffe-break RL (like DoomRL and others) by reducing the number of levels; but these games also feature a less steep learning curve and overall simpler mechanics than the big RLs. Of course that part can be planned in advance

The unpredictability of the RNG doesn't lend itself well to the "hours to finish" measure -- that's ok for rollercoaster rides like the commercial games, but when you factor in the perma-death and the replayability you can't really just put a "40-hours of entertainment" stamp on it

[magellan]

you can't?
I mean, sure. the game where that kobold killied you on level 1 was shorter, but most completed games (of the one roguelike i managed to complete: ADOM) took approximately the same amount of time.

[Darren Grey]

One other quick question : is planning in rougelikes sophisticated enough to say how long the game will take ? Say, is there a way to plan on one hour vs. 10 vs. 40 ?

Generally roguelike development is incremental, such that you'll start with a 5 hour game and a few years later it'll be a 20 hour game after you've added more and more features and locations etc.  Roguelikes generally aren't too long (average major RL takes around 10 hours to complete I'd say) to encourage replayability.  Personally I'd worry about anyone that plans to make a game a specific number of hours long, unless they're deliberately aiming for a very short timespan (like a coffeebreak).  Gameplay length should arise naturally from the content, and you shouldn't be throwing content in just to make the game longer - content should only be added to make the game more fun.

[Gamer_2k4]

Okay, first rule of roguelike development:
It's "Rogue," not "Rouge."

(Someone had to say it.)

[damakun]

Okay, first rule of roguelike development:
It's "Rogue," not "Rouge."

(Someone had to say it.)

lol, I will definitely have to put in some Moulin Rouge references in my roguelike...

[Anvilfolk]

Okay, first rule of roguelike development:
It's "Rogue," not "Rouge."

(Someone had to say it.)

Thank you

I can't really contribute as I haven't developed a roguelike. When I do (heh), I'll probably spend some time developing a very basic architecture that I think will be flexible enough for several types of things. There should be SOME analysis/thought going into it before starting to code, as far as I'm concerned. That's how I tackle most projects.

[kurukku]

Just slightly OT:

Is RAD anything new? (I even never heard the abbr) For me, as a non-professional programmer, it seems like most projects outside the commercial world are done incremental. And actually I guess in the commercial world, too.