Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Analysis Paralisis - how do you cope?  (Read 6285 times)
0 Members and 1 Guest are viewing this topic.
Offline ahristov

Senior Member


Projects: 7


Java games rock!


« Posted 2004-06-25 16:27:04 »

Hi there...

I'd like to know your oppinion on this topic.  (forgive me this core dump :-)

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  Angry )  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  Huh

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 :-)  "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?

Planetalia S.L. Cursos de Java
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2004-06-25 16:33:45 »

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

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.

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2004-06-25 19:35:01 »

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 Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
kul_th_las
Guest
« Reply #3 - Posted 2004-06-25 22:15:26 »

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

Senior Member




Giving Java a second chance after ludumdare fiasco


« Reply #4 - Posted 2004-06-26 02:03:37 »

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

Quote

Perhaps working with game-building tools (map editors and the like) could be a more rewarding experience to you.


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

Senior Member


Projects: 7


Java games rock!


« Reply #5 - Posted 2004-06-26 09:54:08 »

Thank's for all the replies  Cheesy

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 Cheesy ) 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 { ... }
Shocked

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?

Planetalia S.L. Cursos de Java
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2004-06-26 10:30:19 »

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 Smiley

Offline crystalsquid

Junior Member




... Boing ...


« Reply #7 - Posted 2004-06-26 10:37:43 »

Half the time it doesn't actually matter half as much Smiley

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 Smiley

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
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #8 - Posted 2004-06-26 11:57:04 »

Quote

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


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

Quote

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?


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

malloc will be first against the wall when the revolution comes...
Offline frdfsnlght

Senior Newbie




Trying to understand


« Reply #9 - Posted 2004-06-26 12:08:12 »

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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Raghar

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #10 - Posted 2004-06-26 20:32:56 »

Quote

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  Huh


Wazdat?

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

Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #11 - Posted 2004-06-26 22:09:17 »

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 Wink). I think it's important to have some variation in the stuff you do (well otherwise I would go nutz Tongue).

弾幕 ☆ @mahonnaiseblog
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #12 - Posted 2004-06-26 22:11:56 »

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

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline ahristov

Senior Member


Projects: 7


Java games rock!


« Reply #13 - Posted 2004-06-27 11:44:57 »

Quote

Wazdat?

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



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 :-)

Planetalia S.L. Cursos de Java
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #14 - Posted 2004-06-27 11:59:41 »

Quote


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.


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

Quote

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


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

Quote

A joke comes to mind regarding reading/writing games:


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.

malloc will be first against the wall when the revolution comes...
Offline ahristov

Senior Member


Projects: 7


Java games rock!


« Reply #15 - Posted 2004-06-27 12:49:24 »

Quote


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



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

Quote

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


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

Quote


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.

Or fail to differentiate mentally between design and technology, and screw up.



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.

Planetalia S.L. Cursos de Java
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2004-06-27 12:50:00 »

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 Smiley

Offline ahristov

Senior Member


Projects: 7


Java games rock!


« Reply #17 - Posted 2004-06-27 12:59:49 »

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 Smiley


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? Smiley

Planetalia S.L. Cursos de Java
Offline ahristov

Senior Member


Projects: 7


Java games rock!


« Reply #18 - Posted 2004-06-27 13:09:25 »

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

Planetalia S.L. Cursos de Java
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #19 - Posted 2004-06-27 13:17:44 »

Quote

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


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 Smiley

And just before hitting submit... science, science, science? That's like a 2.5 dimension drift compared to the initial post Tongue

弾幕 ☆ @mahonnaiseblog
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #20 - Posted 2004-06-27 13:22:09 »

Just to be clear, my quoted comments were trying to explain what I thought Raghar was saying, not necessarily my opinions Smiley.

Quote


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


You appear to be missing the point that "game design" is an entirely separate kettle of fish from "application design". Requirements gathering, spec'ing, etc are all part of app design (they could be part of game-design too, in which case you are doing two sets of each).

Quote

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


Perhaps because game development is not about implementing an idea but about implementing a game-design, which is so much more complex than a single set of requirements / use-cases / etc that it (traditionally) is treated as an entirely separate process in and of itself?

The way that it's usually described (lazily) in the industry (i.e. in lectures, articles, face-to-face, etc) is something like: "rather than only having requirements, we have an extra thing we have to manage called "putting the fun in", and that's not encapsulatable and becomes a parallel/separate process to the sofware engineering/design". Most people don't bother trying to explain it beyond putting some phrase in inverted commas with the word "fun" in there somewhere, with the implicit assumption "you know what I mean".

