gamedevlists-general — List for discussing general game development issues

[GD-General] Objective Caml (was Ruby opinions)

[Patrick M D. <pa...@wa...>]

On Sat, 22 Dec 2001, Brian Hook wrote:

> Oh, and if anyone has opinions on BETA or OCaml, I'm all ears =)

Sure, I'll be an OCaml advocate for you.  I've been using it for years and
feel I had a good understanding of its strengths and weaknesses. Here are
some high-level points:

  - Excellent performance of runtime code and garbage collector
  - Unifies many programming paradigms in a single language:
      object-oriented, functional, traditional imperative
  - Compilation times are fast and provide good diagnostic feedback
  - Code is very portable between Windows and Unix
  - Debugger supports replay functionality
  - More 3rd party libraries than similar languages (e.g. Haskell/Clean)
  - Powerful type-inference mechanism eliminating the need for most
    type annotations
  - Strict type-checker to catch many errors at compile time

Some specific points about the language:

  - First class functions - kind of like inner classes in Java but
    syntax is very lightweight and easy to use
  - Support for parametric polymorphism (extensional polymorphism
    is in the works)
  - Easy to define new data types and operate on them via pattern matching
    (a generalized case statement that allows arbitralily deep
    introspection)
  - Exceptions
  - Sophisticated module system including functors (a simple lamba
    calculus on modules to support paramterization)
  - OO framework with support for multiple inheritance, binary methods,
    and functional updates

I'm not particularly interested in entering a debate over which language
is better -- that's very much a personal choice.  Personally, I have a
strong mathematical background and appreciate formalism and notation.
For that reason, Haskell is in many ways a more attractive language to me.
However, OCaml still remains my language of choice for any serious
development work.

Patrick Doane

RE: [GD-General] dev environments

[Brian H. <bri...@py...>]

At 10:10 AM 12/23/2001 +0000, Philip Harris wrote:
>Does working on the Mac solve all the C++/MFC problems then? Or just
>interface building issues?

Mostly interface building and maintenance issues (once you build the 
interface, you can change it later trivially as long as you adhere to the 
MVC paradigm...I never found AppWizard to be nearly as good in that 
respect.  It always felt that once I built the skeleton code, editing it 
later was just not tenable.).  But using Obj-C is definitely a big part of 
the plus.

>Similarly there's many types of game where it's inefficient to run cross
>platform on the Mac.

Er, maybe console games, but architecturally speaking the Mac is just a PC 
with a different processor (at least in the case of OS X -- MacOS has its 
own set of annoying issues, but that still shouldn't make x-plat that more 
difficult).

So porting between the two should be trivial, given code that is reasonably 
portable to begin with.  If you're hardcoding calls to Win32 or DSound, 
well, yeah, you're asking for trouble.

>That depends entirely on your GUI library, if the desktop can give you
>lots of windows or high resolution then what's to stop the game doing
>the same?

Most games create a single window and operate within it.  Windows 
specifically is architected around the MDI paradigm so writing multi-window 
apps that don't exist inside a parent workspace is not commonly done 
(obviously it CAN be done, but most sample code and docs don't go out of 
their way to illustrate this).

Brian

RE: [GD-General] Eiffel

[Brian H. <bri...@py...>]

At 09:14 AM 12/22/2001 -0800, Brian Hook wrote:
>Another thing pushing me away from Eiffel is that I have a huge amount of 
>code written in C++ that I don't feel like rewriting or bridging to.  This 
>is just inertia working against ostensibly better languages.

Oh, and I just found out that Eiffel doesn't support hexadecimal constants 
because they're "not portable".  That brought my interest to a screeching halt.

Brian

RE: [GD-General] Eiffel

[Philip H. <ph...@me...>]

