Analysis Paralisis - how do you cope?

Miscellaneous Topics
#1

Hi there…

I’d like to know your oppinion on this topic. (forgive me this core dump :slight_smile:

Programming games has always attracted me, but destiny ( = loosing three times an almost completed platform game in the CGA era, written in Turbo Pascal 3.0, together with the backup copies >:( ) has made me work in a different sector of IT.

So now that it seems that I have more time I’d like to develop a game I’ve been thinking for many years now, but I find that there’s so much info out there and so many ways of doing things that I keep falling into the classical “analysis paralisis” antipattern ???

In the “good old times” when you wanted paralax scrolling in the EGA there was basically one way of doing it quickly (for those who remember duke nukem - the non 3D version :-), and there was one fast flood-fill algo and there was one way of dealing with com ports; if you wanted wolfenstein, you did ray casting, if you wanted quake, you did BSPs.

But now I find myself spending more and more time reading and reading than coding or designing. And the problem is that usually there are pros and cons to every aspect of coding, so in the end I usually end with much more information, but finally with no objective clue as to which way to go :slight_smile: “UDP vs TCP”, "Java3D vs JOAL vs … ", “DirectX vs OpenGL”, etc… endless discussions come to mind. And finally I take a decision based on “gut feeling” which is probably the very same thing I could have done at the beginning without reading so much. I mean, an “informed gut-feeling decision” doesn’t look better to me than a “plain-old-style gut-feeling decision”.

Does anyone have similar feelings? How do you cope with them? Where do you place your threshold for stopping reading and start coding?

#2

It sounds to me like you’ve hit the point where you can no longer work on games as an individual coder. Different people have different thresholds (I’ve met some exceptionally hard-working people who are still able - as individuals - to know enough and keep current on all topics to be able to write modern games to modern standards all on their own; but comments like “no matter how successful this game is, I’m now so sick of games I’ll never write another” give some insight into what sacrifice is going on ;)).

So, my top suggestion is to assemble a small team. There’s a post somewhere in the competition category with my thoughts on small teams for java games dev, which may or may not prove helpful.

#3

Perhaps you are analysing before you know what you want to achieve. Consider writing down everything you actually want to do in the game before you even think about analysing the code. Then try chucking out everything that sounds a bit too fancy or ambitious.

And the way I cope with indecision… is to decide.

Cas :slight_smile:

#4

Good points.

I would also add that unless you’re doing your current project “professionally” (that is, unless you’re getting paid for thankless hours of work) then it sound like it’s just a hobby at this point. And if it’s a hobby, then just do what you want, don’t overwork yourself, and enjoy the experience as a whole. It’s easy to get mired down in implementation details. Instead, try to figure out what technologies you need to use in order to accomplish what you want, and then go for it - in other words, pick anything that will work; don’t let the details of the implementation get in the way of making it a reality. There’s going to be pros and cons to any method, and I’d say without some solid coding experience in any of them, you won’t be able to make anything beyond the “gut feeling” you were referring to - and that’s perfectly normal.

On the other hand - maybe programming (even if you’re really good at it) just isn’t up your alley. Perhaps working with game-building tools (map editors and the like) could be a more rewarding experience to you. There are some simple game engines in the community that might be of help.

#5

I get lost like this all the time. I have about 5 projects I’d like to do and I get lost in indecision. I agree with these guys; you have to pick a project and buckle down and ‘do it’. Which I hope to do one day…

Very true. I was having a blast programming my script editor/map editor/game-ide thing; I was learning swing and it’s my first gui app; its great. I even set it up as a project on sourceforge so I can play with css/php/mysql.

Learning new things is good.

#6

Thank’s for all the replies :smiley:

I think probably kul_th_las come closer to the probable truth - my lack of experience in specifically game programming (yes it’s a hobby), and the fact that I’ve been programming for over 20 years makes me want to write games as perfectly as the software I currently write, and this makes me analyze too much…

blahblahblahh - I don’t think being part of a team would solve my problem - If I’m only in charge of the networking for example, I’d still have the TCP vs UDP indecision. But then OTOH maybe I’d have the time write some benchmarks and have some hard data on which to decide…

Programming a lot isn’t a problem - I’ve pulled hobby projects of more than 50 KLOC when they sounded interesting, and I’ve also written all sorts of strange things just for the fun of them (a GUI in Forth comes to mind :smiley: ) Since the game I want to do doesn’t seem to exist (I have had a fixation on this kind of game for more than 8 years now), I can’t use any scripting engine. Probably I’ll start anyway and let’s see what it comes out of it.
I only hope I don’t overanalyze and end up with:

public class Quark { … }
public interface ElectroWeakInteraction { … }
:o

But what I’d really like to know is how much time do you spend researching vs programming. For example, imagine that you wanted to start a MUD, or a RTS game - any genre you’ve never worked in. How much time would you spend reading gamasutra, javagaming and the like before sitting down and starting to work?

#7

None at all - I’d get the game requirements thought out first, and then make a few snap technical decisions, eg. what graphics API to use. I know a bit more OpenGL than any other API so I decide on that.

Often the first thing I then do is simply bash out a bunch of classes with stub methods in just to see how it might fit together. Some people like to draw diagrams; I just use code - same difference.

At some point I’ll get stuck and then it’s time to ask questions on forums and google for code snippets. This comes up particularly in OpenGL programming - lots of things are difficult until you know how to do them. Then I’ll code them up and squirrel them away in a class and never need to learn how to do it again.

Sooner or later I give up and fail.

Then I start on something else, with slightly less ambition. But the great bit is all that code I wrote in the last failed project gets reused and instead of my mental thought processes getting stalled like a Pentium pipeline when I come across a problem, I simply yank out a chunk of code from the previous project and get straight on doing the game.

The first cycle of success I had with this technique was Alien Flux, which followed no less than 3 aborted projects. The second cycle of success I’m having is Super Elvis, which has borrowed so much code from Alien Flux I’ve been able to write it in approximately two weeks.

Cas :slight_smile:

#8

Half the time it doesn’t actually matter half as much :slight_smile:

With the speed of modern PC’s, you can very often get away with routines that would be considered ‘sub-optimal’ by the purists, but unless you are trying to do Doom3 and throw millions of polys per second around, chances are noone will notice.

I have 101 stories from proffesional game dev where someone goes on about how technique X is vitally important, junior coder things ‘sod that for a game of soldiers’ and uses technique Y, and noone notices the difference :slight_smile:

The best addage is always: Keep It Simple, Stupid.

I think it is Jeff who said that the best way is to build it first, then find out what is slow. This is so definately what happens in proffesional game dev. Code for programmer convinience first (simplicity), and only change it if you are getting real speed problems.

  • Dom
#9

Yes, that is part of the benefit. The other part is that if you have a decent Producer on the team, analysis paralysis will NOT happen (because it’s their role to prevent it!). Equally, just having a decent Designer (game design) can have the same beneficial effect. Or, to put it another way, if you suffer from this then you are not suited to being a Producer, and would benefit from finding someone who is - rather than try to change yourself, just find someone else who complements you :).

