Chaosforge Forum
DoomRL => Discussion => Topic started by: Kornel Kisielewicz on June 17, 2007, 06:14
-
I have no idea how good of a coder he is. He's keen on gamedesign, thats obvious. Somehow i just cant see roguelikes as a pinnacle of coding...
Actually roguelikes are a quite challenging thing to code, especially in the randomness department. Coding a RPG/Shooter/Strategy is much easier :/.
-
Coding a RPG/Shooter/Strategy is much easier :/.
I wouldnt say that...especially in the case of commercial products. I am in the game-making team now.
It takes A LOT of time to wade through someone else's graphics engine, for example.
Various hardware compatibility...
Creating AI for A-class shooter is no easy task either...
Physical engines arent that common yet, but will become a requirement soon...
-
DooMRL is very stable. It have some glitches, bugs, exploits, but they are not deadly, it crashes totally very rarely. For me good coder is not the one who have written overmoded unstable code, but the one who have written a little less moded, but stable code.
I don't mean to disrespect Kornel's work, but DoomRL isn't by far as stable as you're saying. There's been a lot of improvement, but the game used to crash on many occasions.
Actually roguelikes are a quite challenging thing to code, especially in the randomness department. Coding a RPG/Shooter/Strategy is much easier :/.
I agree that coding a roguelike is more challenging than might appear from the result. Most people seem to think that a text-based application is necessarily simple to code. Randomness (level/monster generators) and LOS/pathfinding/AI are tricky subjects. Nevertheless I think you're vastly underestimating the development of RPG/FPS/RTS. Randomness in RLs has its complications, but there's also lots of things you can disregard in a roguelike, especially graphics, controller support, real time processing and multiplayer support, and usually sound support - unless you're coding DoomRL of course. ;)
-
I don't mean to disrespect Kornel's work, but DoomRL isn't by far as stable as you're saying. There's been a lot of improvement, but the game used to crash on many occasions.
Mmm. Yes, 0987 crashes sometimes, but in Beta all known crashes was fixed. At least i don't know now how to crash it, i have played a lots of games, and it haven't crashed.
-
Coding a RPG/Shooter/Strategy is much easier :/.
I wouldnt say that...especially in the case of commercial products. I am in the game-making team now.
So am I ;].
It takes A LOT of time to wade through someone else's graphics engine, for example.
Various hardware compatibility...
Depends on the engine quality. Commercial engines are usualy a lot better documented than their OS counterparts.
Creating AI for A-class shooter is no easy task either...
Compared to behavioral AI with danger-aware pathfinding for a roguelike? xP
Physical engines arent that common yet, but will become a requirement soon...
Physics engines (I guess you're refering to those) ARE a requirement since about late 2005. They aren't as scary as they sound though. And most people use existing engines anyway.
DooMRL is very stable. It have some glitches, bugs, exploits, but they are not deadly, it crashes totally very rarely. For me good coder is not the one who have written overmoded unstable code, but the one who have written a little less moded, but stable code.
I don't mean to disrespect Kornel's work, but DoomRL isn't by far as stable as you're saying. There's been a lot of improvement, but the game used to crash on many occasions.
I have to agree. It's mostly due to the fact that the core engine was hacked together, and never was meant to be released.
Actually roguelikes are a quite challenging thing to code, especially in the randomness department. Coding a RPG/Shooter/Strategy is much easier :/.
I agree that coding a roguelike is more challenging than might appear from the result. Most people seem to think that a text-based application is necessarily simple to code. Randomness (level/monster generators) and LOS/pathfinding/AI are tricky subjects. Nevertheless I think you're vastly underestimating the development of RPG/FPS/RTS.
I'm not ;). Actually the biggest problem with those games is content creation. Just look around on the thousands of projects that have been created that died ONLY because the lack of content. Roguelikes on the other hand have a way to cheat that problem -- they create content themselves. But that thing is realy NON-trivial, so that's why most roguelikes fail.
The biggest trick is NOT to generate content. It's to generate PLAYABLE content.
-
I agree with what Kornel napisaled... developing a roguelike is hard, not only because of its randomness/LOS/pathfinding/AI, etc algorithms and technical challenges, but because of generating playable, interesting and balanced content, tasks which are often underestimated by the fellow roguelike developer which thinks he has the next major game on his pockets.
Also, injecting a theme into your players using a limited symbol set is an interesting challenge.
-
Depends on the engine quality. Commercial engines are usualy a lot better documented than their OS counterparts.
Documentation is good, but it is still a great deal of work to make it serve YOU, to do what you want, instead of what the "stock" version does. And writing a modern graphical engine yourself is not exactly best way to spend your time, these days.
Compared to behavioral AI with danger-aware pathfinding for a roguelike? xP
Never seen any kind of "danger-awareness" in any roguelike...come to think of it - retreating enemies and the like are rarely seen altogether, and usually proclaimed as a key feature of a game.
Physics engines (I guess you're refering to those) ARE a requirement since about late 2005.
Only for A-class shooters. Not really for any other genre. People are reluctant to use even something so old and simple as "Havok".
Most people seem to think that a text-based application is necessarily simple to code.
Mostly because it is. However, roguelikes are not text-based applications. :)
Text-based game would be called Interactive Fiction. And those are very simple to code.
The biggest trick is NOT to generate content. It's to generate PLAYABLE content.
I never said anything about content, my point was about coding skill.
-
Does it really make sense to try to start a pissing contest about what/where/when/how/why code works with someone who might otherwise be spending that time cooking up a new public release?
I'm surprised that there hasn't been a barrage of flames from people without beta access already.
All I can say is mad props to anyone who spends their time working on games for free. I know I don't have the time to do that anymore...
-
Actually the biggest problem with those games is content creation. Just look around on the thousands of projects that have been created that died ONLY because the lack of content.
Although the latter is very true, I can't get my head around the idea a 3D graphics engine would be 'much easier' to code than a random level generator for a roguelike.
Roguelikes on the other hand have a way to cheat that problem -- they create content themselves. But that thing is realy NON-trivial, so that's why most roguelikes fail.
Content generation is a major challenge for roguelikes as much as any other game. Roguelikes imo don't actually create content themselves, they arrange content themselves. It is possible to build a pseudorandom content generator which produces random monster types, random terrain types and the like, but I'm not aware of any RLs so far that actually do that.
The biggest trick is NOT to generate content. It's to generate PLAYABLE content.
Also, very true. But the point you made about 'difficulty' was about coding, not about content generation.
developing a roguelike is hard, not only because of its randomness/LOS/pathfinding/AI, etc algorithms and technical challenges, but because of generating playable, interesting and balanced content, tasks which are often underestimated by the fellow roguelike developer which thinks he has the next major game on his pockets.
I agree. Developing a RL engine is much easier than developing a RL itself. But again, this difficulty is inherent to game design, not to code complexity.
Most people seem to think that a text-based application is necessarily simple to code.
Mostly because it is. However, roguelikes are not text-based applications. :)
Text-based game would be called Interactive Fiction. And those are very simple to code.
Now don't be pedantic. ;) You know I meant to say 'text mode application'. Your point was that RLs are relatively easy to code. The fact that IF is (usually) easy to code doesn't support that observation. My point was that lack of graphics often leads people to believe that an application is easy to code, where (especially in the case of RLs) they often disregard the complexity of level generators, AI, pathfinding, etc, either in terms of code or in terms of processing. Which isn't the same as saying that RPG/RTS/FPS are easier to code than RLs. They're not.
-
Your point was that RLs are relatively easy to code.
No. My point was that some people think that a roguelike developer is THE 1337 h@x0r, who thinks and talks in assembler with his peers, and the like.
-
Physics engines (I guess you're refering to those) ARE a requirement since about late 2005.
Only for A-class shooters. Not really for any other genre. People are reluctant to use even something so old and simple as "Havok".
For FPS, FPP/TPP RPGs, space-sims etc, they're a must have now.
Text-based game would be called Interactive Fiction. And those are very simple to code.
Sure you can use an existing IF engine. But try to code a reasonable and PLAYABLE natural language parser, and you'll see that even IF has it's caveants :P
I never said anything about content, my point was about coding skill.
Contrary to other games, in case of roguelikes, or procedural content in general, the coding skills are stricte needed for better content.
-
Alright kiddies, that's enough of off-topic. The posts about game programming that didn't bring anything to Chaingun>Shotgun topic were split. You might continue the discussion here.
For the Inquisition!
-
What?
Picking between a Chaingun or a Shotgun is of utter relevance if you want to develop a serious game; we live in a dangerous world.
Or maybe not.
-
I've been in a few game-making teams, and it's disheartening to see people arguing about whether someone is a better coder because they work on graphical 3D games or roguelikes. To me, a good coder is the one who gets good work done. Some are more experienced than others, some write code at a faster rate, some write cleaner and more readable code, some write more stable code, some have better problem solving skills, some have more mathematical knowledge, some have more knowledge of advanced algorithms, some are better at working near the hardware level, some are better at making critical engineering decisions - all these things and more are factors. For modern AAA games one good coder is not enough, even if it's John Carmack, and even if you have the Unreal 3 engine to work with. You need a whole team of good to great coders, who work well together, or you won't get a good result in a realistic time.
Programming a fully playable standalone game in under 7 days tells me that Kornel is at least a good coder, maybe a great one. But that doesn't really matter, it's the design skill that goes into his games (well... AliensRL at least) that make me play them, and thus join this forum. Which is as it should be, IMO. After all aren't Roguelikes supposed to be all about the design, by imposing very simple and restricted graphics to work with?
-
My point was that some people think that a roguelike developer is THE 1337 h@x0r, who thinks and talks in assembler with his peers, and the like.
Some people think that bragging on forums insulting works of others, and being able to type some magic words like "graphics engine", "havok", "assembly" makes them THE 1337 h@x0r
-
No. My point was that some people think that a roguelike developer is THE 1337 h@x0r, who thinks and talks in assembler with his peers, and the like.
Some people think that bragging on forums insulting works of others, and being able to type some magic words like "graphics engine", "havok", "assembly" makes them THE 1337 h@x0r
Both of your arguments are straw men and you need to get over yourselves.
I've been in a few game-making teams, and it's disheartening to see people arguing about whether someone is a better coder because they work on graphical 3D games or roguelikes.
This topic is about someone's qualities as a coder? I mistook it for a discussion about the difficulties of coding RLs. My bad.
-
Yay, first ChaosForge forums flamewar ^_^
-
I have no idea how good of a coder he is. He's keen on gamedesign, thats obvious. Somehow i just cant see roguelikes as a pinnacle of coding...
Actually roguelikes are a quite challenging thing to code, especially in the randomness department. Coding a RPG/Shooter/Strategy is much easier :/.
The pinnacle of coding? If you're talking about the "pinnacle" of coding and discussing genres, you've already hurt whatever argument you're going to make afterwards. A good coder, like any other discipline, is someone who can take the job placed before him/her and get it done efficiently, regardless of what the job is.
Kornel has accomplished an incredible feat in that he has made multiple Roguelikes, all of which are extremely playable. He obviously has a keen eye for game design and whether or not he's John Carmack as a programmer, he gets the job done. They are extremely enviable traits that not many people have... the power to be creative and also the ability to create. Not only that, but he does so alone.
I don't mean to disrespect Kornel's work, but DoomRL isn't by far as stable as you're saying. There's been a lot of improvement, but the game used to crash on many occasions.
Wow, software that crashes before it reaches v1.0? Incredible! ;)
Honestly, show some respect for the author of the games you play on his own forum and do not question his skill as a programmer when it's completely irrelevant. Working with a big company you have the security of being on a team and being anonymous... if the game is bad or runs poorly you can blame it on somebody else. Kornel, on the other hand, is making public personal work of his that he worked on alone and he does not have that kind of security. Don't take advantage of it by insulting him and his work.
And I'm stepping into this discussion/flamewar rather late, so if I've said anything that's already been said, I apologize. ;)
*ducks back into hole*
-
P.S. Kornel has gigantic, brass balls and the fact that he hasn't bant us all for heresy is a testament to his greatness as a man. ;)
-
A good coder, like any other discipline, is someone who can take the job placed before him/her and get it done efficiently, regardless of what the job is.
Uh, yeah, right. "hello, world" - anyone ?
If you're talking about the "pinnacle" of coding and discussing genres, you've already hurt whatever argument you're going to make afterwards.
No, i dont think so. I just happen to know the specifics of working on said genres, while you do not, thats all.
Honestly, show some respect for the author of the games you play on his own forum and do not question his skill as a programmer when it's completely irrelevant.
My guess is that in your mind "Bug Reports" subforum is a HUGE disrespect, am i right or am i right ?
-
Yay, first ChaosForge forums flamewar ^_^
>_>; Are you really sure this is the kind of thing you want to mark as a milestone? ...:P
-
A good coder, like any other discipline, is someone who can take the job placed before him/her and get it done efficiently, regardless of what the job is.
Uh, yeah, right. "hello, world" - anyone ?
I'm sorry, but Derek is right on the money here.
Karry, your argument seems to boil down to this: games in some genres are more complex, therefore people who work on them are better coders. I would agree that some genres require more resources to complete, but not that they require better programmers. I would also even maybe agree that some genres also require more outside knowledge (physics, math, AI, networking, hardware, graphics, etc.), but working on tasks that require them don't make people better programmers either. That sort of experience and knowledge is orthogonal to being a good programmer.
(BTW: Does anybody else but me feel like coder is a pejorative word or at least a bit myopic? Saying coder is like calling an author a wordsmith. There's way more to writing than just pen to paper.)
-
(BTW: Does anybody else but me feel like coder is a pejorative word or at least a bit myopic? Saying coder is like calling an author a wordsmith. There's way more to writing than just pen to paper.)
Yeah... I prefer the much more sophisticated term: "Developer" :P
Anyhow...I don't want to hype the difficulty of developing a roguelike compared to another genres... it is an entirely different endeavour; development and game design skills are fuelled by willpower instead of money when you develop this kind of games.. thus, profficience in programming is on a secondary layer when compared to willpower and capacity to complete playable products.
Also, I think that's one misconception of you Karry... roguelike developers are not commonly perceived at DA 1337 h@x0rs.... In my opinion the common perception is of a dreamer developer fighting (commonly alone) against the tides of modern gaming,
-
I've been in a few game-making teams, and it's disheartening to see people arguing about whether someone is a better coder because they work on graphical 3D games or roguelikes.
This topic is about someone's qualities as a coder? I mistook it for a discussion about the difficulties of coding RLs. My bad.
My bad, although it did seem to have degenerated into "who is more l33t" at one point.
Anyway... I think I agree with most posters on this thread except for Karry. Roguelikes have their own set of difficulties and not all of them are to do with programming. Lone wolf developers who produce anything good are worth a lot of respect, especially so if they give it away for free and develop a community around it. And procedural content generation is a technical and design Holy Grail for games, which most commercial developers shy away from due to its difficulty, even while they are putting complex graphics and physics engines into their projects... so a Roguelike isn't just a "hello world" project by a long shot. However I do think that the poster above who pointed out that roguelikes arrange content procedurally more than they generate it has an excellent point. I don't know whether I agree with that or not, I would say it depends where you draw the line to say what is "content".
Also, to me "coder" is just a shorter way to write "programmer" :) "Developer" is more all-encompassing though.
-
For me, the "pinnacle of coding" is definitively Frontier : First Encounters. And this is the "Castle in the Sky" (Berserk fans - pun intended) that I'm aiming at.
If you're talking about the "pinnacle" of coding and discussing genres, you've already hurt whatever argument you're going to make afterwards.
No, i dont think so. I just happen to know the specifics of working on said genres, while you do not, thats all.
I rarely write anything negative about posters on my forum, but with this quote you've made a fool of yourself Karry :). Yet, it made me laugh, so kudos for you, and please don't feel offended -- negative comments are always welcome too :).
As for "coder". Maybe it may sound negative. I always liked the term "developer" more anyway.
My main point with the whole "programming hardness" discussion -- imagine a roguelike. Imagine a space-shooter. Frontier is what happens when you move the roguelike philosophy into the space genre. Coding a frontier-like is a LOT harder than a normal space shooter. And this jump in hardness is *A LOT* bigger than jumping from "ASCII graphics" to "nice graphics".
Thanks Derek for your voice in the discussion - it means a lot to me :).
-
And, as something "out of the blue" in this discussion, a screenshot of "something" that happens on my HD recently :
(http://chaosforge.org/files/sd_ss_7.png)
-
Wow, software that crashes before it reaches v1.0? Incredible! ;)
That was my response to the observation that "DoomRL is very stable". I never said that DoomRL was supposed to be stable. Crashes and bugs are inherent to the development process, and I think Kornel's doing a great job at developing the game.
Honestly, show some respect for the author of the games you play on his own forum and do not question his skill as a programmer when it's completely irrelevant.
I hope this wasn't aimed at my quote in particular, because it's as irrelevant to the discussion as the "1337 h4x0r" comments.
Karry, your argument seems to boil down to this: games in some genres are more complex, therefore people who work on them are better coders.
I agree, though I think you failed to capture the acidic overtones. ;)
Does anybody else but me feel like coder is a pejorative word or at least a bit myopic?
I don't think so, but I'm not a native speaker of English. Coding equals programming in my vocabulary.
Anyhow...I don't want to hype the difficulty of developing a roguelike compared to another genres... it is an entirely different endeavour; development and game design skills are fuelled by willpower instead of money when you develop this kind of games.. thus, profficience in programming is on a secondary layer when compared to willpower and capacity to complete playable products.
I agree. I've made several attempts at developing a roguelike, but never managed to release one. The critical point where I seem to get stuck every time isn't technical at all. After I've made a nearly complete framework, including text/map displays, level generators, collections of monsters and items, LOS, FOV, AI, file I/O, basically the game engine, I get stuck at creating content and storyline. I used to think it was something I just wasn't very good at, but the same problem seems to haunt several unfinished RL projects. Actually finishing a roguelike does require a lot of willpower and creativity, and has little or nothing to do with being a decent programmer -- or perhaps you could say I suck as a developer.
And, as something "out of the blue" in this discussion, a screenshot of "something" that happens on my HD recently
OMG that looks so much easier than your roguelikes. ;)
Nice way to make a point though. (y)
-
Hmm, I go away for a (big) while and when I come back I find everybody took out their Heavy Flamers...
Anyway, on this "omg i r l33t3r then u lol" discussion, I think coming up with a playable game is a great endeavor who many people do not manage to accoplish. Whether this game is a RL or any other kind of game is fairly irrelevant, because if you are doing something people are enjoying playing, it means you are a successful developer (because to develop a game there is much more than coding, I think).
Yes, I do not know the intrincacies of any genre, as I have never programmed a game myself (although I plan to start a project soon, if everything goes well), but I guess every style has its nitpicks. And, from a "perceived complexity" point of view, I think RLs might perfectly be among the most complicated games there are. I know lots of failed roguelikes, be it for the lack of content or gameplay, and so coming up with a successful one is no easy task, I think. The sheer complexity of interactions which most of this games show is far beyond what other games show (although that other games might have graphics, realistic physics or whatever). Right now I cannot think of a commercial game which so much detail as Nethack, for instance.
This, however, does not mean I think coding other kind of games is "easy": as I said, every genre has it peculiarities, and another genre, like maybe 4X strategy, might perfectly be "harder" to code than a roguelike. However, I do not think a generalization like "X genre requires more programming skills than Y" is a valid argument, as the ability to come with a *good* game is which is difficult, from my point of view, and not merely reaching a playable state.
Sorry if any of this has already been said, I just wanted to make my point. So thumbs up for all the developers out there which provide us games (preferably if those games are both free and Linux-compatible :P), it is a task I admire a lot ;).