> Unusable UI (just try getting a decent window manager/GUI on
> Windows...), excessive difficulty or inability to=20
> tailor/replace to personal preferences (eg I don't allow=20
> icons on any system I run), poor process model (eg no=20
> UI-exposed generic process IPC/sequencing ala forks/pipes),=20
> unusable shell (even Cygwin's bash is crippled), CLI opaque,=20
> single-user, intransigent authentication schema, poor interop=20
> and integration with foreign systems (eg NFS, AFS, LDAP,=20
> Kerberos, PAM, etc), fundamentally broken SMTP support (list=20
> owner beef), interop unfriendly internal security semantics=20
> (eg ACLs on dirs not files), end results of=20
> embrace-and-extend run rampant, incompleat syscall interface,=20
> broken/unreliable POSIX supports, consistent and uneditable=20
> RFC violations, network opaque at the host and GUI and=20
> application level, poor tools (that (X)Emacs even runs is a=20
> miracle), untrustable kernel, difficult and unfriendly to=20
> automation, monolithic unified opaque API interfaces, code=20
> porting unfriendly, resource consumptive, operation requires=20
> you to put your body in front of the machine (side effect of=20
> being network opaque), consistent assumption that the user=20
> will work and operate in the manner and with approaches=20
> envisioned by MS (I don't).

That's a great list of problems with Windows but the majority if not all
of them only apply to 99.99% of users. The fact that the kernel is
untrustable and that is has an incomplete syscall interface makes no
difference to my productivity and I spend roughly 75% of my time
developing software.

> and ease of building new tools.  We're engineers -- that's
> what we do: build and use tools.  Windows tends to assume=20

That's not how I see it at all, yes we use tools, we probably build our
own tools as well, but they are just tools. What matters is the results,
specifically are they the results our customers want. I really don't
care whether the cabinet maker has his own tools are simply uses his
teeth, all I'm interested in is whether the cabinets are good and can he
deliver what I've ordered when he says.

Now if Windows actually stops you producing those results then that's a
problem but for the majority of people that is not going to be the case.
The work I do (and I'm sure this applies to a lot of people, even if you
aren=92t one of them) the vast majority of my time is centered around
solving a problem. At the moment it's behaviour AI and the solution does
not depend on Windows and Windows has no effect on how efficiently I
solve that problem. Nor do the tools for that matter, C++ affects the
implementation but actually solving the problem and getting the
behaviour I want has nothing to do with OS or language or tools or RFC
compliance.

Once I have the solution I'm going to sit down with my editor and write
some code. Windows still isn't going to get in the way. If I was using
Emacs under UNIX the process would be virtually the same.

I'm guessing that you do a lot of UNIX system level type stuff in which
case Windows isn't going to provide what your looking for but then it
isn't supposed to. But that doesn't make Windows "excessively difficult
to be productive under".

Phil

RE: [GD-General] dev environments

[Philip H. <ph...@me...>]

> Well, ideally the game is written in a cross platform fashion 
> so you could run it on Mac or PC.  Even so, obviously the ROI 
> depends on the number of team members.  With a 100 person 
> team, then the cost of Macs per person might be larger than 
> the incremental cost of suffering through C++ and MFC.  With 
> a 10 person team, the Macs gotta be cheaper.

Does working on the Mac solve all the C++/MFC problems then? Or just
interface building issues? 
 
> > Personally, I'd rather build the tools into the game using a
> > GUI library. It saves all that messing around with stand 
> > alone tools :)
> 
> This is fine, when it works, but there are many types of 
> tools where it just doesn't fit within the game.  

Similarly there's many types of game where it's inefficient to run cross
platform on the Mac. 

> Tools that 
> need lots of forms entry, database manipulation, large 
> surface area (e.g. multiple monitors, lots of open windows, 
> 1600x1024 resolution, etc.).

That depends entirely on your GUI library, if the desktop can give you
lots of windows or high resolution then what's to stop the game doing
the same?

Several of those examples you mentioned I wouldn't build a standalone
app for anyway, a straightforward spreadsheet can sometimes be far more
efficient than a custom tool, no matter how easy it was to write the
tool.

Don't get me wrong, I've not used the system you're proposing so I'm not
saying you can't be right :) 

Given that we're considering porting a couple of titles to the Mac I may
have the opportunity to try out your suggestions in the future.

Phil

Re: [GD-General] Eiffel

[Thatcher U. <tu...@tu...>]

On Sat, 22 Dec 2001, Jesse Jones wrote:

> At 10:08 AM -0500 12/21/01, Thatcher Ulrich wrote:
> >On Dec 21, 2001 at 01:56 -0500, Kent Quirk wrote:
> >>
> >>  fact, one of the things that I love about Java and wish that C++
> >>  had was anonymous classes. They provide the only way to deal
> >>  with the concept of functors in generic algorithms where the
> >>  functor is defined at the same point as the algorithm is
> >>  used. In C++ you can put it nearby. In Java you can stick an
> >>  anonymous class right inline. It's a powerful, useful, and very
> >>  general mechanism, similar to a lambda notation.
> >
> >Someone showed me this trick recently:
> >
> >	...
> >	struct Function {
> >		static void Call(int arg) {
> >			// some code.
> >		}
> >	} Instance;
> >	SomeFunctionTakingAFunctionPointer(Function::Call);
> >	...
>
> People have been writing templatized callback classes in C++ for
> years. Boost has recently adopted one that is pretty darn cool (see
> the function and bind links at
> <http://www.boost.org/libs/libraries.htm#Function-objects>).
>
> It allows you to write code like this:
>
> Editor* editor = ...;
> boldButton->SetCallback(boost::bind(&Editor::SetStyle, editor,
> kBold));
>
> italicButton->SetCallback(boost::bind(&Editor::SetStyle,
> editor, kItalic));

That's nice, but I don't think that addresses Kent's complaint.  Let's
say you wanted to toggle the bold mode on boldButton.callback; how
would you write:

	struct anon {
		static Editor* editor;
		anon(Editor* e) : editor(e) {}
		static void callback() {
			int	s = editor->GetStyle();
			s ^= kBold;
			editor->SetStyle(s);
		}
	} instance(editor);
	boldButton->SetCallback(instance::callback);

I'm not claiming that's great (in fact it stinks :).

> >and pardon me,
> >but IMHO the STL stinks as far as usability goes.
>
> I don't think STL stinks at all from a usability standpoint. Once
> you wrap your head around the concept of containers, iterators, and
> algorithms it's really easy to use and very powerful.

An example of how the STL is not "really easy to use":

	std::hash_map<string, int> my_hash;

	...
	string	my_key = something...;
	int	my_value = something...;

	// I want to see if my_key is in my_hash, and if so, whether
	// its value matches my_value.
	std::hash_map<string, int>::iterator it = my_hash.find(my_key);
	if (it != my_hash.end() && (*it).second == my_value)
	{
		// Match.
	} else {
		// Mismatch.
	}

I think I got that right.  The iterator is just obfuscation.  Whereas
the way you'd do it in Perl or Lua, the seemingly obvious:

	if (my_hash[my_key] == my_value) {
		// Match.
	} else {
		// Mismatch.
	}

compiles, and leaks memory!  I've seen code like the above, written by
professional C++ coders.  I probably wrote code like that myself the
first half-dozen times I used map or hash_map.  A hash container
should not define operator[] the way std::hash_map does; it's just
programmer abuse.

I find that kind of thing is endemic to the STL.  The STL was designed
(cleverly) as a demonstration of generic programming, rather than as a
nice container library.  Unfortunately, people use it as a container
library, and IMO it stinks for that.

-Thatcher

Re: [GD-General] Eiffel

[Brian H. <bri...@py...>]

t 04:04 PM 12/22/2001 -0800, Jesse Jones wrote:
>I don't think templates stink. The syntax is awkward and there's not 
>enough support for template meta-programming, but having what amounts to a 
>separate language at compile time is a very powerful feature that lets C++ 
>do stuff that Java, C#, and Eiffel can't touch.

Oddly enough, after intensely studying programming language design for the 
past few days (originally sparked by my interest in Eiffel), I'm coming 
back around to Java as a half-way decent intermediate that's also 
pseudo-portable (modulo JVM issues).  Obj-C still has quite a few features 
I prefer though.

Anyway, back to the point -- how does C++'s templates provide genericity 
that is better than Eiffel's?  After looking at Eiffel, it seems like it 
supports generic programming in a much more open and friendly fashion and 
without all the compile time weirdness that C++ jams down our throat.

>dynamism in the language. Pascal and Modula-2 were the first real 
>languages I used so I like the concept of compile-time type checking, but 
>a dynamic language really can make some important things simpler.

This is another aspect of Obj-C I like -- you can have typed or untyped 
variables.  If you send a message to an untyped object ("id") the it works 
as untyped language.  But if you send a message to a typed object then it 
can do a compile time check for you.  That you can send any arbitrary 
message to any arbitrary object is immensely powerful, especially when it 
comes to prototyping or using distributed objects.  No need to even know 
the interface, you can test an object to see if it can handle a message, 
and if it can, send it on through.

This is what makes delegation so practical in Obj-C (whereas to achieve the 
same effect in C++ you have to use MI).

>Right now I think a language like Dylan where you can have both types and 
>untyped variables is the way to go, but perhaps I'll change my mind after 
>I get more experience with Ruby.

My biggest concern with Ruby right now is performance.  Looking at the 
benchmarkst at the GCLS, it looks like Ruby is pretty far behind the other 
languages, including Lua (which I would guess is Ruby's primary competitor 
-- Python, Ruby and Lua seem to be accomplishing much the same thing).

>But the biggest problem with C++ might be that it simply requires too much 
>time and study to become proficient in the language and aware of all the 
>pitfalls.

I would put this another way: C++ was trying to be idiom-neutral and 
provide all the tools for any kind of programming style.  Because of this, 
you can become very proficient in one tiny aspect of C++.  I feel I know 
C++ very well for my purposes, but because I purposefully have avoided 
templates, exception handling, MI and many other things that I consider 
more problematic than worthwhile, I can't say I "know" C++.  In fact, I'm 
not sure many people can say they know the whole language since the whole 
language is overkill for any specific framework design.

I would even argue that any framework that uses EVERY element of C++ is 
probably a disaster.  Which goes back to my complaints about STL =)

Brian

Re: [GD-General] Eiffel

[Jesse J. <jes...@mi...>]

At 7:35 AM -0800 12/21/01, Brian Hook wrote:
>In Eiffel, it feels like inheritance is pushed for mix-in style 
>programming where you're pulling in multiple implementations instead 
>of multiple interfaces.  I personally prefer using inheritance for 
>interface/implementation separation, not as an extension for code 
>reuse (I use aggregation for the latter).

Unfortunately MI has a bad reputation in C++. Even people who should 
know better like Scot Myers rag on it. But essentially all of the 
problems with MI in C++ are because of virtual base classes. So how 
do you avoid virtual base classes? By avoiding diamond shaped 
inheritance hierarchies.

One way to do this is by using mixin classes. You have your main-line 
classes like Widget or Monster or whatever and then you have mixin 
classes like ReferenceCountedMixin or ObserverMixin or whatever. 
Mixins only descend from other mixins so you never wind up with the 
diamond of death.

This turns out to be a very nice way to design frameworks and, unlike 
Java, you *can* reuse implementation.

>I think Obj-C and SmallTalk's emphasis on simplicity gives them an 
>advantage.  For example, inheritance is discouraged as a form of 
>extension by a client.  Areas where you would normally use 
>inheritance they tend to push either aggregation or, more likely, 
>delegation.

Or they just rely on name commonality. So, you can have a container 
of Foo's and Bar's and still call name() or process() or whatever and 
it will just work, even if there's no common base class.

>Take STL. Please.  The only reason I can fathom that people love it 
>so much is that it's there (and even then, you have to go get a 
>"real" implementation to avoid the scorn of those that laugh when 
>you say you're using Microsoft's implementation).  Hey, I don't have 
>to write a map class, it's just there!  STL isn't particularly well 
>designed,