Quote

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.


Well, my suggestion was that the workload was getting beyond your capabilities as in individual (no matter how great you are...). But I can see a separate point that if you really had a game design completed then you wouldn't need to spend much time picking particular technologies - because the game-design has already given you enough information to generate additional requirements on-the-fly.

c.f. Star Wars Galaxies, where the team was run from a 100+ page game-design document. Whenever questions came up about impreciseness in the software requirements, or about "should we adopt algorithm/library/technology X instead of the Y we were planning?" the game-design doc was used as "the bible" which would answer the question without allowing room for competing opinions - it's say was final.

Quote

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


Probably my attempt to extend the analogy tripped up Smiley.

Quote

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


You are certainly in a minority when compared to commercial games developmers, then. Whether your way of looking at things is right or wrong (I'm not qualified to have an opinion on that! Ask me again when I've managed 10's of games projects Wink), it's not how others do things. Personally, I'm inclined to agree with that majority on this subject: my experience strongly supports the view that if you don't separate game-design from software-design then your game has a much higher chance of sucking as a game (i.e. being boring, unsatisfying, or unaddictive to play), even if the software engineering side is perfect (no bugs, short dev time, etc etc).

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #21 - Posted 2004-06-27 13:23:53 »

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? Smiley


Um, there's absolutely nothing of "game design" in that which would lead me to ask (playing devil's advocate):

  Where's the fun in this? Sounds like it's going to be as enjoyable as watching paint dry, unless there's a secret bit of gameplay in there which you're keeping quite about...

malloc will be first against the wall when the revolution comes...
Offline ahristov

Senior Member


Projects: 7


Java games rock!


« Reply #22 - Posted 2004-06-27 14:14:09 »

Quote


You appear to be missing the point that "game design" is an entirely separate kettle of fish from "application design". Requirements gathering, spec'ing, etc are all part of app design (they could be part of game-design too, in which case you are doing two sets of each).


Perhaps because game development is not about implementing an idea but about implementing a game-design, which is so much more complex than a single set of requirements / use-cases / etc that it (traditionally) is treated as an entirely separate process in and of itself?



I don't think that there's any fundamental difference between a document stating

"The planet of gamelandia has 6 contintents. ... The brown frog in continent 4 has 50 hit points. It appears with a probability of 40%, and when killed will drop a protection ring with 5% probability, otherwise it simply drops a healing potion"

and

"If the customer has purchased at least $1.500 worth of goods in the last 5 months, he will be offered a 5% discount in the next purchase, providing that he dosn't pay using a discount coupon"

I see them both as documents describing how an application (be it a game, a flight control system or 3D modelling software) should behave. As for complexity, you should see some of the 300+ page requirements documents that we handle in my real job  Smiley

I think that sweeping an inadequate documentation under the "it must be fun - you know what I mean" carpet is just an excuse. Of course I'm not an expert either, but statistics show that many games are made with a game design document which surely has lots of "fun" things in it, and yet many games - a huge majority - suck anyway.  

I think the "fun" thing can and should be expressed in the requirements. If the frog has 999 hp when it first meets the level-1 player and kills him everytime, this is not fun. If it has 10 hp and drops an Armageddon ring 100% of the times, it's not fun either. However, just stating that "the frog must behave in a way that is fun" in the document, what does that mean, and who decides that?

Quote


c.f. Star Wars Galaxies, where the team was run from a 100+ page game-design document. Whenever questions came up about impreciseness in the software requirements, or about "should we adopt algorithm/library/technology X instead of the Y we were planning?" the game-design doc was used as "the bible" which would answer the question without allowing room for competing opinions - it's say was final.


Well, I guess they had a rather detailed game bible. How would that bible helped them choose between Java3D and Xith3D for example? Smiley


Quote

Um, there's absolutely nothing of "game design" in that which would lead me to ask (playing devil's advocate):

  Where's the fun in this? Sounds like it's going to be as enjoyable as watching paint dry, unless there's a secret bit of gameplay in there which you're keeping quite about...


This is precisely the reason why I want to make such a game, because of misconceptions like that.

For example, nodoby gave a **** about the way the scientific police worked until CSI came and made it seem interesting (albeit exaggerating it a lot).