Anything from 2 months to 5 years. Depends entirely on the genre, what transferable skills you have in terms of known libraries / algos / etc (e.g. Cas transferred a large percentage of skills and experience from one project to the next), and what role you are taking. Even in a single-person game project, that person rarely (if ever) is diligent enough to take on all the possible roles. So, what you choose to skimp on has a big effect on how much time you need to spend researching.

Moving on from research, you are a fool (IMHO; or just a gambler (which arguably is the same thing ;))) if you do not plan your game before starting. There are one or two people around here who swear by not planning things, so maybe it’s not for everyone, but I’d still confidently force it upon 98% of people as a beneficial thing. You should - at the very least! - write a game concept doc (there’s a template + article describing them on gamasutra; if you can’t find it on google, go to grexengine.com, and look in the FAQ). Then you should - at the very least! - do some UML planning. Especially since this is java, where you should be writing everything to interfaces (I don’t know what excuses there are for not writing everything to interfaces; perhaps there’s some really rare case where they aren’t worth having?).

EDIT: Unless you are not interested in writing a game for the game’s sake, and are never intending to release a game: e.g. you’re doing it as an experiment in learning a (set of) technology(s). My understanding of the OP was that the goal was to make a game.

#10

ahristov, (long post coming… sorry)

I generally agree with all the comments here. It sounds like I’m in much the same situation as you. Besides programming, I love the research I do before getting on with a new project. I love the research so much, I never stop doing it, in fact. I’ve never written a game before, but I’ve been programming for 15 years. Gaming is definitly a hobby for me. Here’s what I did/do:

I found this forum and I read like mad for about 3 days straight. This gave me a broad base of information. Then I took break, let it sink in, and decided to write a ‘game’. I say ‘game’ because I don’t necessarilly think what I’m writing will be any fun, if I ever even finish it. I think of it as a technology test where I can try out things without sweating the details like a schedule or ‘proper design docs’ and such. The game I picked is is the classic balistics game where multiple players pick angle/power and try to shoot one another. I extended it to 3D, live action, on a network. I’m trying to play with these techs: 3D, sound, input, model building, networking (for games), and physics. To me, these areas seem to cover almost anything I’d like to write and I have almost no previous knowledge.