I disagree. The division between containers, iterators, and 
algorithms is great. The attention to performance and the performance 
guarantees are great. The ease of use coupled with flexibility and 
extensibility is great. Type checking is great (might as well 
leverage one of the things that C++ does well). The fact that it's a 
compile time library is at least cool because it lets the library 
adapt itself at compile time to the types you're using (eg int's can 
be memcpy'ed).

>it's a bitch to compile, and a bitch to debug.

I'll give you this one. :-)

>Having stepped into STL code on accident, that's just not a 
>neighborhood I want to visit again.

I bet you'd say the same thing about an awful lot of libraries that 
you use though. Unfortunately most of those libraries are compiled so 
that you can't see how poorly they're written. The problem with STL 
is that templates add quite a bit of visual clutter, the better 
implementations have a lot of different cases for things like POD and 
non-POD types, and the most popular implementation looks like (but 
isn't) shrouded.

   -- Jesse

Re: [GD-General] Eiffel

[Jesse J. <jes...@mi...>]

At 10:08 AM -0500 12/21/01, Thatcher Ulrich wrote:
>On Dec 21, 2001 at 01:56 -0500, Kent Quirk wrote:
>>
>>  fact, one of the things that I love about Java and wish that C++ had was
>>  anonymous classes. They provide the only way to deal with the concept of
>>  functors in generic algorithms where the functor is defined at the same
>>  point as the algorithm is used. In C++ you can put it nearby. In Java
>>  you can stick an anonymous class right inline. It's a powerful, useful,
>>  and very general mechanism, similar to a lambda notation.
>
>Someone showed me this trick recently:
>
>	...
>	struct Function {
>		static void Call(int arg) {
>			// some code.
>		}
>	} Instance;
>	SomeFunctionTakingAFunctionPointer(Function::Call);
>	...

People have been writing templatized callback classes in C++ for 
years. Boost has recently adopted one that is pretty darn cool (see 
the function and bind links at 
<http://www.boost.org/libs/libraries.htm#Function-objects>).

It allows you to write code like this:

Editor* editor = ...;
boldButton->SetCallback(boost::bind(&Editor::SetStyle, editor, 
kBold)); italicButton->SetCallback(boost::bind(&Editor::SetStyle, 
editor, kItalic));

When the button is clicked it calls the callback with the argument 
provided. The prototypes look like this:

void Button:: SetCallback(boost::function& f);
void Editor::SetStyle(uint32 style);

boost::bind takes a pointer to a free function, member function or 
functor object with N arguments and returns a boost::function 
argument that takes fewer arguments. You can even do things like 
leave the middle argument of a 3-argument function unbound.

It's not as nice as a real closure system, but it's enormously useful 
and it's also efficient and typesafe.

>I'm still sick of C++ though.  The useful modern stuff I want to use
>is all a huge PITA.  Templates stink, (lack of) introspection stinks,
>header files stink, manual memory management stinks, and pardon me,
>but IMHO the STL stinks as far as usability goes.

I don't think templates stink. The syntax is awkward and there's not 
enough support for template meta-programming, but having what amounts 
to a separate language at compile time is a very powerful feature 
that lets C++ do stuff that Java, C#, and Eiffel can't touch.

The weak support for introspection doesn't bother me as much as the 
lack of any dynamism in the language. Pascal and Modula-2 were the 
first real languages I used so I like the concept of compile-time 
type checking, but a dynamic language really can make some important 
things simpler. Right now I think a language like Dylan where you can 
have both types and untyped variables is the way to go, but perhaps 
I'll change my mind after I get more experience with Ruby.

I don't think STL stinks at all from a usability standpoint. Once you 
wrap your head around the concept of containers, iterators, and 
algorithms it's really easy to use and very powerful. The only 
problem are the icky error messages and the truly awful way that 
Plauger wrote his version of the library.

But the biggest problem with C++ might be that it simply requires too 
much time and study to become proficient in the language and aware of 
all the pitfalls. Even the stuff published in magazines like C/C++ 
Users Journal is full of problems.

   -- Jesse

[GD-General] Ruby opinions

[Brian H. <bri...@py...>]

The fun continues as I try to bring up interesting topics without allowing 
the threads to devolve into flame fests =)

So after much deliberation of Obj-C and Eiffel, someone on Yet Another 
Mailing List (cocoa-dev) said "Hey, why not use Ruby?!"  I've always 
considered Ruby more of a scripting language than a "real" development 
language, based on the overviews I've seen of it.  For writing a high 
performance server project, I think the orders of magnitude difference in 
performance between your typical compiled language and your typical 
interpreted language are pretty important.  If one language is 2x faster, 
hey, I can work around that -- but 100x faster is a bit much.

The only other scripting language I've looked at (and liked...for some 
reason Python doesn't do it for me) is Lua, which I happen to like a 
lot.  My complaints about Lua are that it's a moving target to some extent 
and there is a massive lack of information on it (no books, a couple 
references, and some open source projects).  Learning it is difficult 
because you basically have to learn by example and/or rely on the help of 
the many helpful people on the Lua mailing list (including lots of other 
game developers).

So, opinions on Ruby (specifically compared to other popular scripting 
languages)?

I've already integrated Lua into one project as an extension language and I 
do happen to like it quite a bit.  I haven't thought about writing an 
entire application in Lua or Ruby.

Oh, and if anyone has opinions on BETA or OCaml, I'm all ears =)

Brian

Re: [GD-General] Eiffel

[J C L. <cl...@ka...>]

On Fri, 21 Dec 2001 23:37:38 -0000 
Philip Harris <ph...@me...> wrote:

>> I won't work under Windows.  Not worth my time.  Not worth my
>> employer's time.  Can't see a reason to bother.  Not a religious
>> thing -- its just an environment which I consider and find
>> excessively difficult to be productive under, and without any
>> return value for that difficulty.

> Interesting, what in particular do you find so massively
> inefficienr?

Unusable UI (just try getting a decent window manager/GUI on
Windows...), excessive difficulty or inability to tailor/replace to
personal preferences (eg I don't allow icons on any system I run),
poor process model (eg no UI-exposed generic process IPC/sequencing
ala forks/pipes), unusable shell (even Cygwin's bash is crippled),
CLI opaque, single-user, intransigent authentication schema, poor
interop and integration with foreign systems (eg NFS, AFS, LDAP,
Kerberos, PAM, etc), fundamentally broken SMTP support (list owner
beef), interop unfriendly internal security semantics (eg ACLs on
dirs not files), end results of embrace-and-extend run rampant,
incompleat syscall interface, broken/unreliable POSIX supports,
consistent and uneditable RFC violations, network opaque at the host
and GUI and application level, poor tools (that (X)Emacs even runs
is a miracle), untrustable kernel, difficult and unfriendly to
automation, monolithic unified opaque API interfaces, code porting
unfriendly, resource consumptive, operation requires you to put your
body in front of the machine (side effect of being network opaque),
consistent assumption that the user will work and operate in the
manner and with approaches envisioned by MS (I don't).

A computer, and especially an OS is a tool.  Somewhere that got
lost, especially from an engineering viewpoint.  

More exactly it is a collection of tools and the capability and ease
of building new tools.  We're engineers -- that's what we do: build
and use tools.  Windows tends to assume that it is the tool,
singular.  I don't want a single tool -- that's a useless Swiss army
knife that does nothing well.  What I do want is a well built easily
operated tool box which makes it as easy if not easier to create and
use new tools as it is to use tools already in the box -- and
specifically one where the tool box is itself one of those tools and
is just as easily changed/replaced/rebuilt as an other tool in the
box.  

  If what I do is to build and use tools, surely my tools
  should support those activities?  Go into any good cabinet maker
  and you'll find that a large percentage of the tools were built
  right there by the cabinet maker for himself.  Ditto for a tool
  and die maker.  Even ditto for the North Sea fisherman I worked
  with as a lad, or the sailors crewing the yachts in the harbour.

Trying to leverage that (to me obvious and
how-could-you-do-otherwise) approach on Windows (when I've tried or
watched others try) has always been a recipe for disaster and pain.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] dev environments

[J C L. <cl...@ka...>]

On Fri, 21 Dec 2001 15:42:49 -0800 
Brian Hook <bri...@py...> wrote:

> ...1600x1024 resolution, etc.

Which is getting pretty mid-range these days.  I've been running
1920x1440 for the last couple years on a Matrox G200, and its pretty
trivial to get 2048x1536 or larger with more modern cards (the G200
was discontinued a year or more ago).

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

RE: [GD-General] dev environments

[Brian H. <bri...@py...>]

At 06:49 PM 12/21/2001 -0500, Daniel Vogel wrote:
>Most people here use Visual Assist and I haven't heard of anyone reporting
>crashs so far. While we are mentioning great tools: Araxis Merge is the best
>tool for merges I've seen so far.

Not to go on and on about NextStep, but for years its FileMerge program was 
the best you could find, period.  When working on Quake 2 and Quake 3 we 
had a dedicated OpenStep box whose job was ONLY merging files.

Brian

RE: [GD-General] Eiffel

[Brian H. <bri...@py...>]

At 09:50 AM 12/21/2001 -0600, Paul Bleisch wrote:
>One thing that I see a lot is the attitude that "we use C++
>for the engine, so I guess we gotta use it everywhere."

I use C++ because the subset of the language I use is portable and will 
generate a binary on any platform I care to support.  That's a pretty 
important consideration.  Odder languages like Eiffel or Obj-C are a bit 
more problematic and may lack many of the ancillary tools that people find 
necessary for development.

Another thing pushing me away from Eiffel is that I have a huge amount of 
code written in C++ that I don't feel like rewriting or bridging to.  This 
is just inertia working against ostensibly better languages.

And people write tools in what they feel is the most effective fashion 
possible.  For many people, it's a huge assumption that it's faster to 
write a tool with C++ and MFC than it is to learn a new 
language/environment.  Fair assumption, but in the case of Obj-C/Cocoa, 
dead wrong.

I'm leaning back towards Obj-C for a server program I'm working on simply 
because the latest version of GCC supports Obj-C++, which allows me to use 
Obj-C for all my core stuff and still call out to my C++ frameworks for 
stuff I may need.

Brian

Re: [GD-General] Eiffel

[Brian H. <bri...@py...>]

At 10:08 AM 12/21/2001 -0500, Thatcher Ulrich wrote:
>but IMHO the STL stinks as far as usability goes.

THANK you for saying that.  I'm so tired of people going on and on about 
how great STL is (it's probably the #1 validation of C++ and templates I've 
seen), when in fact IT'S NOT THAT GOOD.  It's convoluted, difficult to 
debug, has bizarre syntax, takes forever to compile, generates tons of 
warnings, requires third party implementations for stability.  The only 
reason people dig on it is that they didn't have to write it.

Someone should sift through the STL source code some time then come back 
and tell me it's GOOD.

The primary advantage is that if you need a List or a Map you can just use 
STL without having to reroll it, but since I have that stuff lying around 
anyway, it doesn't bother me.

Brian

Re: [GD-General] game_dev_proc (was Eiffel)

[Sergei M. <se...@ha...>]

Very interesting link, I'll even suggest to all the tech people here to take
a look on it.
These guys really push the limits of the hardware, as I read it and use
rather sophisticated toolset for processing their data... and they are only
3-4 programmers!
Reading that link arises some questions in my head, like: "My god, why
creation of one damn game must be such trip into technical depths of the
hardware and algorithmical complexities... Yes, I would enjoy it, but
looking at it from a non-programmer point of view it seems as a lot of
efford put into a single CD that bring to life one little orange dog... And
what if these same guys worked over the cure for the cancer and don't
spending their brainpower for people's entertainment ?". Maybe the answer is
obvous, but I mean that the process of creating today's games evolved into a
very complex challenge taking years. And for almost every single game that
process is started from the scratch! (Although these same guys are one
excellent example of reusing their previous work). It seems that in our
world today one single piece of entertainment is fun when it is complex
(besides Tetris maybe) - complex environment, compex level geometry, complex
animations, textures and effects, complex behaviour, dialogues and
storyline. Books, movies, games...
I remember that eating mammoths and living in caves wasn't such bad at the
end... :)
...
(now I'm back to earth)
Besides all the stuff they write (Naughty Dog's guys) I was excited to see a
tool that rearanges the data to optimize data flow... Would any PC developer
bother with that? These people use that because of inadequate hardware, but
I havent't heard of PC developer to use such thing (I'll be happy if
somebody prove that I'm wrong!) - maybe we trust too much in the OS features
that lacks on consoles..?
What do you think about that?

From: "Thatcher Ulrich" <tu...@tu...>
> > > There's a BIG PS2 game out at the moment that was written almost
> > > entirely in lisp, including the VU code. They wrote their own
> > > compiler, and apparently have the full rewrite-while-executing
> > > environment going as well.
>
> Here's some info re: the older Crash games (look under "GOOL" for the
> Lisp stuff):
>
> http://www.gamasutra.com/features/19991112/GavinWhite_03.htm
>

RE: [GD-General] dev environments

[Daniel V. <vo...@ep...>]

> Yeah, except "Show me your definition" only works _after_ you've
> compiled the project with browse info. If you wipe out your "Debug" and

This restriction doesn't apply if you use Visual Assist. As Brian already
mentioned Visual Assist is THE MSVC addon you want to get. Not only does it
allow "goto definition" without any hassle but also has very clever general
autocomplete functionality and working (as opposed to basic MSVC where you
have to wait forever after entering . or ->) member completion. It also
shows you the function declaration of the function you're currently trying
to call, expands macros if you move the mouse over them and shows you the
scope you're currently in. Oh, and it allows better syntax highlighting and
gobs of other useful features I forgot to mention.

Visual Assist, cygwin, putty and Araxis Merge are my favourite productivity
enhancers besides sleep ;)

-- Daniel, Epic Games Inc.

RE: [GD-General] dev environments

[Daniel V. <vo...@ep...>]

Most people here use Visual Assist and I haven't heard of anyone reporting
crashs so far. While we are mentioning great tools: Araxis Merge is the best
tool for merges I've seen so far.

-- Daniel, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Warrick Buchanan
> Sent: Thursday, December 20, 2001 2:35 PM
> To: gam...@li...
> Subject: RE: [GD-General] dev environments
>
>
> Yeh it's quite good and takes off from where Visual Studio leaves
> off but it
> annoyingly crashes quite often....
>
> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 20 December 2001 19:30
> To: gam...@li...
> Subject: RE: [GD-General] dev environments
>
>
> A-ha.  Someone sent me a link to www.wholetomato.com and their Visual
> Assist program.  This is the kind of thing I'm talking about!  That's
> definitely a step in the right direction.  I'll have to give it a whirl.
>
> Brian
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>

RE: [GD-General] dev environments

[Brian H. <bri...@py...>]

> Even when you take into consideration that everyone would 
> need Macs to use the tools and PCs (or PS2 etc.) to run the game? 

Well, ideally the game is written in a cross platform fashion so you
could run it on Mac or PC.  Even so, obviously the ROI depends on the
number of team members.  With a 100 person team, then the cost of Macs
per person might be larger than the incremental cost of suffering
through C++ and MFC.  With a 10 person team, the Macs gotta be cheaper.

> Personally, I'd rather build the tools into the game using a 
> GUI library. It saves all that messing around with stand 
> alone tools :)

This is fine, when it works, but there are many types of tools where it
just doesn't fit within the game.  Tools that need lots of forms entry,
database manipulation, large surface area (e.g. multiple monitors, lots
of open windows, 1600x1024 resolution, etc.).

Brian

RE: [GD-General] Eiffel

[Philip H. <ph...@me...>]

> I won't work under Windows.  Not worth my time.  Not worth my 
> employer's time.  Can't see a reason to bother.  Not a 
> religious thing -- its just an environment which I consider 
> and find excessively difficult to be productive under, and 
> without any return value for that difficulty.

Interesting, what in particular do you find so massively inefficienr?

Phil

RE: [GD-General] dev environments

[Philip H. <ph...@me...>]

> a game company (that had funding, heh), I would give all the 
> developers a PowerMac, simply because it would be more cost 
> effective developing tools on OS X than it would be trying to 
> leverage existing PCs and forcing reluctant toolsmiths to use 
> MFC/Win32/C++. Yes, it's THAT good.

Even when you take into consideration that everyone would need Macs to
use the tools and PCs (or PS2 etc.) to run the game? 

Personally, I'd rather build the tools into the game using a GUI
library. It saves all that messing around with stand alone tools :)

