Temple of The Roguelike Forums
Development => Programming => Topic started by: guest509 on April 22, 2012, 06:19:17 AM
-
Like many game making enthusiasts I have about a billion and one little ideas I'd like to implement. Often, when jotting things down, I will discard systems and even entire game ideas because they are beyond my ability to implement.
We all cut things out of games because they do not fit the design or because they are just bloated and do not add to the fun factor. How often do we cut out fun stuff do to difficulty of implementation?
I realize some things have to be cut. 3D graphics and ports to X-Box, for example. But what about other things that could be done but are just difficult. So we ditch the idea and go an easy route.
Here's the examples that got me thinking on this:
Jumper RL - I had some ideas for a multiplayer platformer. Jumper Engines are pretty easy to find and copy, my main creative job would be making the randomized levels. Spelunky did this pretty well and the procedural generation wiki has some papers on the topic. The issue: hard to implement. Top down levels lend themselves to procedural generation because it's the content of rooms that are most important. In a platformer it's the terrain itself that is important. I could copy the Spelunky method and come up with a pretty cool game, but it'd be hard. Much harder than a top down game...
HeroRL - A traditional multi genre RL where each selectable level is styled according to a certain genre. So you can take your cowboy hero into a space station, your mage into a western tavern, etc... The issue? COMPLEXITY. Sure, it's a good idea for a game. But goddamn, just creating the system, even if stolen from GURPS or something, is just HARD.
A counter example is my woefully behind schedule Cardlike v2.0. I've dropped the map system just because it would add more fiddliness for little fun factor, and it conflicts with some of my other design goals. This is NOT a decision based on difficulty of production, it's purely a design decision.
So I guess my question is how commonly do you choose ease of implementation over the 'fun factor'? Secondly, is this a bad thing? I mean, if it's too hard to implement at some point we don't have any games, or we get tons of half finished ones.
-
This is really the question with roguelikes. Simple ones are easy enough to implement, but if you try to step any further it will become much harder. I have good experience from Teemu (one of my roguelikes) where the first version was quite easy to do, because I kept things simple. Now version 1.3 is still under development, because things got just a little bit more complex.
I think the answer is good, solid engine with small start. Then add features one by one. But who ever does that.
-
I would love to play this HeroRL idea you mentioned.
-
So would I Legend... ;)
-
Wait- what's your problem?
Are you having trouble designing the rules of your game, or programming it?
-
HeroRL - A traditional multi genre RL where each selectable level is styled according to a certain genre. So you can take your cowboy hero into a space station, your mage into a western tavern, etc... The issue? COMPLEXITY. Sure, it's a good idea for a game. But goddamn, just creating the system, even if stolen from GURPS or something, is just HARD.
There was a game where you were able to do crazy things like that... It was called Civilization. If Mr. Meier could do it in 1991, then you can do the same (only better) in 2012. Maybe it's not that complex. Or should I say: not much more complex than writing an usual roguelike ;).
-
Wait- what's your problem?
Are you having trouble designing the rules of your game, or programming it?
There is no problem. It was a question. Asking how often people go for ease of implementation over fun factor.
As far as civilization, was that made by a solo hobby developer? I am pretty sure Sid had a team of pros.
-
Wait- what's your problem?
Are you having trouble designing the rules of your game, or programming it?
There is no problem. It was a question. Asking how often people go for ease of implementation over fun factor.
I don't see how the two are mutually exclusive. 3D and ports to x-box, for example, are now one-man jobs.
You described HeroRL being complex and hard-- Is it complex because your rules are difficult to implement or because you haven't decided on how the rules fairly and appropriately represent your idea/objectives?
Basically- I'm asking what your question is asking-- is it asking it from the point of view of a game designer or from a game programmer?
There are 4 branches of game development--
Production/Game Design (rules, story, gameplay)
Software Development (tools, shaders, mechanics, physics, engine)
Asset Development (art, music, models)
Level Design (scripted events, areas, gameplay implementation)
Procedural generation lets us cut out or greatly reduce our need for Assets and Levels. The only two things a roguelike developer needs to think about are design and programming (including the emulation of level design and, if necessary, assets).
Is your question one of design, or one of programming?
Typically- a designer has a certain set of objectives they wish to accomplish in regards to how they effect the player. The programmer develops a paradigm, or set of features, necessary to accomplish these tasks as simply as possible. It is the designer's job to determine what the mechanics are- what stats each creature has, how combat is handled, and everything else that matters. The programmer just finds a way to implement it.
Complexity exists relative to one's perspective of a problem- Is an idea too complex to describe the rules or are the rules too complex to program?
In my personal opinion, if the rules are well-defined then there isn't really any problems when it comes to implementation.
-
In my personal opinion, if the rules are well-defined then there isn't really any problems when it comes to implementation.
I guess it depends on what you mean by "rules" but I completely disagree with this statement. Take for example a 3d engine. A rule might be that the player should see only the objects in view and not the objects that are, for example, behind walls or out of view. This rule is obvious, however it is not exactly trivial to make it work (and be efficient). Of course you can look up how professionals do it, but obviously even if you know all the "rules" writing your own 3d engine is not something that comes without 'really any problems'.
A designer might say "enemies track down the player". This is once again a really simple design rule, but implementing it is not trivial. Of course nowadays most people know about A* or some other algorithm, but it's still something that can cause a lot of problems and something I often see that is bugged up in games.
I think unless you are a programming god you are going to run into issues and unexpected difficulties in almost anything you implement, unless it's trivial. I'm not sure how you can think there are few problems implementing a rule set, because there is quite clearly an immense difference between a design document and a finished game.
You do make a good point though, in that most things are harder to design than to implement. In the end, assuming you can program worth a damn, it comes down to how good your design is in terms of whether or not a game is "fun".
-
Let's assume, for just an instant, that we are on a forum full of people that develop games as a hobby. How often do you cut out fun stuff, or discard ideas, because it would be hard to implement? I tend to discard a ton of stuff because I lack the programming skill or the years of time it would take to implement it. That's part of why I went back to making card games for awhile.
I wish I lived in the fantasy world where design was harder than implementation.
Here's a design. Modern Warfare 3, the Roguelike. It'll be epic! A tried and true design. So Req', now that all the hard work is done when can I expect the game? Feel free to illustrate my point, and my question, by actually trying to answer that silly question.
-
Yea, that was a stupid thing to say.
I definitely misused the word 'problem.' The most important quality of a programmer is stubbornness- The assumption that with continued effort any problem can be solved. The persistent belief that one is always good enough to solve any given problem will inevitably result in a solution for the problem being found (unless the sun burns out first).
In this vein- most of the 3d problems have been solved and packaged into libraries that are easy to use. The developer just needs to brush up on the literature and pick tools appropriate for the job.
Even if you're going to program a 3d engine from scratch-- mesh loader, input handler, frustrum culling and a scenegraph aren't particularly difficult problems. Ignorant of 3d concepts, I don't think an experienced programmer would have trouble figuring the basics out. Tutorials and literature is plentiful... or you can just use unity, ogre or flash3d.
That said- A designer should not concede design for programming difficulty- ever. It's the programmer's responsibility to interpret the design and implement it in a progressively functional manner.
If the design objectives revolve more around the effect of gameplay on the player instead of gameplay being a particular way, the rules tend to be more easily reduced in a way that doesn't cause problems for the programmer. If a designer says, "I want to make the next mmocrpgfps of awesomeness" and works toward that specific goal, it's going to suck for a programmer. Any story could be told in a number of ways, picking the most appropriate, concise, and interesting ruleset makes for easy programming.
-
Let's assume, for just an instant, that we are on a forum full of people that develop games as a hobby. How often do you cut out fun stuff, or discard ideas, because it would be hard to implement? I tend to discard a ton of stuff because I lack the programming skill or the years of time it would take to implement it. That's part of why I went back to making card games for awhile.
I wish I lived in the fantasy world where design was harder than implementation.
Here's a design. Modern Warfare 3, the Roguelike. It'll be epic! A tried and true design. So Req', now that all the hard work is done when can I expect the game? Feel free to illustrate my point, and my question, by actually trying to answer that silly question.
Lol, okay- sure.
Modern Warfare 3, the Roguelike-- just aesthetically mod DoomRL. Done!
Let me ask you-- How many of your ideas do you actually develop to the point at which they're ready to implement? What I'm getting at here is that the discouragement in designing something tends to not involve implementation, but fleshing out a truly complete concept.
If you have a complete design for a game, I would be happy to try and implement it... y'know, if I found it inspiring and all.
-
I think it is really important as a game developer to implement the things you think might be too difficult or unwieldy. It's just like fighting a hard monster in a roguelike. It might be a little rough, but you'll gain a whole bunch of exp and loot!
Personally, I would say that I really never exclude something due to implementation concerns. I change my priorities in this way (for instance I usually add trivial things that I have done before early on), but I wouldn't disregard a feature. The thing is that you should be convinced of why something should or should not be in your game, and when you are convinced you can no longer throw it out. In some sense I think a lot of this depends on how much of a designer vs. a programmer you are. I really enjoy game design, but I also love programming. It is just as fun for me to implement a new system as it is to design that system.
Keep in mind that it is possible to be a designer and not a programmer, just look at david ploog with dcss. Either way, you should be uncompromising. Try to separate the designer and the programmer within yourself. The designer should give mandates that the programmer should execute.
-
I think it is really important as a game developer to implement the things you think might be too difficult or unwieldy. It's just like fighting a hard monster in a roguelike. It might be a little rough, but you'll gain a whole bunch of exp and loot!
I like this!
-
What I'm getting at here is that the discouragement in designing something tends to not involve implementation, but fleshing out a truly complete concept.
I've found it to be just the opposite. But we could be talking about different things.
-
It's the programmer's responsibility to interpret the design and implement it in a progressively functional manner.
The design or plan should always be complete before it can work even in theory. One of the major problems is that the design is not complete (not detailed enough) or it has a flaw and it doesn't work when it's implemented. I think design/planning is the least known and mastered aspect of game programming, maybe because it's the worst part of it: Create a complete design and stick to it? No thanks, I'll just come up with something and see what happens.
-
There are plenty of things that are easier to design than to implement.
There are plenty of features that even harder to design properly, so they will be fun, not just complex and boring.
About the question - I often cut potentially funny features if their implementation seems too difficult. The problem is that I often don't look at their ideas. I'm sure that creating interesting multiplayer platformer with procedurally generated levels (such as described JumperRL) is very difficult, so such idea won't come in my head.
I'm sure that creating interesting MMORPG (roguelike or not) is just impossible, so i won't even try.
I won't try to create roguelike with detailed battle system, complex body parts and material system, just because I'm sure it won't be fun without some "spark" in design.
Well, even creating something like ADOM or Angband, creating pure roguelike without "twist" seems impossible to me, because such roguelike will be boring. So in my projects I always use an additional ideas, e.g. unusual setting or battle mechanic - I'm not sure that i can create something interesting without them.
-
I come up with new ideas and discard most of them in regular basis. Sometimes they don't fit to the theme of the game, sometimes they're hard to design well and sometimes they're too hard or laborous to implement. I'm deliberately not writing huge and detailed design document before writing code, because I believe that well planned is never implemented. Rather I like to design and implement one thing at a time, discarding and editing things as the design grows. The goal is to keep the game design and codebase as good as possible at all times. If I were to design everythign before starting writing code, I would be basing lot of design on assumptions.
-
If I were to design everythign before starting writing code, I would be basing lot of design on assumptions.
This is not related to programming but game design itself. In other words you need to test some feature to see if it works in gameplay's point of view. But it could in theory work already in the design. I think designing has bigger role when you get more experienced in game development. I guess it's something you don't learn quick.
-
If I were to design everythign before starting writing code, I would be basing lot of design on assumptions.
This is not related to programming but game design itself. In other words you need to test some feature to see if it works in gameplay's point of view. But it could in theory work already in the design. I think designing has bigger role when you get more experienced in game development. I guess it's something you don't learn quick.
Yes and no. If I'm giving character class special attack to compensate slower healing rate, I'm assuming that slower healing rate needs compensation and that special attack is good for that. If I'm first playing around with character that has slower healing rate, I probably get idea if it needs compensation.
Granted, the more experienced you are, the bigger steps you can take in designing a game. I'm not Sirlin, so I have to take smaller steps.
-
I find design much harder than implementation for the most part. Potential features get thrown away usually because of not fitting to game theme, being silly shout outs or not contributing to gameplay. Very rarely something pops up that is discarded because one would have to redo half of underlying architecture to include it.
Some features that are found difficult to implement or requiring significant extension to the engine are delayed. When enough good proposals that require container items (or similar solution) to be put into game you will eventually find them in PRIME.
When you have a great idea that fits into theme and would be very fun you have designed absolutely nothing yet. Design means you know by exactly what mechanics interaction will be handled.
I recommend taking five minutes with a pencil and sheet of paper whenever something potentially excellent pops up to your mind. With smaller ideas you can do all the thinking in your head. I have a hard time explaining thing without bad examples so here it goes.
For PRIME 1.9, we (me and Psiweapon) wanted more psykers. There was proposal of adding Bene Gesserit who would make use of The Voice. Sounds neat, eh? So decide how exactly it works! Thats design. Psiweapon handed me phrases for reverend mothers to speak and told what actions on part of the player would be blocked in effect.
- "You will not show belligerence!" / unable to make direct attacks
- "You will not read the Nam-Shub!" / unable to use computers
- "You will not indulge your mutant nature!" / unable to use psi/mutant powers
Later I had a look at other timed effects and determined best durations for this to work so that getting commanded with The Voice is an obstacle but never something that would ruin your day. Unless you make several mistakes that is. Then one needs to compare the effects against other powers in PRIME. For example not showing belligerence is similar to fear in many respects. It means one has to consider whether it is still interesting and worth keeping this effect.
Next, implementation phase. In case of the Voice that was not difficult. Engine has supported timed conditions already so all I had to do was to handle user interface commands and modify some of them depending on current conditions. Finally, playtest. Nothing can substitute that.
To sum up, I sometimes discard ideas because of implementation difficulty but often just delay them. Ideas get far more often dropped because of design considerations.
-
I've just resigned myself to the notion that RPGs take a lot of time to make.
-
I've just resigned myself to the notion that RPGs take a lot of time to make.
Seven days?
-
Wow. Learning a lot about people's process.
-
One of the major problems is that the design is not complete (not detailed enough) or it has a flaw and it doesn't work when it's implemented. I think design/planning is the least known and mastered aspect of game programming, maybe because it's the worst part of it: Create a complete design and stick to it? No thanks, I'll just come up with something and see what happens.
Huh, I think I find myself saying (about my project) "Have a complete design but need to implement it? No thanks, I'll just keep designing." I guess that's just me, always thinking, never doing. I think the major problem for me is I'm not a guru programmer, and then it's like, "Oh, magic should be able to teleport you through walls! How do I do that?!"
I also like Krice's comment about how the best way to build a RL is to start with a robust engine and slowly add features.