quote: Original post by null_pointer
OK, I'll go with faster, slower code.

Faster to write, slower to execute. Profile and optimize later if necessary.

quote:"In properly written code..." -- hmm...interesting...I thought it was subjective?

Yes. We were going by my rules here

Seriously, I think the main use for assertions is in testing your own logic, and should never be in testing someone else's. It is like scaffolding that builders use: it holds the building up during construction, but is not meant to be there when you're done, and certainly shouldn't be relied upon by anyone else wishing to use the building.

quote:
1) It's not a brute force approach -- it's really rather elegant. Call exception::display() at the point of error, and it works just like an assertion.

I have a concession to make: if you set Visual C++ to break on exceptions, you can probably use them to get at the call stack just as effectively as using an assertion.

However, this doesn't counter the issues of exceptions causing code bloat and slowdown, or of being more long-winded to use in simple situations.

quote:
2) I doubt anyone would write something like this pseudocode:


void do_something(object* p)
{
if( p == NULL )
throw exception(p->data);
}


Don't you? Even if they did, it would cause an access violation and they would break into the code.

No, but if p == NULL, they may want to see q->data, or some other variable that is there. A lot of my functions have too many variables to output using a Display() function.

quote:
2) You don't have to have a catch statement in every function that has a try block.

No, but if you caught the exception further down the stack, you've already lost several stack-based variables which might have been important for debugging. You often need to stop execution at the first point that it becomes a problem for debugging purposes. I accept that in release mode, your priorities shift to having some sort of graceful exit.

quote:
3) It may be a lot of code, but Eiffel requires a lot of code too (behind the scenes). Encapsulate it with objects if you like.

You can't really encapsulate exception handling in an object. Maybe with macros. What are you going to do to create something as concise as 'assert(x != NULL)'? What's the point of encapsulating this single line of code?

quote:1) Hmm...you need a higher level language because it will take less time to write and be faster, because of course C++ is faster to write in and thus slower because its easier and less specific than a higher level language like asm, and VMs are better because they are higher level than C++. ??

Faster to code, slower to execute. In cases where execution speed is not critical, this is a very useful tradeoff to be able to make.

quote:
You can see that the differences lay not in the tasks to be done but their difficulty.Which is easier to write? A VM or a few DLLs? You say there are only two differences between the VM and the DLLs, and they are: a) implementations, b) language subsets.

Well, you are still looking at everything from a programmer's perspective, and only the original game programmer. Sure, the VM is going to be harder to write, but gives different rewards, rewards which are better in many cases.

quote:The implementation of a VM is much harder to write. You must design your own scripting language, including all the basic commands, and you must write a text parsing engine, an emulator, and then you must still fill in all the same code for the implementations on each of the platforms.

Well, designing a language is not hard generally. The way it seems to work is that people who have worked on many games before get to know exactly what kind of things their language would need. And then add those features to a standard syntax, while stripping out anything they don't need. UnrealScript, for instance, features 'state' where a class can have different functions executed depending on their state. It's an encapsulation of a switch statement enforced by code and made simpler to understand. So, they put that into the language. It didn't require much thought, I assume: they were aware of the need for it, and just did it.

quote:
Personally, I think it is the job of the programmer to implement the ideas of the designer, and not to design a system so that the designer can implement his own ideas.

You are basically saying "Don't empower designers, hire more programmers." Are you out of work?

In a traditional setup, a designer's role might get less and less important as the game progresses. This is a waste of a valuable human resource. Would you just teach them C++ and get them to augment the coding team, even though it would probably take too long to get them to a standard where they can make 'production-quality code'?

Secondly, you seem to be thinking of a designer as "The Idea Guy". This really is not the role that they assume in most games these days. The design team will often be involved in producing the maps or levels. This includes deciding mechanical functionality, whether it is some complex puzzle, or an enemy reaction to you entering a certain area, or that a lift lowers when you flick a certain lever. Chances are, they may write some of these things in a very high level type of pseudocode anyway. Instead of writing down "When lever 1 is thrown, start lift 8 up and release the zombie from the room next to it", a scripting language allows them to write:

Lever1::OnThrownLift(8).StartDoor(1).OpenZombie(3).WakeEnd  