Phil

Re: [GD-General] Eiffel

[Thatcher U. <tu...@tu...>]

> > There's a BIG PS2 game out at the moment that was written almost
> > entirely in lisp, including the VU code. They wrote their own
> > compiler, and apparently have the full rewrite-while-executing
> > environment going as well.

Here's some info re: the older Crash games (look under "GOOL" for the
Lisp stuff):

http://www.gamasutra.com/features/19991112/GavinWhite_03.htm

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

Re: [GD-General] dev environments

[Zach B. <za...@za...>]

Brian Hook wrote:
> A-ha.  Someone sent me a link to www.wholetomato.com and their Visual
> Assist program.  This is the kind of thing I'm talking about!  That's
> definitely a step in the right direction.  I'll have to give it a whirl.

I'm quite happy with it myself.  It crashed and ate up resources until
a recent version (September, I think?) but it was still worth using.

I'm working on a PS2 game and use Developer Studio with Visual Assist.
There are ways to shoehorn foreign code into Developer Studio's slow
and error-prone browsing database, but I get by fine with VA and the
occasional recursive grep.  Any system like this (syntax highlighting,
completion, parameter info, etc.) is only as good as its parser, and
VA's parser seems to handle my code very well and updates itself in the
background whenever I save a project file.  The prime virtue of this
kind of setup is that I rarely have to switch buffers/modes/whatever
to look at declarations and can just concentrate on a single file.

