STAFF WANTED for COMMERSIAL ADVENTURE GAME
Prelusion
My name is Mike Hiltunen and I am the lead programmer of a game development
company known as Prelusion.
Prelusion is a game development company with the goal of making high quality
games for the PC systems as well as for other platforms.
We are currently working on our first title "Gilbert Goodmate and the
Mushroom of Phungoria" which is an adventure game in the same style as the
Monkey Island series.
"Gilbert Goodmate" is being published by Crystal Software, a UK based
computer games publishing company. “Gilbert Goodmate” will be released for
the PC, the Amiga and possibly for other platforms as well.
Prelusion consists of four members and a number of external employees in the
areas programming, graphics, animations, music, dialogue writing and sample
speech.
We are looking for talented people to work with us on the "Gilbert Goodmate"
project.
We need people to work with us on distance. This means working at home
keeping regular contact with one and other over the internet.
The payment will be a certain percentage of the total income from the game
once released.
Feel free to take a look at our web-site for more information about
Prelusion and the game, as well as a work-in-progress image from the game.
Listed below are the different areas in which Prelusion are looking to hire.
Programming
One 2D programmer for specific tasks required.
* Programming knowledge of and experience with PC required.
* Very good knowledge of the W95 OS and DirectX.
* Knowledge of C/C++ required.
* Strong interest in computer/video games.
Graphics
Three 2D graphic artists for background drawings and sketches required.
* Excellent artistic skills required.
* Very good imagination required.
* Strong interest in computer/adventure games.
* Knowledge of Photoshop preferred.
Animation
Three 2D animator and cut-scene maker required for specific tasks.
* Excellent animation skills required.
* Very good imagination required.
* Strong interest in computer/adventure games.
* Experience in making cartoon style animations.
(Please note that regular access to the internet and mail services are
required for all of the above cases).
If you meet the qualifications listed in any of the above areas and you are
interested in taking this opportunity to participate in the making of a
commercial computer game, then contact us now!
Email: cen...@hem1.passagen.se
Web: http://pln.home.ml.org
Best regards,
Mike Hiltunen, Programmer
Prelusion
cen...@hem1.passagen.se
C. Chapman
Let me tell Prelusion what it takes to make great games.
1. Hard Work
2. Experience
3. Talent
- Don't fall short in any of these categories or you'll get burn on both
ends.
Design and Marketing.
And remember when David knoked that giant down with his "magic" sling
shot. He was blessed by God.
Are you blessed? Do you have gift?
-Then you may reply. Otherwise I'm laughing at all of you
Howard Rubin - change nospam to nyx
"C. Chapman" <Blue...@aol.com> wrote:
<snip>
> Otherwise I'm laughing at all of you
And we're all laughing at you, your inappropriate advertising to
technical newsgroups, your incompetent spelling and your rudeness
which is likely to eliminate any competent talent you might have
hoped to attract.
--
Advertisers using spambots, please don't send to the following addresses:
pres...@whitehouse.gov vice.pr...@whitehouse.gov first...@whitehouse.gov consum...@ftc.gov c...@ftc.gov fr...@uspis.gov u...@ftc.gov rh...@fcc.gov jqu...@fcc.gov sn...@fcc.gov rch...@fcc.gov cust...@usps.gov ad...@HARRIS-MARKETING.COM postm...@HARRIS-MARKETING.COM jmo...@SAVOYNET.COM postm...@agis.net ab...@agis.net ro...@agis.net dns-...@AGIS.NET n...@AGIS.NET hostm...@agis.net pat.co...@state.co.us ph...@agis.net webm...@agis.net postm...@cyberamish.com ab...@cyberamish.com ro...@cyberamish.com postmaster@localhost postm...@tsf-marketing.com ab...@tsf-marketing.com ro...@tsf-marketing.com postm...@TSF-INDUSTRIES.COM ab...@TSF-INDUSTRIES.COM ro...@TSF-INDUSTRIES.COM in...@tsf-industries.com
st...@quantcom.com wa...@pwr.net au...@mci.savetrees.com postm...@answerme.cybermirror1.com postm...@ispam.net pri...@answerme.cybermirror1.com priv...@answerme.com priv...@answerme.cybermirror1.com priv...@mci.savetrees.com priv...@spamford.com ro...@answerme.cybermirror1.com st...@mci.savetrees.com sta...@mci.savetrees.com wal...@answerme.cybermirror1.com wal...@auto3.cybermirror1.com wal...@ispam.net wal...@mci.savetrees.com wal...@temp.cyberpromo.com docu...@agis.net ip-re...@agis.net rou...@agis.net ne...@agis.net accou...@agis.net in...@agis.net aa...@agis.net h...@agis.net ema...@qlink2info.com sim...@answerme.com off...@savetrees.com postm...@inreach.com ab...@inreach.com ro...@inreach.com hostm...@INREACH.COM a...@INREACH.COM postm...@EMAILDIRECT.NET ab...@EMAILDIRECT.NET ro...@EMAILDIRECT.NET postm...@e-bizness.com ab...@e-bizness.com ro...@e-bizness.com com...@IAW.ON.CA maxe...@UNITED-CBE.ORG dom...@EMAILDIRECT.NET
Wai Wong
I'm a hardworker, I have experience and talent... but who wants to work for
a moron who can't spell and laughs at other. Not me!
C. Chapman wrote in message <35A066...@aol.com>...
>-Then you may reply. Otherwise I'm laughing at all of you
Jerremy Koot
>I'm a hardworker, I have experience and talent... but who wants to work for
>a moron who can't spell and laughs at other. Not me!
Ed Humes
Jerremy Koot wrote in message ...
>Well, this ofcourse all depends on what the moron is paying....
Touche my friend!
Ed (who has worked for many stupid and rude people)
Bob Marley
experience are "peons" of programming. What it takes to make great games is
none of those things. Programming is so easy, it doesn't take talent. I'm a
network programmer at one of the biggest local area networks in Virginia,
and I know first hand on what "Hard Work" is, and let me tell you, making
games is a walk in the friggin' park.
Experience - no, not in my day. I may have experience, but i've seen many
young people pass through my company's door, and make a solid program even I
could appreciate. But I have to admit, I do look down on Visual Basic
programmers.
Design - yes, marketing - no. When you do get something called
"experience", you try to advance in company buisness, which means you take
pride in your company, and aren't looking to make a quick buck off of them.
Any applications I make are for my company to do what they desire with,
period.
John Mancine
Bob Marley wrote in message <6q53u2$nae$1...@Skuzzy.cstone.net>...
> It sounds to me like you are suggesting that people with no work
>experience are "peons" of programming. What it takes to make great games is
>none of those things. Programming is so easy, it doesn't take talent. I'm a
>network programmer at one of the biggest local area networks in Virginia,
>and I know first hand on what "Hard Work" is, and let me tell you, making
>games is a walk in the friggin' park.
Maybe i missed something. Are you being serious?
Pretty embarassing if you are.
JRM
Paul Hill
>network programmer at one of the biggest local area networks in Virginia,
>and I know first hand on what "Hard Work" is, and let me tell you, making
>games is a walk in the friggin' park.
Oh yeah?
Building a buisness application:
1) Write the spec
2) type the code in
Building a game:
1) Write the spec
2) design levels, innovative and intuitive visual interfaces, hundreds of
original artwork, sounds, a sotryline, puzzles etc.
3) write the code
4) test, play, test,play, teste the code
6) goto 4 until your insanity hits breaking point or the publisher threatens
to break your knees
7) Ship the code and pray that people 'get' it.
Writing code that people have to use is a hell of a lot easier than writing
code that you hope people will spend precious money on.
(snippy snippy)
>could appreciate. But I have to admit, I do look down on Visual Basic
>programmers.
>
Good code and bad code are written by good and bad programmers. I
personally would rather cut my ears off than write code in VB, but that's
only because it's paradigm drives me crazy. I would say it's this message,
rather than the medium, that counts.
(snippity-snip)
>pride in your company, and aren't looking to make a quick buck off of them.
>Any applications I make are for my company to do what they desire with,
>period.
Probably why so much business software is cack then. Cobbled together
comittee-designed peice of rubbish that eats LAN space and doesn't do a damn
thing the user wants.
Sorry, but business software is a doddle to write compared to games. Anyone
disagree?
anonymous
<6q53u2$nae$1...@Skuzzy.cstone.net>...
> It sounds to me like you are suggesting that people with no work
> experience are "peons" of programming. What it takes to make great games
is
> none of those things. Programming is so easy, it doesn't take talent. I'm
a
> and I know first hand on what "Hard Work" is, and let me tell you, making
> games is a walk in the friggin' park.
Wow! What a revelation. I guess I better go wake up my cube neighbor and
tell him that making games is a "walk in the friggin' park". Then again,
maybe I won't. You see, he's fallen asleep amidst a pile of calculus and
trig books. He's been working on the physics for a game that's has to be
released in 2 months. We're trying to do something that's never been done
before, in record time, and on a budget - so we work 12-14 hours a day.
Sometimes more. Thank got we have a kitchen, a shower, and some couches to
sleep on, otherwise we'd have to go home more often, eating in to our
precious "walk in the friggin' park" time.
I guess it would all be a lot easier if we had guys like you around; guys
who know what "Hard Work" is. Hell, we could use a good network programmer
- but you'd better be able to double as an AI programmer, 3D graphics
programmer, a sound programmer, and a....
Rob Wilson
As a programmer from the Amiga days, I would like to say that
programming games on the PC is alot more difficult, but applications
programming was a 'doddle'.
The person who started this thread should support his claim by putting
a game that he has written in an accessible place for us to determine
if he is right, something tells me that all we will find is a business
application of some sort.
I have to disagree with him strongly, games programming is an art,
utilising skills in diverse areas and lots of research, application
programming has a different skill, but alot more people can do it...
including me!
Rob.
Paul Hill
>network programmer at one of the biggest local area networks in Virginia,
>and I know first hand on what "Hard Work" is, and let me tell you, making
>games is a walk in the friggin' park.
Mitchell Morris
>Didn't see the original mail, but I take exception to this
>
>>network programmer at one of the biggest local area networks in Virginia,
>>and I know first hand on what "Hard Work" is, and let me tell you, making
>>games is a walk in the friggin' park.
>
>
>Oh yeah?
>Building a buisness application:
>1) Write the spec
>2) type the code in
[snip]
>Sorry, but business software is a doddle to write compared to games. Anyone
>disagree?
Okay, I'll bite. I'll write the spec for a business application, and you
"type the code in"
SPECIFICATION:
* Runs native under Linux, using the Motif 2.0 libraries for interface.
* Looks, acts, smells, feels exactly like Quicken including binary
file compatibility.
I'll wait while you type.
--
Mitchell Morris
mmo...@mindspring.com
A door is what a dog is perpetually on the wrong side of.
-- Ogden Nash
Acy James Stapp
Paul Hill wrote:
> Didn't see the original mail, but I take exception to this
>
> >network programmer at one of the biggest local area networks in Virginia,
> >and I know first hand on what "Hard Work" is, and let me tell you, making
> >games is a walk in the friggin' park.
>
> Oh yeah?
> Building a buisness application:
> 1) Write the spec
> 2) type the code in
1) Write the spec
2) Design templates, innovative and intuitive visual interfaces, hundreds
of original sample documents, etc.
3) write the code
4) test, work, test, work, test the code
5) (huh?) goto 4 until your insanity hits the breaking point or your employer
threatens to break your knees.
6) Write a manual even an idiot could understand
7) Goto 6 until the idiot can understand it
8) Ship the code and pray that the idiots out there 'get' it.
>
>
>
> Building a game:
> 1) Write the spec
> 2) design levels, innovative and intuitive visual interfaces, hundreds of
> original artwork, sounds, a sotryline, puzzles etc.
> 3) write the code
> 4) test, play, test,play, teste the code
> 6) goto 4 until your insanity hits breaking point or the publisher threatens
> to break your knees
> 7) Ship the code and pray that people 'get' it.
>
> Writing code that people have to use is a hell of a lot easier than writing
> code that you hope people will spend precious money on.
>
> (snippy snippy)
>
> >could appreciate. But I have to admit, I do look down on Visual Basic
> >programmers.
> >
>
> Good code and bad code are written by good and bad programmers. I
> personally would rather cut my ears off than write code in VB, but that's
> only because it's paradigm drives me crazy. I would say it's this message,
> rather than the medium, that counts.
>
> (snippity-snip)
>
> >pride in your company, and aren't looking to make a quick buck off of them.
> >Any applications I make are for my company to do what they desire with,
> >period.
>
> Probably why so much business software is cack then. Cobbled together
> comittee-designed peice of rubbish that eats LAN space and doesn't do a damn
> thing the user wants.
Just like so much game software. The reason there are so many more games
is because games are much, much easier to write. And they have much
more limited reusability.
>
>
>
> Sorry, but business software is a doddle to write compared to games. Anyone
> disagree?
>
Yes. Writing games may be more interllectually challenging than
some business software (but not all, by any means), but it's no
harder in terms of the time and effort you put into it.
I think perhaps youd better work on equal-quality business and game
applications before passing judgement like this.
--
Acy James Stapp - Slam Software - Amp 3D Engine
ast...@slamsoftware.com http://www.slamsoftware.com
--
From the 1992 Presidential Campaign
Reporter: "Have you ever had an extramarital affair, governor [Clinton]?"
Clinton: "If I had, I wouldn't tell you."
Phantom
> > It sounds to me like you are suggesting that people with no work
> >experience are "peons" of programming. What it takes to make great games is
> >none of those things. Programming is so easy, it doesn't take talent. I'm a
> >and I know first hand on what "Hard Work" is, and let me tell you, making
> >games is a walk in the friggin' park.
Writing games in the Win32 environment isnt "hard" per se, but I can tell you
its no 'walk in the friggin' park'. Business apps are generally designed around
tested and tried ideas, whereas any worthy game has to be cutting-edge to even
get noticed. You are correct in saying that Programming doesnt take talent, but
GOOD programming takes MOUNDS of talent. I've seen "professional" programmers
write code that i'd puke on just looking at. The only programming task I'd
compare with writing games is writing an OS (which in my opinion is a much more
involved task than any game (that is, if its a well made OS)). Other than that,
nothing else is even close.
Phantom
Michel Huot
>
> It sounds to me like you are suggesting that people with no work
> experience are "peons" of programming. What it takes to make great games is
> none of those things. Programming is so easy, it doesn't take talent. I'm a
> network programmer at one of the biggest local area networks in Virginia,
> and I know first hand on what "Hard Work" is, and let me tell you, making
> games is a walk in the friggin' park.
>
> young people pass through my company's door, and make a solid program even I
> programmers.
You are talking as if every game programmers were VB programmers and/or
were using
some all-done-yet 3D library(DirectX, OpenGL...), or doing
(relatively)simple 2D games
like there was 5 years ago. But its really a lot of work to get a 3d
engine working
above 50 frame per second on a 486-33mhz. I am talking here about angled
wall/floor/ceiling stuff, where everything can have variable height, not
like old
Wolfenstein 3d(this was *very* good a few years ago). Programming a game
is hard,
because you have to make a 3d engine, a sound engine, [...] and write AI
to have
*intelligent* looking ennemies. Its really a big task.
Regards, Simon
Justin Heyes-Jones
(Mitchell Morris) wrote:
>On Tue, 4 Aug 1998 15:03:41 +0100, Paul Hill <not.giving.it.cos.of.spam> wrote:
>>Didn't see the original mail, but I take exception to this
>>
>Okay, I'll bite. I'll write the spec for a business application, and you
>"type the code in"
>
>SPECIFICATION:
> * Runs native under Linux, using the Motif 2.0 libraries for interface.
> * Looks, acts, smells, feels exactly like Quicken including binary
> file compatibility.
That's the equivalent of doing a conversion, like we do in games quite
often. For example some guys I know were given an arcade machine, an
assembler and 6 months to do a conversion with no code and no spec
other than the arcade machine.
Now writing Quicken for Linux with no code is a pretty easy task,
since you can simply build a detailed design up by using Quicken.
There's nothing hard or unknown to do in an accounts package surely.
In games it's often impossible to provide a detailed program design
because so much has to be learnt and experimented with on the way.
I'm sure there are programming jobs that are more complex than writing
games, such as medical or engineering software. But re-writing and
exisiting personal finance package just dosn't sound hard.
Justin Heyes-Jones, just...@hotmail.com.
Mitchell Morris
wrote:
>On Tue, 4 Aug 1998 17:20:26 +0100 , m...@unpkhswm04.bscc.bls.com
>(Mitchell Morris) wrote:
>
>>On Tue, 4 Aug 1998 15:03:41 +0100, Paul Hill <not.giving.it.cos.of.spam> wrote:
>>>Didn't see the original mail, but I take exception to this
>>>
>>Okay, I'll bite. I'll write the spec for a business application, and you
>>"type the code in"
>>
>>SPECIFICATION:
>> * Runs native under Linux, using the Motif 2.0 libraries for interface.
>> * Looks, acts, smells, feels exactly like Quicken including binary
>> file compatibility.
>
>That's the equivalent of doing a conversion, like we do in games quite
>often. For example some guys I know were given an arcade machine, an
>assembler and 6 months to do a conversion with no code and no spec
>other than the arcade machine.
[lucid commentary snipped]
My point was that there is, in both entertainment and business software,
no project where the spec is set in stone and some person "types the code in."
I chose that particular example precisely because it represents as stable
a specification as you could hope for, but the stability of the spec
provides you no real advantage in trivializing the implementation. The original
poster, Paul Hill, wanted to trivialize business application implementation,
and I wanted to provide a counter-example.
The true difference between developing business applications and entertainment
applications is in the culture and tools. I could laboriously write a sprite
engine over a (relatively) long period of time, whereas an experienced game
developer could toss one out in a day. On the other hand, I can generate
a socket-based multiplexing proxy filter off the top of my head in a single
day, but I suspect that there aren't many games that require that sort of
thing.
To put it another way, an experienced game developer would be just as lost in
my job as I would be in his.
+Mitchell
--
Mitchell Morris
mmo...@mindspring.com
If you make people think they're thinking, they'll love you; but if you
really make them think they'll hate you.
Justin Heyes-Jones
(Mitchell Morris) wrote:
>To put it another way, an experienced game developer would be just as lost in
>my job as I would be in his.
>[lucid commentary snipped]
I'd hardly call it lucid. ;-)
Programming is programming and software is software. Granted you may
be able to write your proxy sprogget arse thing in a day while it
would take me a while to get up to speed in your realm of no doubt
extremely complex network programming.
But programming is solving problems and learning new technologies
whether you work for IBM or Electronic Arts.
Saying that one is harder than the other is like saying that building
houses is harder than building shops.
Justin Heyes-Jones, just...@hotmail.com.
Uknown Programmer
Write a Spec for the product
Estimate 6 months to write
Customer modifies spec 1 month into project
Due date unchanged but now almost 1 month behind
Customer modifies spec 2 1'/2 months into project
Have to backtrack 1/2 month while hitting the same due date.
etc
This goes on and on, its called Spec Creep and happens quite frenquently,
Try programming a business app where your patching and patching and
patching
since the customer wants the changes implemented yesterday, then you have
to
attempt to correct all the patches in what little time you have left and
finish the task.
NOT Real fun and in reality the patches never get properly fixed most
times.
--
...SPAM PROTECTION IN EFFECT....
Frank Shapiro
Real Email is: shapiro_ at yahoo.com
Paul Hill <not.giving.it.cos.of.spam> wrote in article
<#Xe6yJ7v...@uppssnewspub05.moswest.msn.net>...
> Didn't see the original mail, but I take exception to this
>
> >network programmer at one of the biggest local area networks in
Virginia,
> >and I know first hand on what "Hard Work" is, and let me tell you,
making
> >games is a walk in the friggin' park.
>
>
> Oh yeah?
> Building a buisness application:
> 1) Write the spec
> 2) type the code in
>
> Building a game:
> 1) Write the spec
> 2) design levels, innovative and intuitive visual interfaces, hundreds of
> original artwork, sounds, a sotryline, puzzles etc.
> 3) write the code
> 4) test, play, test,play, teste the code
> 6) goto 4 until your insanity hits breaking point or the publisher
threatens
> to break your knees
> 7) Ship the code and pray that people 'get' it.
>
> Writing code that people have to use is a hell of a lot easier than
writing
> code that you hope people will spend precious money on.
>
> (snippy snippy)
>
> >could appreciate. But I have to admit, I do look down on Visual Basic
> >programmers.
> >
>
>
> Good code and bad code are written by good and bad programmers. I
> personally would rather cut my ears off than write code in VB, but that's
> only because it's paradigm drives me crazy. I would say it's this
message,
> rather than the medium, that counts.
>
> (snippity-snip)
>
> >pride in your company, and aren't looking to make a quick buck off of
them.
> >Any applications I make are for my company to do what they desire with,
> >period.
>
>
> Probably why so much business software is cack then. Cobbled together
> comittee-designed peice of rubbish that eats LAN space and doesn't do a
damn
> thing the user wants.
>
Paul Hill
> * Runs native under Linux, using the Motif 2.0 libraries for interface.
> * Looks, acts, smells, feels exactly like Quicken including binary
> file compatibility.
>
Well that's a typical business spec (ie a load of cobblers) but as to
writing that, it would be dead easy.
Much easier, than, for example, porting a game written in DirectX to a
PlayStation.
I would have had the binary file on the table by now, the algorthims are
simple adding up, and XLib is massively simpler than DirectX to 'do'.
I've written buisness software - it's a doddle.
Paul Hill
Acy James Stapp wrote in message <35C7436A...@io.com>...
(chop chop)
>> >games is a walk in the friggin' park.
>>
>> Oh yeah?
>> Building a buisness application:
>> 1) Write the spec
>> 2) type the code in
>
>1) Write the spec
>2) Design templates, innovative and intuitive visual interfaces, hundreds
>of original sample documents, etc.
Er.. pardon me but I thought innovative business UI's is actually a Bad
Thing. a modern GUI design usually has a rather fervent bible that tells me
this. And it's a bit easier knocking up a monkey program for a business
app, even a big one, than it is for a game.
>3) write the code
Run AppWizard (or whatever), draw some functional dialog-boxes and ship.
>4) test, work, test, work, test the code
Or ship it and pretend it's the 'crappy' OS that's causing the problem (are
you listening Lotus? What about you, Symantec? )
>5) (huh?) goto 4 until your insanity hits the breaking point or your
employer
The 5 key doesn't work on my keyboard. Oh hang on, it does. Hurrahh!!
>threatens to break your knees.
>6) Write a manual even an idiot could understand
>7) Goto 6 until the idiot can understand it
Why bother? end-users, at best, beleive the manual to be an elaborate form
of packing.
>8) Ship the code and pray that the idiots out there 'get' it.
Cos if they don't, you suffer how exactly? Consider the following logic
flow:
I need to do something -> I'll use a computer -> I need to get some
software -> This'll do
Now compare:
I'm bored -> hey this game looks good -> I'll buy it (or, sadly in the PC
industry, pirate it)
>
>>
>>
>>
>> Building a game:
>> 1) Write the spec
>> 2) design levels, innovative and intuitive visual interfaces, hundreds of
>> original artwork, sounds, a sotryline, puzzles etc.
>> 3) write the code
>> 4) test, play, test,play, teste the code
>> 6) goto 4 until your insanity hits breaking point or the publisher
threatens
>> to break your knees
>> 7) Ship the code and pray that people 'get' it.
>>
(cerrrrr-chunk)
>Just like so much game software. The reason there are so many more games
>is because games are much, much easier to write. And they have much
>more limited reusability.
>
Untrue. The most popular language (based on lines of code) is still our old
friend COBOL. I imagine not much games software since Hunt the Wampus has
been written in this old geezer.
And as for reusability, let me count the number of Quake-engine clones out
there...
And, BTW
>>
>>
>>
>> Sorry, but business software is a doddle to write compared to games.
Anyone
>> disagree?
>>
>
>Yes. Writing games may be more interllectually challenging than
>some business software (but not all, by any means), but it's no
>harder in terms of the time and effort you put into it.
>
>I think perhaps youd better work on equal-quality business and game
>applications before passing judgement like this.
>
Been there, done that. I'm not saying business software is easy to write
(all programming is bloody hard, and massivley underpaid), but writing
business software is a hell of a lot easier cos as long as it runs OK and
looks nice and fulfills a business need it's done. Games-writing is a
creative act, and the main reason I switched is because (to paraphrase Andy
Hertzfield) 'I don't want to churn out workmanlike code for creepy bosses in
suits' any more.
Matt Craighead
> Actually having done both let me explain the reality of business apps,
> Write a Spec for the product
> Estimate 6 months to write
> Customer modifies spec 1 month into project
> Due date unchanged but now almost 1 month behind
> Customer modifies spec 2 1'/2 months into project
> Have to backtrack 1/2 month while hitting the same due date.
> etc
>
> This goes on and on, its called Spec Creep and happens quite frenquently,
> Try programming a business app where your patching and patching and
> patching
> since the customer wants the changes implemented yesterday, then you have
> to
> attempt to correct all the patches in what little time you have left and
> finish the task.
> NOT Real fun and in reality the patches never get properly fixed most
> times.
Are you sure we don't work at the same company?
--
Matt Craighead
Engineer, Window Painters, Ltd.
http://www.windowpainters.com
hoze
bud.................................
--
Joe Hughes
Muffler Bearing Specialist
j...@doomsdaySoftware.com
http://www.doomsdaysoftware.com/
"10:15 on a Saturday night....."
Javier Arevalo
>Sorry, but business software is a doddle to write compared to games. Anyone
>disagree?
I'd say that there are some quite complex pieces of business software.
The whole production problem of games (i.e. every element is somehow
tied together with everything else, so you have to iterate through
them all several times) is usually higher. Writing the spec for a game
is an art still in its infancy, because only a few people can envision
what a game will be before it's built.
On the other hand, quite some areas of business software development
have other problems: safety (who cares if your game crashes from time
to time? But a bank HAS to open its branches every morning),
interaction with low-tech high-power decision-making people (yeah
there's some in the games industry but not quite as close as those in
business); and lack of fun, passion and motivation to make it slightly
better than you thought you could.
Greets
Javier Arevalo
http://web.jet.es/jare
change nospam to jare in the address to send email
Javier Arevalo
>He's been working on the physics for a game that's has to be
>released in 2 months. We're trying to do something that's never been done
>before, in record time, and on a budget - so we work 12-14 hours a day.
You recognize that's not "a harder task", it's just improper resource
allocation. Which, true, makes it harder, but not because of the task
itself.
Banks don't play (not too much) with budgets when it comes to
rebuilding their accounting applications. They won't be lured by the
idea of pulling it off in half the time and with innovative
techniques; they would call that not "cool", but "unnecessarily
risky".
Daniel J. Dolz
(Mitchell Morris) wrote:
>On Wed, 5 Aug 1998 09:02:37 +0100, Justin Heyes-Jones <non...@nowhere.com>
>wrote:
>>On Tue, 4 Aug 1998 17:20:26 +0100 , m...@unpkhswm04.bscc.bls.com
>>(Mitchell Morris) wrote:
>>
>>>On Tue, 4 Aug 1998 15:03:41 +0100, Paul Hill <not.giving.it.cos.of.spam> wrote:
>>>>Didn't see the original mail, but I take exception to this
>>>>
>>>Okay, I'll bite. I'll write the spec for a business application, and you
>>>"type the code in"
>>>
>>>SPECIFICATION:
>>> * Runs native under Linux, using the Motif 2.0 libraries for interface.
>>> * Looks, acts, smells, feels exactly like Quicken including binary
>>> file compatibility.
>>
>>That's the equivalent of doing a conversion, like we do in games quite
>>often. For example some guys I know were given an arcade machine, an
>>assembler and 6 months to do a conversion with no code and no spec
>>other than the arcade machine.
>
>[lucid commentary snipped]
>
>My point was that there is, in both entertainment and business software,
>no project where the spec is set in stone and some person "types the code in."
>I chose that particular example precisely because it represents as stable
>a specification as you could hope for, but the stability of the spec
>provides you no real advantage in trivializing the implementation. The original
>poster, Paul Hill, wanted to trivialize business application implementation,
>and I wanted to provide a counter-example.
>
>The true difference between developing business applications and entertainment
>applications is in the culture and tools. I could laboriously write a sprite
>engine over a (relatively) long period of time, whereas an experienced game
>developer could toss one out in a day. On the other hand, I can generate
>a socket-based multiplexing proxy filter off the top of my head in a single
>day, but I suspect that there aren't many games that require that sort of
>thing.
>
>To put it another way, an experienced game developer would be just as lost in
>my job as I would be in his.
>
>+Mitchell
>
>--
>Mitchell Morris
>mmo...@mindspring.com
>
>If you make people think they're thinking, they'll love you; but if you
>really make them think they'll hate you.
>
Well, I have to agree with you this time.
Daniel J. Dolz
Morris) wrote:
>On Tue, 4 Aug 1998 15:03:41 +0100, Paul Hill <not.giving.it.cos.of.spam> wrote:
>>Didn't see the original mail, but I take exception to this
>>
>>>network programmer at one of the biggest local area networks in Virginia,
>>>and I know first hand on what "Hard Work" is, and let me tell you, making
>>>games is a walk in the friggin' park.
>>
>>
>>Oh yeah?
>>Building a buisness application:
>>1) Write the spec
>>2) type the code in
>
>[snip]
>
>>Sorry, but business software is a doddle to write compared to games. Anyone
>>disagree?
>
>Okay, I'll bite. I'll write the spec for a business application, and you
>"type the code in"
>
>SPECIFICATION:
> * Runs native under Linux, using the Motif 2.0 libraries for interface.
> * Looks, acts, smells, feels exactly like Quicken including binary
> file compatibility.
>
>I'll wait while you type.
>
>--
>Mitchell Morris
>mmo...@mindspring.com
>
>A door is what a dog is perpetually on the wrong side of.
> -- Ogden Nash
Oh yes? Your org should learn to write specs then. Maybe some reading
will help. You see, sometimes you need a bit of theoretichal basis.
What is that "looks, acts". The example is of no use even if you try
to see its funny side.
1.- write a correct, understandable, easy to check, rigorous spec.
It愀 only a medium brainer work, once you got the understanding of
what you want to do.
2.- write the code.
Game programming is far more dificult, and challenging.
Daniel Dolz
dd...@uncoma.edu.ar
Justin Heyes-Jones
LOL. Maybe there is no difference between game and business software
development.
Justin Heyes-Jones, just...@hotmail.com.
Scott Hill
> Bob Marley wrote:
> >
> > It sounds to me like you are suggesting that people with no work
> > experience are "peons" of programming. What it takes to make great
games is
> > none of those things. Programming is so easy, it doesn't take talent.
I'm a
Virginia,
> > and I know first hand on what "Hard Work" is, and let me tell you,
making
> > games is a walk in the friggin' park.
> >
>
> engine working
> above 50 frame per second on a 486-33mhz...
> ...Programming a game
> is hard, because you have to make a 3d engine, a sound engine, [...] and
write AI
> to have *intelligent* looking ennemies. Its really a big task.
>
But, once you have a 3D engine, you have a 3D engine, once you have a
sound engine, you have sound engine and so on. OK, you have to do tweaks
when new hardware (3d accelerators, sound cards, what ever) comes out, and
to keep with the current trends, but you should just be able to tweak and
adjust to suit your new game.
Now, maybe once in a while (every couple of years ?) you need to do a
complete re-write of your 3d engine to get the nice new effects into it,
but all 3d-engines are based around the same algorithms, pushing the same
kinds of data around in the same kind of ways so, in effect, you've already
done all the hard work before.
Of, course just the same is true of application programming. I'm not
saying one is easier or harder than the other just that they're two
different kettles of fish, they both require different skills and
abilities, your average, reasonably good, application developer should be
able to knock up a basic, but good, game in no time, and your average,
reasonably good, game developer should be able to knock up a basic, but
good, application in no time, but, creating that 'killer' app is just as
hard as creating that 'killer' game.
--
Scott Hill
Sc...@DDLinks.co.uk
Software Engineer (and all round nice guy)
Company homepage : http://www.ddlinks.demon.co.uk
"The best trick the devil ever pulled was convincing people he didn't
exist..."
- Verbal Kint.
"the Internet is here so we can waste time talking about nothing in
particular when we should be working" - Marcus Hill.
Mitchell Morris
[snip]
>Oh yes? Your org should learn to write specs then. Maybe some reading
>will help. You see, sometimes you need a bit of theoretichal basis.
^^^^^^^^^^^^
You misspelled "I'm still learning how to use a dictionary".
>What is that "looks, acts". The example is of no use even if you try
>to see its funny side.
>
>1.- write a correct, understandable, easy to check, rigorous spec.
>It愀 only a medium brainer work, once you got the understanding of
>what you want to do.
>2.- write the code.
>
>Game programming is far more dificult, and challenging.
>
>Daniel Dolz
>dd...@uncoma.edu.ar
That is a complete specification for a conversion process. When you are done,
you will have an application that performs all functions exactly like Quicken.
This is correct, understandable, easy to check, and rigorous.
I'm still waiting for Paul Hill and/or you to, and I'm quoting here,
"type the code in."
I realize you would like to claim that business programming is a trivial
endeavor, but your criticism demonstrates the worst kind of parochialism.
Problem solving is the only real talent any programmer brings to the
project, and you may rest assured that there are whole stacks of them inherent
to business application development that you haven't yet seen.
YHBFB. YHL. HAND.
--
Mitchell Morris
mmo...@mindspring.com
A Law of Computer Programming:
Make it possible for programmers to write in English and you
will find the programmers cannot write in English.
Mitchell Morris
[snip]
>Well that's a typical business spec (ie a load of cobblers) but as to
^^
You misspelled "my brain is".
>writing that, it would be dead easy.
>
>Much easier, than, for example, porting a game written in DirectX to a
>PlayStation.
>
>I would have had the binary file on the table by now, the algorthims are
^^^^^^^^^^
You misspelled "trivial math portions".
>simple adding up, and XLib is massively simpler than DirectX to 'do'.
>
>I've written buisness software - it's a doddle.
^^^^^^^^
You misspelled "shoddy".
I supplied you with a spec; in fact, this spec is so dead simple that
you will have no problem at all knowing when you're finished. I'm just
waiting for you to "type the code in".
Oh wait ... you mean there's more to it that just sitting down and
pushing the keys? Dang, where was *THAT* step listed in your process?
Maybe some verification is in order? Dang, that step isn't there
either. What about the part where you have to send the manual off the
printer? Or the part where the box art which includes the bullet list
of current buzzword-compliant features is sent to manufacturing? Hmm
... it seems as if there are whole bunch of steps that have to be followed
irrespective of the business/game nature of the software.
By the way, I've written game software - it's a doddle.
Somehow, that sort of assertion carries no real weight without some evidence
to back it up.
YHBFB. HAND.
--
Mitchell Morris
mmo...@mindspring.com
Do not meddle in the affairs of troff, for it is subtle and quick to
anger.
Stephen Macdonald
<nos...@jet.es> writes
>You recognize that's not "a harder task", it's just improper resource
>allocation. Which, true, makes it harder, but not because of the task
>itself.
So designing a nuclear power plant is not "a harder task" than sweeping
the streets, its just a "resource allocation" problem because the street
sweeper doesn't know anything about nuclear power plants.
Ahh, now I understand. Thankyou for pointing that out.
GAL.
(no offence intended to street sweepers :-)
--
Stephen Macdonald
Acy James Stapp
Paul Hill wrote:
> Acy James Stapp wrote in message <35C7436A...@io.com>...
>
> (chop chop)
>
> >> >games is a walk in the friggin' park.
> >>
> >> Oh yeah?
> >> Building a buisness application:
> >> 1) Write the spec
> >> 2) type the code in
> >
> >1) Write the spec
> >2) Design templates, innovative and intuitive visual interfaces, hundreds
> >of original sample documents, etc.
>
> Er.. pardon me but I thought innovative business UI's is actually a Bad
> Thing. a modern GUI design usually has a rather fervent bible that tells me
> this.
>
Yes, unless you're Microsoft and you get to completely ignore all of
your own design conventions and come up with new ones each time
you ship another product.
> And it's a bit easier knocking up a monkey program for a business
> app, even a big one, than it is for a game.
This could be debated for hours. You seem to be forgetting a huge
class of vertical market applications with strict performance and
reliability requirements; notably banking, industrial control, and
medical device applications where a bug could result in massive
loss of money or life. Sure, there are a lot of horizontal (and
vertical) market applications that are poorly written. There are
also a lot of games that are poorly written. Quality takes time
and effort. Markets in which standardized buying practicees
based on intensive discounts (institutional productivity software
like word processors, etc comes to mind) practically scream for
low quality. Marekts in which quality is important (individual
sales of any application (which can be returned), vertical market
sales, and sales to limited market (where it's important to
maintain good reputation)) _are_ harder to write software for.
>
>
>
>
>
> >3) write the code
>
> Run AppWizard (or whatever), draw some functional dialog-boxes and ship.
>
Yeah, good luck getting an application running that way.
> >4) test, work, test, work, test the code
>
> Or ship it and pretend it's the 'crappy' OS that's causing the problem (are
> you listening Lotus? What about you, Symantec? )
>
<RANT>
Microsoft: "Mr. DOJ attorney, we have documents proving that all along,
we've planned to integrate Microsoft Word, Excel, Internet Explorer,
Microsoft AntiVirus and Microsoft Coffee Maker into Windows all along."
Windows exists because MS wanted a GUI and DOS extender for Word.
Even now, much of the new functionality added to windows is because
of new applications.
In order to remain competitive with Microsoft's products, competitors
need to use functionality that was specifically designed to be used
in Microsoft's products and in many cases isn't fully implemented.
(DirectX is an exception here; I'm specifically referring to the new
common controls).
</RANT>
OTOH, if the application crashes
A. It's the OS fault, but they should have worked around bugs in the OS or
B. It's the application's fault.
If it brings down the OS, then it's the OS fault.
> >6) Write a manual even an idiot could understand
> >7) Goto 6 until the idiot can understand it
>
> Why bother? end-users, at best, beleive the manual to be an elaborate form
> of packing.
>
I do agree with this. Mostly it's because users have learned that
software makers skip step 7. Witness the proliferation of Dummies (tm)
books. Would they even exist if technical writers for application
vendors did their jobs? No.
Writing manuals is expensive and doesn't help sales that much,
even though it's a sign of quality software.
> >8) Ship the code and pray that the idiots out there 'get' it.
>
> Cos if they don't, you suffer how exactly? Consider the following logic
> flow:
>
> I need to do something -> I'll use a computer -> I need to get some
> software -> This'll do
>
> Now compare:
>
> I'm bored -> hey this game looks good -> I'll buy it (or, sadly in the PC
> industry, pirate it)
Huh?
I need to do something (I'm bored/I need to get paid) ->I'll use a computer
-> I need to get some software -> This looks like it fills my needs ->
I'll buy it (or pirate it)
What's the difference?
> >Just like so much game software. The reason there are so many more games
> >is because games are much, much easier to write. And they have much
> >more limited reusability.
> >
>
> Untrue. The most popular language (based on lines of code) is still our old
> friend COBOL. I imagine not much games software since Hunt the Wampus has
> been written in this old geezer.
COBOL is an application. It has good reusability.
> And as for reusability, let me count the number of Quake-engine clones out
> there...
Most individual games have a limited lifetime (maybe 100 or 200 hours at most).
Most applications are used for thousands of hours (if not tens of
thousands)
> Been there, done that. I'm not saying business software is easy to write
> (all programming is bloody hard, and massivley underpaid), but writing
> business software is a hell of a lot easier cos as long as it runs OK and
> looks nice and fulfills a business need it's done. Games-writing is a
> creative act, and the main reason I switched is because (to paraphrase Andy
> Hertzfield) 'I don't want to churn out workmanlike code for creepy bosses in
> suits' any more.
I guess I'm lucky to only have worked with non-creepy bosses in suits.
How about this one "Writing game software is a hell of a lot easier cos
as long as it runs OK and looks nice and fulfills an entertainment need
it's done". Is that untrue? Maybe writing games is harder for you because
it interests you more and you're willing to expend more energy on it?
I certainly feel it's much easier to work 100 hours/wk on a 3D engine
than to work 100 hours out of town, living out of a hotel, doing an
installation for a product that had to be installed and tested two
weeks late because of delinquent hardware vendors and having
someone breathing down your neck telling you that it has to work
and "oh, we forgot this essential functionality" etc.
Obviously, your idea of business software is "a walk in the park" or
"churning out workmanlike code for creepy bosses". I guess
"churning out workmanlike code for yourself or for some pissy
producer" wouldn't be a walk in the park?
Stephen Macdonald
writes
>I certainly feel it's much easier to work 100 hours/wk on a 3D engine
>than to work 100 hours out of town, living out of a hotel, doing an
>installation for a product that had to be installed and tested two
>weeks late because of delinquent hardware vendors and having
>someone breathing down your neck telling you that it has to work
>and "oh, we forgot this essential functionality" etc.
I think you've missed the point.
The original argument started because somebody felt compelled to
counter-argue the fact that writing business applications was harder
than writing games.
The reference to "harder" was undoubtedly made with respect to the
technical complexity of the task, and *not* the desirability of the
task.
I know a few games programmers. All of them have sufficient computer
science backgrounds that they could turn their skills toward developing
state-of-the-art business applications (it may take them longer than
someone who always practises in this field, but they can do the job).
I know a LOT of business applications programmers. I don't know very
many of them who could turn their skills towards developing state-of-
the-art 3D games the like of which are seen in your average amusement
arcade these days - regardless of how much time or money you gave them,
or how interesting they found it. It would just be too technically
demanding for them.
--
Stephen Macdonald
Acy James Stapp
Stephen Macdonald wrote:
>
>
>
> I think you've missed the point.
probably
>
>
>
> The original argument started because somebody felt compelled to
> counter-argue the fact that writing business applications was harder
> than writing games.
>
> The reference to "harder" was undoubtedly made with respect to the
> technical complexity of the task, and *not* the desirability of the
> task.
>
> I know a few games programmers. All of them have sufficient computer
> science backgrounds that they could turn their skills toward developing
> state-of-the-art business applications (it may take them longer than
> someone who always practises in this field, but they can do the job).
>
> I know a LOT of business applications programmers. I don't know very
> many of them who could turn their skills towards developing state-of-
> the-art 3D games the like of which are seen in your average amusement
> arcade these days - regardless of how much time or money you gave them,
> or how interesting they found it. It would just be too technically
> demanding for them.
I agree.
I think a lot of this is because of the desirability of game programming.
Game employers can be a lot more selective because of the limited market,
preventing crappy programmers from entering the field (and forcing them
into the much larger business programming market)
Michael Buck
: In article <6qbdpm$o5j$1...@excalibur.flash.net>, Javier Arevalo
: <nos...@jet.es> writes
: >You recognize that's not "a harder task", it's just improper resource
: >allocation. Which, true, makes it harder, but not because of the task
: >itself.
: So designing a nuclear power plant is not "a harder task" than sweeping
: the streets, its just a "resource allocation" problem because the street
: sweeper doesn't know anything about nuclear power plants.
: Ahh, now I understand. Thankyou for pointing that out.
I think you missed the point. The "improper resource allocation"
mentioned in the original post had to do with an arbitrarily imposed
deadline, I believe, not on the supposed difficulty of designing the
software. So, the point was that there weren't enough resources
dedicated to the project to finish it by the deadline imposed.
Michael Buck
mb...@ix.netcom.com
mb...@netcom.com
Chris Marriott
Acy James Stapp wrote in message <35C9F4D0...@io.com>...
>
>I think a lot of this is because of the desirability of game programming.
>Game employers can be a lot more selective because of the limited market,
>preventing crappy programmers from entering the field (and forcing them
>into the much larger business programming market)
Hmmm. Not sure I see that game programming *is* particularly desirable, but
perhaps that's just a personal view!
I make my living from writing astronomy software, and for me the
"excitement" comes from the complex "mathematical modelling" aspect of the
work. It's VERY satisfying, for example, to take a series of mathematical
equations representing the orbits of the satellites of Saturn from an
obscure astronomical journal, and convert those equations into a program
which shows the satellites orbiting the planet. It's even MORE satisfying to
be able to get out my telescope, look at Saturn, and SEE those satellites in
the exact positions which my code has predicted.
I'm certainly not trying to sound in any way "snobbish" here, but I guess
I've just never seen the POINT of games; for me, modelling the "real
universe" is a lot more satisfying.
Regards,
Chris
-----------------------------------------------------------------------
Chris Marriott, SkyMap Software, UK (ch...@skymap.com)
Visit our web site at http://www.skymap.com
Astronomy software written by astronomers, for astronomers
Stephen Macdonald
writes
>I think you missed the point.
Yeah probably. Too many message routes in this damn thread now!
--
Stephen Macdonald
Steve Boynton
astronomy program, attempt to model reality. Take, for example, flight
simulators and the Close Combat series. These titles, while still
considered *games*, are actually *simulations*. An accurate simulation is
not a trivial coding challange. Converting the physical equations into
graphic form takes an understanding of complex math, among other things.
I don't know who started this insipid debate, but programming requires
logical thought no matter what the application. Anyone thinking themselves
superior for the *type* of programming they do is, IMHO, providing insight
into their own self image problems.
But what do I know? ;)
$.02
Chris Marriott wrote in message <902433967.27817.0.nnrp->Hmmm. Not sure I
Acy James Stapp
Chris Marriott wrote:
> Acy James Stapp wrote in message <35C9F4D0...@io.com>...
> >
> >I think a lot of this is because of the desirability of game programming.
> >Game employers can be a lot more selective because of the limited market,
> >preventing crappy programmers from entering the field (and forcing them
> >into the much larger business programming market)
>
> Hmmm. Not sure I see that game programming *is* particularly desirable, but
> perhaps that's just a personal view!
>
> I make my living from writing astronomy software, and for me the
> "excitement" comes from the complex "mathematical modelling" aspect of the
> work. It's VERY satisfying, for example, to take a series of mathematical
> equations representing the orbits of the satellites of Saturn from an
> obscure astronomical journal, and convert those equations into a program
> which shows the satellites orbiting the planet. It's even MORE satisfying to
> be able to get out my telescope, look at Saturn, and SEE those satellites in
> the exact positions which my code has predicted.
>
> I'm certainly not trying to sound in any way "snobbish" here, but I guess
> I've just never seen the POINT of games; for me, modelling the "real
> universe" is a lot more satisfying.
Yup. Although I have Skymap installed in my "Games" folder
(unregistered, sorry.) Nice product though.
Matt Craighead
> LOL. Maybe there is no difference between game and business software
> development.
Well, we kind of do some of each... which can be worse than all one way.
I've had enough of "fun" interfaces for kids!
Richard Van Fossan
only worked on one (a contract position between jobs), and it was hard as
Hell.
Rich
Bob Marley wrote in message <6q53u2$nae$1...@Skuzzy.cstone.net>...
> It sounds to me like you are suggesting that people with no work
>experience are "peons" of programming. What it takes to make great games is
>none of those things. Programming is so easy, it doesn't take talent. I'm a
>network programmer at one of the biggest local area networks in Virginia,
>and I know first hand on what "Hard Work" is, and let me tell you, making
>games is a walk in the friggin' park.
>
> Experience - no, not in my day. I may have experience, but i've seen
many
>young people pass through my company's door, and make a solid program even
I
>could appreciate. But I have to admit, I do look down on Visual Basic
>programmers.
>
> Design - yes, marketing - no. When you do get something called
>"experience", you try to advance in company buisness, which means you take
Richard Van Fossan
kid you not). Then there was the Wrestling game one of my colleagues worked
on (also for the GameBoy/GameGear). The publicist for one of the characters
sent a very strongly-worded letter insisting that his client's "Trademarked
beard stubble" be "faithfully reproduced in his digitized image." Her
response was "How? His whole f***ing chin is one pixel!"
I can say from experience that writing games ain't no walk in the park,
unless you're talking Central Park, at midnight, with money hanging out of
your pockets and are wearing a huge sign saying "I am totally defenseless;"
then it's close.
Rich
Paul Hill wrote in message ...
>>SPECIFICATION:
>> * Runs native under Linux, using the Motif 2.0 libraries for interface.
>> * Looks, acts, smells, feels exactly like Quicken including binary
>> file compatibility.
>>
>>I'll wait while you type.
>
>
>Well that's a typical business spec (ie a load of cobblers) but as to
>writing that, it would be dead easy.
>
>Much easier, than, for example, porting a game written in DirectX to a
>PlayStation.
>
>I would have had the binary file on the table by now, the algorthims are
Pete Stubler
spell the word COMMERCIAL?
Richard Van Fossan
capitalized? ;-)
Pete Stubler wrote in message <35D190A9...@image.kodak.com>...
Marc Bassini
Pisa tower...
Richard Van Fossan a écrit dans le message
<6qv4vv$5...@news.microsoft.com>...
Russ Williams
[...]
>It's hard to create a commercially viable game, but it's
>nothing like developing, say, reliable, fault-tolerant and
>secure distributed system.
Like, say, online multiplayer games? They need to be
fault-tolerant (for input, at least) so that they can't be
crashed by vandals or bugs and so that cheating isn't
possible. Security is a problem if the game uses an
online billing system and requires credit card details.
These requirements are perhaps less strict for games,
but you have real-time issues, such as packet loss and
latency to deal with convincingly.
>It's no big deal if some game has bugs that occassionally
>cause it to fail.
That depends on the bugs and the platform.
Console games are required to run for many hours
before they can be released - and memory leaks
are a lot easier to spot in 2mb of RAM than on a
mainframe. Console games can't be patched, either.
PC games, OTOH, are often less reliable because
there are less stringent quality requirements. PC
games do have to cope with a huge diversity of
poor quality hardware/drivers, though - more than
any other class of applications (including other PC
apps).
>Also, games don't have to conform to any hard
>engineering requirements other than playability and
>the ability to sell copies.
Which are both extremely grey areas. It's a damn sight
easier to code to formal requirements than it is to make
something that's 'fun'. Who defines fun? Why is one
game fun, but another isn't? Everyone has their own
answers for those questions, and most are
contradictory.
All in all, there is a range of difficulty in both games and
non-games programming. These ranges overlap
substantially, making any sweeping statements of one
being easier than the other completely meaningless.
---
Russ
Daniel J. Dolz
(Mitchell Morris) wrote:
>On Thu, 06 Aug 1998 00:46:00 GMT, Daniel J. Dolz <dd...@uncoma.edu.ar> wrote:
>[snip]
>
>>Oh yes? Your org should learn to write specs then. Maybe some reading
>>will help. You see, sometimes you need a bit of theoretichal basis.
> ^^^^^^^^^^^^
>You misspelled "I'm still learning how to use a dictionary".
Hey! My mother language is spanish. Give me a break.
>
>
>>What is that "looks, acts". The example is of no use even if you try
>>to see its funny side.
>>
>>1.- write a correct, understandable, easy to check, rigorous spec.
>>It愀 only a medium brainer work, once you got the understanding of
>>what you want to do.
>>2.- write the code.
>>
>>Game programming is far more dificult, and challenging.
>>
>>Daniel Dolz
>>dd...@uncoma.edu.ar
>
>That is a complete specification for a conversion process. When you are done,
>you will have an application that performs all functions exactly like Quicken.
>This is correct, understandable, easy to check, and rigorous.
>
>I'm still waiting for Paul Hill and/or you to, and I'm quoting here,
>"type the code in."
>
>I realize you would like to claim that business programming is a trivial
>endeavor, but your criticism demonstrates the worst kind of parochialism.
>Problem solving is the only real talent any programmer brings to the
>project, and you may rest assured that there are whole stacks of them inherent
>to business application development that you haven't yet seen.
>
>YHBFB. YHL. HAND.
>
>--
>Mitchell Morris
>mmo...@mindspring.com
>
>A Law of Computer Programming:
> Make it possible for programmers to write in English and you
> will find the programmers cannot write in English.
>
Ok. Extremes positions are wrong.
Ricardo J. Santos
right now is about each year). For example what you think would have happened with
Id if they where still using Wolfestein 3D engine? Game developing is an area in
computer science that lives by the change. Yesterday software renderers. Today
hardware acceleration. Near future affordable geometry acceleration. Far future,
who knows (maybe a 3D holographic room with a wave device that could transmit the
other sensations directly to our brain :o) The point is: If you make a business
application, when the hardware changes it does not automaticaly becomes obsolete.
For a game developer, if you dont improve and continue using old technology,
someone else will. And then is your company that will be old, Old News that is.
(Before I get flamed, my native language is spanish, so sorry if I made any mistake
in my writing).
Scott Hill wrote:
> Michel Huot <hu...@icrdl.net> wrote in article <35C7CA99.535@Group>...
> > Bob Marley wrote:
> > >
> > > It sounds to me like you are suggesting that people with no work
> > > experience are "peons" of programming. What it takes to make great
> games is
> > > none of those things. Programming is so easy, it doesn't take talent.
> I'm a
> > > network programmer at one of the biggest local area networks in
> Virginia,
> > > and I know first hand on what "Hard Work" is, and let me tell you,
> making
> > > games is a walk in the friggin' park.
> > >
> >
no_spam
it??