I started coding with very minimal initial goals, like generating a random terrain height map and displaying it with java3D (colored, no textures) (about a month of work). I then worked a little on input just so I could move around and gracefully exit my app. Then I started to build models using an editor (Blender) which took a bit of research and a learning curve (another month). Then I got my models into my app and displaying as I wanted. Then I started working on physics (using odejava) and getting my models to move around (another month). Then I worked on texturing. I just finished writing a particle engine. I haven’t touched sound or networking yet, and I have to revisit input soon.

Basically, I focus on one particular aspect at a time and learn as much as I can about it while I’m writing it. I throw out a lot of code along the way, and sometimes have to make huge architectural changes to my app, but I set my initial expectations with all that in mind.

I also read these forums every day. I find they make good breakfast reading (I’m eating my cereal right now). On any given day, I might be focusing my reading on a particular area that I plan on working on in the next few days, but I read almost every new post in every topic anyway. I’m always finding little bits of insight into aspects I never would have thought about otherwise. I find that I’m slowing building a deeper understanding of the whole gaming thing, and not just about my ‘game’.

I’ve also decided that I’ll never know absolutlely everything about everything in these areas, but rather I understand enough to ask [hopefully] intelligent questions, make good guesses, know the issues, pros and cons, and understand what others write on the subject (that seems to be true of life in general). My ‘game’ is slowly evolving into an architecture and design I wouldn’t have thought of in the beginning, but makes sense now.

I also take my time. Lots of it.

I don’t know if any of that helps, but it works for me.

-Tab

#11

Wazdat?

First you should do a game design, not looking around various sites on articles. Reading and writing games are two different things.

#12

What generally works really well is working around the limitations. Think about how you could do the best thing out of your resources. It might sound funny, but programming usually isn’t the most limitating factor. Usually it’s time and artistic skills.

So think about what you can do in your time and with your artistic skills… then one comes to another and it boils down to a handfull of games wich you could do - but the good thing is you could make em very very well.

Kinda simplified, but I think you get the idea. It’s much easier to decide if you really know what you want to do.

That process helped my planning alot and my spare time is nicely trashed with programming and art for the current game and research for game#3 (game#2 is totally finished research wise ;)). I think it’s important to have some variation in the stuff you do (well otherwise I would go nutz :P).

#13

I totally disagree with you Raghar, reading/writing a game is exactly the same thing. Infact, reading a game can be considered game design.

The way I see things is I can base an entire game around a single image. Seriously, thats what im doing for my current game. I have an image in my head, thats the design done. I know Jme more than I know anything on PC, so Im using that. Simple as.

I mostly do what princec does, code, and when it becomes very hard to add other stuff on, I trash it, and start again.

To be fair, i have never really finished anything. Simply because it becomes boring after 2 hours. After 2 hours, I would have the entire game up, all thats left is the game desing (oh btw, anybody wanna help with that).

frdfsnlght, I sort of do the opposite of you in a sense. I can’t focus on one thing and get on with it. Im like a caterpillar, i eat small chuncks out of ever leaf until the whole tree is dead (bad metaphor, but gets the message across).

At the end of the day, It really helps to organise things at the end of the day (in my brain, i dont like paper). What did I do today, what needs to be done.

Simple as a piece of crap on a stick.

DP

#14

Raghar, to do a proper design of a software in a sector you’ve never worked in, and even in areas where you have a lot of expertise, it is usually a good idea to read what other people have done before making any decisions. Otherwise you’ll end up either reinventing the wheel or -more probably - inventing a square wheel.

For example, if you’ve never written a web app, it would be a very bad idea to design one without learning before about the design patterns that already exist - mvc, front controller, delegates, helpers and the rest of the bunch. It is very doubtful that making a design from scratch on your own would even approach the elegance, power and simplicity of these industrially tried designs.

“Analysis paralisis” is the other side of the coin - it’s an antipattern in which a team focuses so much on analysis that becomes paralized trying to make a perfect analysis controlling every possible contingency and risk factor and trying to make a system infinitely flexible to accomodate future changes.

A joke comes to mind regarding reading/writing games:

A guy meets the editor of an important publisher

  • I’m a writer, and I have this fantastic novel I’d like to publish.
  • I see. Have you read Shakespeare?
  • No.
  • And Lev Tolstoi?
  • No!!
  • Maybe Oscar Wilde?
  • Hey, stop bothering me!! I told you I was a writer, not a reader!

Well, same thing here :slight_smile:

#15

