Ease of Implimentation...Major Consideration?

[guest509]

  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.

[Krice]

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.

[Legend]

I would love to play this HeroRL idea you mentioned.

[guest509]

  So would I Legend...

[requerent]

Wait- what's your problem?

Are you having trouble designing the rules of your game, or programming it?

[TheCreator]

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 .

[guest509]

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.

[requerent]

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.

[kraflab]

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

[guest509]

  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.

[requerent]

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.

[requerent]

 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.

[kraflab]

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.

[guest509]

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!

[guest509]

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.