Temple of The Roguelike Forums
Development => Programming => Topic started by: damakun on April 13, 2009, 07:12:41 AM
-
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 !
-
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
-
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.
-
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.
-
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.
-
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.
-
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 ?
-
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.
-
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 ;)
-
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.
-
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.
-
Okay, first rule of roguelike development:
It's "Rogue," not "Rouge."
(Someone had to say it.)
-
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...
-
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.
-
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.
-
Hey guys!
Im just on here to get incentive, you see I just got futher in developing a roguelike than I did last attempt a while back and I have a basic working AI(Im most pleased with this as they way Ive done it , it should work for any created monster and doesnt matter where in the map its placed) as well as load and save features plus static maps, anyway before I went further I felt since I built this roguelike from the gound up using C++ that I would start migrating it to OO, tbh it has slowed me down majorly but some parts of the code look more neat , conversly other parts it works but seems cumbersome. (I hope I havent made a mistake by migating to OO but the reason I did this was because it was getting to the point that say I came back 6 moths later or anyone did well it was becomming a code maintenance nightmare (Even though everything worked fine)
Im actually speaking to a guy via mail that has previously made one of the roguelikes mentioned on the wiki, the guy has been a billiant help and is total down to earth.(His code is eally readable and elegant, these are words banded about but looking at this guys code has helped me realise I could finish a rogue , granted not anywhere near his standard but to a standard I would be hapy with) Whats stopped me progressing with a roguelike until know is believe it or not because I read lots of stuff on planning , OO paradigms , polymorphism and all that jazz and when I wasnt coding fom the outset well enough to be adhering to all peoples coding pet hates mentioned on the web and in books , well I would stop my poject and give up thinking my coding wasnt up to scratch. (However this time arround by speaking to someone who has really done a roguelike hes been really helpful and has stressed to me not to look for that 100% semantically correct code , because it doesnt exist in real terms! This mentality has helped me once I finally started believing it since I started out with this totally dumb system for a roguelike :) however I got it working and through that and all the error checking that goes along with doing code well I learned from it and I am just starting to reap the rewards in that parts of my code I am feeling happier with.
I have also been given some pointers as to what to read pertaining to random dungeon generation should I decide to go that way. In all this the point I am making is just go for it and learrn fom the experience and also I want to quote something which has given me more incentive from this thread:(Theres a guy helping me who holds pretty much the exact same view as the below quote and has actually written and maintained a succesful rogue)
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.
As for the OO part thankfully the guy Im speaking to has told me various things not to do with OO to stop me getting bogged down in OO semantics of use but as Im using it I am also cautious since I know I would be at the point of doing my questlog code by now if I hadnt done a rewrite however my heart of hearts tells me its for the best.
With regards to these people who say roguelike dev is easy , well Im really glad you brought that up :) Its just I have programmed for about lets see 8 years now, not long and have coded in many languages as opposed to one specific one, Im no guru but I think its plain wrong to say roguelike dev is easy, for example take the amount of people out there who are saying they program plus roguelike dev is easy then why is there not hordes of roguelike games out there which surpass the major ones that were made when lets be honest I personally think at that time things were quite so high level and not as much technology and infomation out there to help so hats of to the creators of adom and older rogues
As for planning considering people that havent finished a roguelikee project well I think to plan effectively you need to understand the problems and to undestand the problems its a slog at times
Read books
have an idea
do the simplest chunk of your idea - in code (TEST test test)
error check
do reading on what you ae trying to achieve
rinse repeat for other parts
At this point you have probably learned a mammoth amount from actually coding and referencing reading amterials but by now you realise your codes quite messy so rewrite
.......
The above is probably seen as very very bad but I hold the view that once you have went though all that dodgy code and have followed through on a project (All be it shoddy) you now know many of the problems and on you next roguelike you are therefore in a position to plan and actually benefit from it (Probably get shot for this mentality but I have tried it the planning way and its not as if I dont follow how to read c api docs its just I have benefitted most by getting my hands dirty to misuse a phrase :D as well as being lucky to have someone who I can show code to and he gives me really general but great hints/advice as to the pros cons of what I have done - I have also been on a pre degree course in my country (HND) where we did textual analysis and uml and quite a bit of java coding, learned alot but once again its no substitute to getting and learning through coding , since when you plan without knowing coding orr coding implications of what you do your going to have this beutiful document and then to your horror realise, DAMN! now how in the heck! do I code this)