---
Zach Baker <za...@za...>
"As a rule, I never touch anything more sophisticated and delicate than myself."

RE: [GD-General] Eiffel

[Paul B. <pa...@mi...>]

> -----Original Message-----
> From: Kent Quirk [mailto:ken...@co...]=20
> Subject: Re: [GD-General] Eiffel
>=20
> I'd really like to find a language that makes more sense in a=20
> production environment than C++ or Java.=20
>=20
> C: "You can do whatever you want."
> C++: "You can do whatever you want, if you can figure out how."
> Java: "You can do whatever you want that's safe."
> Perl: "You can do whatever you want any way you want, and=20
> preferably not
> the same way twice."
> Pascal: "You can't do anything."
> Eiffel: "You can do whatever we want."
> Python: "Whatever."
>=20
> Any counterarguments?

What does "Whatever." mean for Python?  We use Python "in a
production" environment all the time.  We have about one or
two dozen tools written in Python. =20

One thing that I see a lot is the attitude that "we use C++
for the engine, so I guess we gotta use it everywhere."  I
agree with one of Brian's original statements: if I never=20
have to write a tool in C++ again, I can die a happy man. I'm
at the point where C++ just doesn't buy me anything for most
of our toolset. =20

Our main uber editor is still C++, but that is for legacy=20
reasons.  I am pretty sure UberEditor 2.x will not be C++. =20
More than likely it will either be C# or Python. Nothing other=20
than C++ or Perl really has the runtime/module support that we=20
would want.  Perl is out because Perl source code looks like=20
dropped carrier garbage.

Paul

Re: [GD-General] Eiffel

[Brian H. <bri...@py...>]

At 01:56 AM 12/21/2001 -0500, Kent Quirk wrote:
>definitely use a fourth revision. (It appears he wrote a book in 1999 by
>starting from the paper, so you probably have to buy the book to get an
>update.)

I have the book.  It's good, and very length expansion on his previous 
critique.  He does seem to try to be objective, but there is a bit of a C++ 
negative sentiment and a positive Eiffel bias; not so much in absolutes, 
but where he's willing to cut slack, e.g.:

"While C++ does possess feature XYZ, it's a royal pain in the ass to get 
to" vs.
"While Eiffel lacks feature XYZ, it is trivial to work around by blah blah 
blah"

I'm also beginning to see some areas of Eiffel that I'm not sure I'm 
comfortable about (other than the different implementations that aren't 
entire compatible).  For example, Eiffel supports and almost pushes MI 
because they have a model of what inheritance means, even Ian does talk at 
length about the differences between interface and implementation 
inheritance (which is almost never discussed in introductory C++ texts but 
which is absolutely vital to not screwing up a framework design).

In Eiffel, it feels like inheritance is pushed for mix-in style programming 
where you're pulling in multiple implementations instead of multiple 
interfaces.  I personally prefer using inheritance for 
interface/implementation separation, not as an extension for code reuse (I 
use aggregation for the latter).

I think Obj-C and SmallTalk's emphasis on simplicity gives them an 
advantage.  For example, inheritance is discouraged as a form of extension 
by a client.  Areas where you would normally use inheritance they tend to 
push either aggregation or, more likely, delegation.

Have I mentioned that Cocoa is just a joy to work with?

>No overloading.

I dislike overloading.  I think this is a preference thing, but I would 
much rather see:

SetPositionWithVector( ... );
SetPositionWithXYZ( ... );
SetPositionWithTransform( ... );

Than just three different versions of SetPosition().  This is for both 
pragmatic (I want to search for all instances where I set position with a 
vector; I want the environment to choose the right function to start 
hinting to me about the parameter types) and stylistic reasons.  But I've 
heard the counter-argument of "I don't want to remember all those variants" 
and it seems valid to me.  I've just seen it abused, a lot, and it ends up 
making potentially difficult to read or maintain code (not to mention when 
things go to hell with inheritance and default arguments).

>Again, it comes down to favoring readability over writeability
>and eliminating ambiguity.

Yep.

>No nested classes.

I'm with them on this one too, although this is primarily because I dislike 
the entire linkage and file system model that C/C++ impose.  Nested classes 
are nominally private to the enclosing class, yet for some reason when you 
change the nested class you force a recompile of, well, everything that 
includes the specification of the enclosing class.  Blah.

>C: "You can do whatever you want."

Personally I think all the languages let you do whatever you want, so long 
as in the end they let you call out to C for the gritty low level 
stuff.  These days doing what I want isn't an issue, is how I go about 
doing it.  C++ feels like a really bad practical joke.

Take STL. Please.  The only reason I can fathom that people love it so much 
is that it's there (and even then, you have to go get a "real" 
implementation to avoid the scorn of those that laugh when you say you're 
using Microsoft's implementation).  Hey, I don't have to write a map class, 
it's just there!  STL isn't particularly well designed, it's a bitch to 
compile, and a bitch to debug.  Having stepped into STL code on accident, 
that's just not a neighborhood I want to visit again.  STL just seems like 
"Oh, someone wrote some code that's more reusable than the stuff I've 
hacked together over time...cool!" I personally just try to make my code 
reusable.  Go figure.

Brian