Hi Dark,
That's a very good analogy. In a way programming is a lot like
cooking. There are many ways to get the same result, and often times
it is up to the cook or the cheff how he or she will prepare it.
Some bakers might insist on making the crust, cutting and using fresh
fruit, adding various other ingreediants, etc from scratch when baking
a pie. Another baker might use a frozen pie crust, canned pie mix out
of a can, when making their pie. Its doubtful the customer will notice
the difference, but each baker will insist his or her method is the
best for various reasons.
When programming there are similar considerations to be decided. A
programmer can certainly program a game from scratch in a traditional
language like C++, or they can take a shortcut and use something like
BGT which will give them the same result with a lot less effort. We
programmers can argue all we want about the technical advantages and
disadvantages of each method, but frankly speaking, the end user
doesn't care. To them the end result is what matters rather than the
method or means of how it is produced.
However, the complexity of the game in question isn't the only factor.
C++, for example, has a number of complexities not found in other
languages such as pointers. Use of pointers gives the developer more
control over memory management, but at the same time forces them to
take the time initialize and destroy the pointers when done. Not
properly deleting a pointer when it is no longer being used would
result in a nasty memory leak. Rapid development languages like Visual
Basic, C# .Net, and Visual Basic .Net handle all of this transparently
in the background freeing the developer up from directly dealing with
memory management and clean up. The .Net Framework in particular has
what is called a garbage collecter that manages memory in the
background and cleans up after the application resulting in less bugs,
and takes the responcibility of using pointers and other memory
management tasks away from the developer. Both methods are useful.
Cheers!
On 7/16/11, dark wrote:
> Hi Jeremy.
>
> One thing i've noticed abut it professionals as I said, is a tendency to
> worry about stuff that actually doesn't affect the end user.
>
> it's like buying whipped cream instead of actually pulling out a whisk and
> doing it yourself, or buying some frozen hash browns instead of physically
> mashing the spuds, battering them etc.
>
> there will be professional purist chefs who will think this is terrible and
> always ssay you should do the hole lot yourself, but then when people cannot
> physically tell the difference in the meal, you think what is the point?
>
> obviously in stuff like making gravy or pastry or sauce, you do! take the
> long method rather than using prepacked sinse it will change the end result,
> but if it makes no overall difference but adds on to the preparation time
> why bother?
>
> this was the reason for my question.
>
> audio games don't get produced half as often as they could be, and in order
> to help that situation examining what your making them with is always a good
> thing.
>
> previously I thought if a programmer was experienced in a given language, it
> was only the complexity of the project itself and life that changed matters,
> but oviously that's not the case, so I ask why.
>
> Beware the grue!
>
> Dark.
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gamers@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