In another area, you may remember games like Star Flight, Star Control, Master of Orion or the like that - at least for me - were terribly fun to play (not their last sequels, though).

In the first two of them, for example your ship could land on planets collecting ore. Before landing, you were presented a map of the planet which generally speaking bore little relation to on-surface factors.

In my game, the general approach is similar *but* you have a wide array of instruments at your disposal - providing that you have obtained/bought/built them , of course -:

Looking for nice stars with promising planets? How about a emission analysis to determine the composition of the star and its position in the main sequence?

Want to drop a lander and pick some ore on that nice-looking planet in that binary system? Ok, go ahead blindly, land to find how a huge earthquake smashes your lander while you are happily collecting ore.  Grin
Yes, you should have dropped first some sensors for tracking geological activity. Binary systems and tidal gravity forces aren't a toy Smiley

Want to mine a nebula? You can go there and use your entire monthly pay in fuel just to find that it's a hidrogen blob or you can do an absortion scan and find that it's rich in basic organic compounds...

You picked some microorganism on Antares-IV. You can trade it for $10 at the life-traders-union, or you can do a culture of it, make a stereochemical analysis of the byproducts and discover that the critter produces insulin, which happens to raise the value of the discovery to $1000

I think you get the idea.

Planetalia S.L. Cursos de Java
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #23 - Posted 2004-06-27 14:58:50 »

Quote

In another area, you may remember games like ...

In the first two of them, for example your ship could ...

In my game, the general approach is similar *but* ...

Looking for nice stars with promising planets? ...


Right, now *this* is "game-design". Completely different from the other design stuff you quoted earlier.

I'm not sure how to respond to the earlier stuff, about specifying numbers of hit points, etc - that is NOT game-design, that is balancing and / or software/app stuff.

To me there is an obvious difference between specifying the dry facts of a design - like hitpoints - which nevertheless are often important to the fun (mainly because of the need to balance and counter-balance)...and specifying game-play, which is what you're doing in the paragraphs I quote above. Or, to put it another way, there is a whole part of the game dev process which is exactly the same as what we did at IBM on any project in the planning stages; but then there's this whole other aspect (the gameplay design) which is completely different from anything we did - although similar techniques can help focus a team when attempting to capture it (use-cases, etc). Perhaps at more "touchy-feely" Tongue dot-com companies, where the "feelings" of the client were taken on board more explicitly, there is a part of the software design process that is similar to this gameplay stuff? But personally I struggle to find neat equivalents in the traditions of software engineering. When talking to investors, I usually describe it as "usually, when software is being written competently, it is solving some problem or need - such that even though the client usually doesn't know precisely what they want, at least it's possible to analyse it and work out what they want and give it to them; in games development, there is no such need nor problem, there's nothing to analyse, you can only invent. This demands different (additional) processes".

malloc will be first against the wall when the revolution comes...
Offline ahristov

Senior Member


Projects: 7


Java games rock!


« Reply #24 - Posted 2004-06-27 15:06:54 »

Quote


Right, now *this* is "game-design". Completely different from the other design stuff you quoted earlier.

I'm not sure how to respond to the earlier stuff, about specifying numbers of hit points, etc - that is NOT game-design, that is balancing and / or software/app stuff.



So it was, after all a communications/terminology problem that we had Smiley , because I consider what I wrote basically part of the requirements, although belonging to the introduction of the whole specification, something like explaining the big picture and the rationale for the specific things that come afterwards....

But anyway, having all that clear still doesn't doesn't help me with my doubts Smiley

Planetalia S.L. Cursos de Java
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #25 - Posted 2004-06-27 15:08:09 »

Quote

This is precisely the reason why I want to make such a game, because of misconceptions like that.


That is the wrong thing to say, here. There was no "misconception" - you had completely failed to describe anything even remotely approaching "gameplay". Your entire description could have perfectly well been applied to a website of "suggested science-projects for teachers to use in schools" ... or even "a revision aid for science subjects" website.

I only put forward a simple question: where's the GAME.

Quote

I think you get the idea.


...now that you've furnished us with descriptions of the game/gameplay, yes, I have a good idea thanks Grin. Sounds fun.