I think you’ve got the wrong idea. AFAICS Raghar was pointing out that game design is a process that starts before worrying about technologies, processes, patterns, etc. Which is true, of course. In commercial games dev even a basic game-design is not really considered complete until it has had some research done on available technologies, e.g. to check that the game is achievable (!), but you should have several pages of game-design firmed-up before you start doing any detailed tech analysis (or, at least, this is what I though Raghar was saying).

In that analogy, what I believe Raghar was saying is “first you have to decide why you want a web app, what the point of the thing is, what service you are trying to offer to a customer, etc. Then once you have that firmed up, a lot of the technology decisions will already be more constrained”.

I know it was a tiny toy example, but…what I don’t see in your process is any differentiation between game design and game-implementation. The lack of this differentiation is sometimes held up as what separates wannabe games developers from real ones. That’s harsh, but perhaps fair in general: in general, there are a lot of people who embark on a game but don’t / can’t be bothered to write up a formal game-design first, and screw up. Or fail to differentiate mentally between design and technology, and screw up. Generally the technology works but it ends up being a tech demo (c.f. Elixir Studios’ Republic - where was the game?) instead of a game.

Just a thought.

#16

I think we have a terminology problem. For me, the things you are talking about are just requirements gathering, just a phase in the overall design process and according to some a separate phase prior to design. As for that, I’ve a clear idea of what I want to achieve, and yes it’s fixed on e-paper (a txt document )

I don’t know why some people have misinterpreted my original post as “not knowing what I want to do” as opposing to “not knowing which technologies to use to implement a clear idea”. In my original post, I was speaking about technologies, which should imply that the requirements gathering phase was over. Obviously, if in the requirements phase I hadn’t decided that I wanted networking, I wouldn’t have doubts regarding whether to use UDP or TCP. However, you can’t do a proper structural analysis if you don’t know the underlying layer.

I’ve more than enough experience to know that if you don’t have a clear goal, no road will lead you to a morphing destiny :slight_smile: .

This is just requirements gathering for me - i.e. “knowing what you / the customer wants the system to do” -, not design.

I’m sorry to disagree, but in any other software area “design” is defined as a formal description of how a system fulfilling a set of requirements will be implemented, and this does include the choice of underlying technologies.
How on earth are you going to make a structural and interaction diagram of your software -which is certainly part of the design phase - if you haven’t decided whether you’ll be using a centralized or mesh topology for your networking? or reliable vs non-reliable delivery?

I don’t believe “game design” means anything different, and I don’t think that choosing technologies on the fly during the implementation - coding - phase as you seem to suggest is a very prudent way to go unless you have a huge experience in similar implementations - and even in that case I’d be careful - which as I stated in my first post is not my case in the specific area of game programming.

#17

There a step before game design that you’ve missed out, and that’s the purpose of the game. Is it purely for personal enjoyment? Is it for the people on this board to play? Is it to sell and make money? You’ve really got to get this bit worked out first as it affects everything you do from then onwards. Everything!

Cas :slight_smile:

#18

[quote]There a step before game design that you’ve missed out, and that’s the purpose of the game. Is it purely for personal enjoyment? Is it for the people on this board to play? Is it to sell and make money? You’ve really got to get this bit worked out first as it affects everything you do from then onwards. Everything!

Cas :slight_smile:
[/quote]
Cas, why do you believe I’ve missed this point?

“The aim of the game is to help the popularization of science and to bring closer to people the way scientific methods, technologies and instruments are used in scientific research. The game will have a client/server architecture. The client will be offered free of charge, and will be distributed using web downloads, cds in scientific fairs, magazines, etc. There will be a centralized server farm that will offer a shared online environment where the game will develop. Money for running the operation will be sought by means of corporate sponsorships, state aids under the available programmes for scientific popularization or personal donations. Accessing the game will be free of charge.”

Is this a clear enough aim? :slight_smile:

#19

And to be even more specific:

"Our primary target market are boys and girls in the second half of secondary school levels (this is a rough translation from spanish, I don’t know what’s the equivalent name in english for that education level), as well as university students in their first three years - an age group spanning approximately from 15 to 23 years. "

#20

Well, I put it like that, because redundancy between the current APIs is very low and therefore the choice is pretty straight forward.

OpenGL? If you need a scengraph api then Xith3D, if not (eg for a accelerated 2D game) either lwjgl (which has it all) or jogl (plus joal and jinput). Plain2D without anything? Java2D then.

Simple physics? Roll your own. Complex physics? Take a look at ODE.

It just boils down to that splitsecond decision :slight_smile:

And just before hitting submit… science, science, science? That’s like a 2.5 dimension drift compared to the initial post :stuck_out_tongue: