Discussion on game development

[Kornel Kisielewicz]

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 :/.

[Karry]

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...

[Rabiat]

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. ;)

[Blade]

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.

[Kornel Kisielewicz]

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.

[Santiago Zapata]

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.

[Karry]

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.

[Behrooz Wolf]

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...

[Rabiat]

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.

[Karry]

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.

[Kornel Kisielewicz]

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.

[Malek Deneith]

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!

[Santiago Zapata]

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.

[Newts Revenge]

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?

[Aerton]

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