Although it also sounds suspiciously similar to the plans of people who want to make that infamous MMOG: The Universe (TM) (with plans to "model every atom separately using a particle system. It'll be really cool - we'll get, like, water running downhill, and a REAL physics system instead of this simulated crap" etc.

Which is why game-design as a process in and of itself is so highly recommended Grin. Now, I'm not suggesting you really care about what I think - I'm not a publisher nor customer - and maybe your gameplay is carefully scoped so that the above paragraph is inaccurate to the point of being insulting and patronising. I'm just going on what you've said so far, and trying to show how things like separating out game(play)-design could/would help, if someone were trying to pitch something using similar phrasing as you've used in this thread.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #26 - Posted 2004-06-27 15:18:23 »

Quote


Well, I guess they had a rather detailed game bible. How would that bible helped them choose between Java3D and Xith3D for example? Smiley


Perhaps: Because it either describes the gameplay as "designed to work on a small home-PC screen" or it describes it as "works on a PC but really shines on a CAVE".

Basically, technical analysis will often make your decision for you ("Do I know OpenGL and have my own SG? Why, then I don't want an SG I just want an OGL binding") - or narrow it down to a few.

It tends to leave blanks - perhaps your technical analysis leads you to choosing jME or Xith with either being OK. NOW the wooly bits are probably answered by the details of your game(play) design...which talks about the look and feel of your game (no game design doc can avoid describing L&F!). That should then - in most cases - differentiate enough to make your decision for you. Between the two types of evaluation, you should only be left with a coin-toss in a tiny minority of cases.

To a certain extent, I'm with Onyx on this - I'm not sure why you would have much paralysis on current techs. For instance, the choice between what transport layer you use for your networking seems to me fairly trivial, as soon as you are armed with a decent resource (like the networking forum here Wink)

1. You know nothing about networking: learn a bit, then go get a 3rd party solution. There are several that are 100% free. You don't care what transport it uses.
2. You are competent at networking and understand the basics of TCP & UDP already: read the thread on this forum, and you now have a checklist of what the differences are. Run down the list and choose.
3. You are really into networking, or want to do something really special: read the thread on this forum, and learn WHY people ever bother with the inferior UDP protocol. Discover that they want RDP / TCP-without-in-order-delivery - and go away and implement precisely that.

Of course, just *finding* the decent resource is often the problem. Hence things like making all articles on JGF peer-reviewed, to try and make it into a resource you can "trust" and save you having to trawl the net for good reliable sources...

malloc will be first against the wall when the revolution comes...
Offline ahristov

Senior Member


Projects: 7


Java games rock!


« Reply #27 - Posted 2004-06-27 17:15:02 »

Quote


That is the wrong thing to say, here. There was no "misconception" - you had completely failed to describe anything even remotely approaching "gameplay".


Yes, i hadn't written anything about gameplay (i was answering a specific question made by Cas about the aim of the game, not about of the gameplay).. but that didn't stop you from concluding that it would be as boring as watching a painting dry Cheesy It looks like a statement to me, not a question Cheesy, an oppinion about a subject formed on no facts about that subject, precisely the definition of the word  misconception Wink.

Quote

Your entire description could have perfectly well been applied to a website of "suggested science-projects for teachers to use in schools" ... or even "a revision aid for science subjects" website.


When did I say that it was a description? It was the aim of the game, not a description of it. RTFP Grin. I think it's clear that it's quite different to say that the aim of a fighter is to defend a country than to describe how the fighter works.  You use the aim when you go to Congress asking for budget, and then you use the description when talking to engineers.

Quote


Although it also sounds suspiciously similar to the plans of people who want to make that infamous MMOG: The Universe (TM) (with plans to "model every atom separately using a particle system. It'll be really cool - we'll get, like, water running downhill, and a REAL physics system instead of this simulated crap" etc.


Well, good luck to them Cheesy Except that atoms are not particles and atomic systems don't behave like that, and no amount of computing power will ever be capable of such a simulation. The only way to simulate such a system is to be the system.  That's the fun of chaotic systems - systems that are deterministic but unpredictable nonetheless. And if we add to that nondeterministic qm then it becomes even more fun Cheesy

Quote


2. You are competent at networking and understand the basics of TCP & UDP already: read the thread on this forum, and you now have a checklist of what the differences are. Run down the list and choose.
3. You are really into networking, or want to do something really special: read the thread on this forum, and learn WHY people ever bother with the inferior UDP protocol. Discover that they want RDP / TCP-without-in-order-delivery - and go away and implement precisely that.

I'm somewhere between point 2 and 3, plus added lazyness because networking is not fun (to me). I don't feel like diving in the source code of a TCP stack just to remove the in-order-delivery, and I don't feel like writing a new protocol from scratch either since I know that this is no trivial stuff and network protocols are difficult to get right. I'll see if there's something already written, but probably I'll just use two connections - TCP for things that I need guaranteed delivery and happen not so frequently and UDP for the rest, and use a common sequence number for frames and a mux/demux that sends them to the appropriate channel.

The problem with peer-reviewed articles is that here we have only oppinions. Most people I've read speak from their generic knowledge of the xxx protocol, but few have done hands-on research that can be reviewed, in the sense that "I wrote a small game to test bla bla bla. Here are the results plotted against quality of the channel expressed in % of incorrectly transmitted frames for modem users, xDSL users etc.. Here's also the playabilty of the game as judged by the players...". It's like trying to recommend a diet without taking into account the specific traits of the patient.

You can't peer-review an oppinion. In science journals - described theories and experiments are either mathematically correct and reproducible or not. You don't say "IMHO x^2  = 2 has no rational roots". As Grimaldi said, "Arithmetics is not an oppinion".

Planetalia S.L. Cursos de Java
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #28 - Posted 2004-06-27 17:45:48 »

Quote

not about of the gameplay).. but that didn't stop you from concluding that it would be as boring as watching a painting dry Cheesy It looks like a statement to me, not a question Cheesy, an oppinion about a subject formed on no facts about that subject, precisely the definition of the word  misconception Wink.


I was only trying to say that although you'd said lots of things that might normally be considered the output of the design phase of a project, they lacked what's special about a games project. Perhaps the "devil's advocate" phrase didn't mean anything to you? It means "deliberately taking this is in the worst possible way, in order to establish what happens at the extremes, and possibly uncover a flaw in what is being said (that might otherwise be brushed aside because I happen to know what you really mean)". According to dictionary.com, "argues against a cause or position, not as a committed opponent but simply ... to determine the validity of the cause".

Quote

Well, good luck to them Cheesy Except that atoms are not particles ...


Perhaps I wasn't obvious enough: I was saying that they have a generic vague idea of what they want to do, rather than a game-design. They have no game, and worse they're hankering after something practically (and obviously) impossible, but superficially "neat".

Quote

I'm somewhere between point 2 and 3, plus added lazyness because networking is not fun (to me). I don't feel like diving in the source code of a TCP stack ...


So, where's the problem? Going back to the point, I don't understand why/how you get paralysis here?

Quote

The problem with peer-reviewed articles is that here we have only oppinions. Most people I've read speak from their generic knowledge of the xxx protocol, but few have done hands-on research that can be reviewed


OT, but ... what words do you want me to use to describe the process where someone who has done the thing before reads an article someone else has written on the subject, and decides if it's genuine, whether or not the source actually works, and whether it's misleading or not?

To me the whole point of peer-review is to prevent precisely what you describe - "speak from their generic knowledge of the xxx protocol, but few have done hands-on" - and end up with things that *actually work* rather than being vague conjecture. How should I describe this?

Quote


Yes, i hadn't written anything about gameplay (i was answering a specific question made by Cas about the aim of the game,


I'm confused now. Shrug. I've lost the plot of what you think design is and isn't, so I shall bow out now before causing further confusion Smiley.

malloc will be first against the wall when the revolution comes...
Offline ahristov

Senior Member


Projects: 7


Java games rock!


« Reply #29 - Posted 2004-06-27 18:11:12 »

Quote


So, where's the problem? Going back to the point, I don't understand why/how you get paralysis here?



Cheesy Basically, the paralisis comes from trying to achieve a perfect design using the optimal tools when as someone rightly said here, in today's computing world and unless I'm aiming at a "bleeding edge technology game" (which I'm not) it doesn't really matter.  So I'll hear the advice of Richie and "first make it work, then make it work fast" Wink

Quote



To me the whole point of peer-review is to prevent precisely what you describe - "speak from their generic knowledge of the xxx protocol, but few have done hands-on" - and end up with things that *actually work* rather than being vague conjecture. How should I describe this?



Just the way you did  Wink  But I haven't seen articles like the one you mention in the networking forum, or maybe I haven't looked well enough.

Planetalia S.L. Cursos de Java
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (25 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (43 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!