Now yes, all the above could be done in C++ in some form. Do we want to require designers to have to use Visual C++ to test a 3-line piece of code? Or should the designer have to write that down, pass it to a programmer, wait for it to be implemented (at the end of a long queue of every other designers' requests,no doubt) and then test it? What if it didn't work? Rewrite the 3 line script, resubmit to programmer, rewait? If I was a designer I'd tear my hair out at that. I'd want to be able to quickly test that myself. After all, it doesn't look too difficult, even to a non programmer. ("Before the dot is the name of your thing, after the dot is what you want your thing to do.") Instead of requiring a C++ compiler, why not just have a list of events and a text editor in the level editing program, and store the scripts with the level? And why compile the above, when interpreting it would take next to no time?

Given the right tools, a designer can produce 'production quality' code that fulfills their aims and allows them to work in parallel with programmers, rather than waiting on them for basic tasks. That quality of code is far easier to create in a language that doesn't allow for memory leaks, that provides a simplified container class, that doesn't require knowledge of separate compilation and linking steps, etc.

quote: If the programmer will be using the language, then it is (obviously) much more efficient to use the DLL approach.

Not if they don't want to have to relink the project every time they tweak 3 lines of code...

quote:
I think that it's much easier to write a generic class than a text parser/command interpreter. At least to me. Other people may indeed find it easier to write a VM than a class. Poor guys... *sniffles*

Parsers are quite simple to write if the language suits them. C++ is hard to write a parser for, whereas UnrealScript or Visual Basic are easy. This is down to things such as preceding function names with the keyword 'function' that immediately switches the parser into "Oh, so I'm expecting a function" mode, rather than "hmm, I just read 'int'... is this a function definition, a function prototype, a variable declaration?"

I don't know how easy or difficult the memory management side of things would be. But since nearly all scripting languages either have (a) no concept of the free store, or (b) garbage collection, I doubt it would be too difficult. Anything on the stack just disappears when it goes out of scope. Anything else is reference counted. Simple enough, I guess.

quote:Yeah, I trust the industry experts about as far as I can throw them.

Well, I wasn't saying "The Big Guys do this, so it must be right." But in this case, I think they are. The ones with the vision are empowering their entire team, rather than forcing some sort of tree structure where everything has to go through the programmers at the root. They're distributing the high level tasks out among those who can handle them, and working on the low level stuff that no-one else can deal with.

quote:
I've seen implementations for VMs where the "pros" claimed syntax-checking and the like were mere annoyances and should be removed.

Well, in some applications, they are mere annoyances. The benefits of type checking in some systems are far outweighed by the extra effort needed in having to declare all your variables explicitly. It sometimes makes more sense to just execute anyway, and log any 'errors' during execution, rather than to refuse to run at all.

quote:The point of this discussion is that most of the advantages/disadvantages you listed have absolutely no bearing on VMs vs. DLLs. Conceptually, they're the same: handled by the writer and hidden from the user.

The distinction is: what kind of user? Do you want all your 'users' to be proficient in C++? If so, you are cutting out a lot of potential users.

quote: In short, libraries using abstract base classes provide all the scripting language you need while maintaining the things that SHOULD be standard, like memory management, syntax, etc.

Why should a designer who just wants 3 zombies to appear at the flick of a switch need to know about memory management?

quote:You gain benefit (in programmer time) from things being standard, and others being specific.

You also gain in programmer time by having a language that is more suitable to your application. There are some things I can't imagine doing without pointers. But on the other hand, Visual Basic's Collection object is far cleaner than C++'s std::map<>, while performing much the same task. No single language is perfect for everything. Therefore it may make sense to have 2 languages for 1 project: one for high level logic, one for low level number crunching.

Some projects will benefit from their own language, and some will not. This is a design decision that should not be taken lightly. Unless you are doing it as a learning experience, of course. Many projects would do well by simply embedding an existing scripting language, gaining many of the benefits I have detailed already, with less overhead than writing a dedicated VM.

quote:
#1 PORTABILITY

I argued against this last time, and the only thing you came up with is that you do not need a compiler for every target platform. I'm sorry, but that is what compilers were made to do.

What kind of argument is that? Guns are made to kill things: does this mean we should go out shooting people just because guns exist? There are often better ways of resolving conflict than to shoot people. And there are often better ways of producing a game than compiled native code.

And you are adding an extra burden on people who want to work on your game: they have to buy an extra product that costs quite a lot. This may be fine in-house, but many people write their games specifically to appeal to the mod community, which increases their game's longevity and interest. If you require Visual C++ to make a mod, fewer people are interested. Sure, you can get DJGPP but that is hardly easy to use and has no decent IDE to speak of. The Borland compiler also exists, but again, text mode is not all that simple to use and is an added complication.

Yes, the VM writers will already have a compiler, but I am assuming that one central reason for writing a VM is so that other people can contribute to the project, not merely the same people who worked on the VM.

quote:
I say that the benefit gained from any language is proportional to the experience in programming; the designers who do not program cannot produce as efficient a game as the programmers themselves.

Sure. But the difference is in what that proportion is. Double the programming experience and you double the output. But take 2 people with equal programming knowledge down, 1 given ASM, and the other given Java, and see who can make something meaningful first. Double their experience level, and the Java guy will still be far more productive than the ASM person.

Just because the designer cannot do it as well as a programmer could, doesn't mean they can't do it well enough to be shippable, especially if the programmer has created a good environment in which bugs are next to impossible. if we always leave everything to the best person, then nothing will ever get done. We would have nobody entering the industry as they would be pointless: after all, a senior programmer can do everything a junior one can. It doesn't work that way. You have to make good use of everyone's time.

Maybe a script to start a lift moving on the flick of a switch takes 10ms to execute, and native code would take 1ms. Will the game player care? They may be more interested in the fact that the levels are more intricate due to designers being more able to express their creativity.

quote:Letting the designer code the game is just a poor work-around and as such an unnecessary waste of time. (BTW, A good program is flexible and extensible, and you should have no trouble adding features to it.)

It saves programmer time, and allows better use of designer time. It removes the delay between a designer realising a feature is needed and the programmer implementing that feature.

quote:
Why should software differ from the operating system? Why should the operating system differ from the BIOS? Why should the BIOS differ from the chip on which it is burned? Why are CPUs sold separate from the motherboard? Why use classes and functions? Why not assembly? Why classify and separate things at all?

Now you are you arguing against encapsulation. This is madness!

Tell me... do you never use anything like this in your code:

int main(){    try    {    Application.Run();    }    catch(...)    {    // blah    }}  

Of course, the Application has lots of encapsulation between its parts. All subsystems are encapsulated, I assume. But the outside world only ever needs to see one interface. The Application object itself takes care of calling Init(), of entering a loop of calls to OnIdle(), and Shutdown() at the end.

Encapsulation isn't just about separating things, it's about putting separate things in one place with a standard interface. Hence the origin of the word: to put within a capsule.

Many other languages work just fine without you ever needing to know about the linker, or a compiler, or needing to declare forward references, or any of that. This can all be done for you. The reason C++ doesn't do it is down to C compatibility and the desire to not harm performance. If you are willing to trade away performance for a lot more simplicity, you don't need all these details. Scripting actions for a game is a prime candidate for this.

quote:
STL? no, that's too generic and slow. DX? nah, not specific-enough. Platform-independent APIs (OpenML) founded and supported by large companies like Intel? nah, too far away from the problem domain...etc. If you want to deny the trend, then go right ahead.

Everything you just mentioned is relatively low level. And routinely get used as part of the construction of the engine side of the game. But they are not -adding- these things to their projects, they are using them to replace what used to be platform specific code at the low level. In fact, the use of such libraries generally means they are using less code themselves to achieve the same effect. It took me a long time to get D3D initialisation working, and now I just downloaded a zip file from Witchlord's site that does the same thing, via D3DX, in about 1/20 of the code. Sure, this is a library rather than a VM, but the point here was that there is less code on my behalf to achieve the goal, and the goal here is the creation of the low-level half of the game that is hardware-based.

There is another half, where the direction is also away from native code, but not towards libraries. It's towards writing engines extensible by more than just hardcore programmers, that are useful in more than 1 style of game. The best way of achieving this is probably to use scripting or a VM in some form. The 2-tier approach to software is growing. It's getting harder to find games -without- scripting in them somewhere.

quote:Just because a solution requires more work and/or more intelligence doesn't mean it is better than a simple solution. You said yourself that of two solutions, the simpler one is almost always better.

Right. But this is about distributing effort more evenly. In the early 80s, nearly all games were written by ASM programmers, except for a few slow monoliths carved out in BASIC. As games have become more advanced, they are done in progressively more high-level languages. And therefore more people are able to contribute. In order to make most effective use of resources, a team would want to be able to
draw on the expertise of non-programmers. So the idea is that the programmers make the 'difficult' solution as it provides 'simple' solutions for non-programmers. The end result being more productivity overall. Case study: go out and count how many lines of code have been written in UnrealScript mods. Could the original Unreal programmers have written -all- that code in the time it took them to write the VM? I doubt it. By creating the tool, they could channel a lot of productivity that would otherwise have lain dormant. It was a short term 'expense' that led to long term rewards.

Edited by - Kylotan on June 6, 2000 7:59:41 AM