But it gets me a bit how he emphasizes how much expectations for professional games have grown, and therefore that it's harder to code a game now than ever before.

Really, if you're not out to code a 3D MMRPG, game development is easier than ever before...we have so many more tools for making better games than existed ten or twenty years ago. The internet is littered with tutorials on game-making, and a large collection of free or cheap programming languages (eg Java, various C++ compilers, Blitz) and tools (eg Eclipse, LWJGL, Dev-C++, SDL, Allegro, DirectX) are available. Ten years ago it would be a lot more work, and likely expense, than it is today to write a 2D space-shooter or a side-scroller.

I don't really think that Java and LWJGL (for example) have made games development an order of magnitude easier. It's just a slight shift towards the "easier" end of the spectrum from C++.

I would like to draw your attention to Powerbuilder, and what happened to development of client/server database applications back in the early 90s. Suddenly it was a total doddle to write database applications on Windows that took advantage of the whole platform effectively. It takes me minutes to achieve in Powerbuilder what it takes me days to achieve in Java. This is the sort of order of magnitude that the games development environments we have today need to grasp. RAD for game development.

It has little to do with Java:"the language" - although Java may well be the most effective underlying platform technology.

Even libraries like Xith3d are not making things a great deal easier because of the outrageously complex syntax of Java programming.

We need BASIC, in an IDE with all the 3D models and resource editing and deployment built-in, all geared totally towards developing games.

Hm.I don't really think that Java and LWJGL (for example) have made games development an order of magnitude easier.

The complexer your game is, the more you'll profit from a effective language/platform like Java. Again you've to differentiate: Moorhuhn ist not "the games development", so it depends what you do and what you use to reach it.A game of type Lemmings you'd sell as casual game today, and still it's complex to program, so actually even casual games will benefit from Java (+ 3d layer) a lot.

Quote

It takes me minutes to achieve in Powerbuilder what it takes me days to achieve in Java. This is the sort of order of magnitude that the games development environments we have today need to grasp. RAD for game development.

Typical database apps have more in common than most games, though. Add to this that complex database apps aren't built with PowerBuilder neither. A good computer/video game is an unique piece of art. I don't think they fit well to a "game construction kit".

Quote

Even libraries like Xith3d are not making things a great deal easier because of the outrageously complex syntax of Java programming.

Xith3d (or take Java3D as its big brother) makes things easier. A good OpenSource 3d engine is of great help.

Quote

We need BASIC, in an IDE with all the 3D models and resource editing and deployment built-in, all geared totally towards developing games.

You're kidding. No grown game will be written with Blitzbasic, and even in case it would: let's wait 10 years until it's ready.

Jeff hit the nail on the head: an effective language/platform in addition to nice middleware (3d engine, physic engine, AI engine, ..) and there you go.Between the language and middleware there's still room for other game-orientated libraries, like JOGL, JOAL, Jinput, and some 2D ones maybe.

Even libraries like Xith3d are not making things a great deal easier because of the outrageously complex syntax of Java programming.

We need BASIC, in an IDE with all the 3D models and resource editing and deployment built-in, all geared totally towards developing games.

Cas

I disagree. For one Java syntax is *slightly* simpler than that of C/C++, which appears to be the dominant language for gaming. (Maybe not in your market though.)

BASIC was designed for beginners to learn - heck that's spelled out in the name (the 'B' is for 'Beginners'). It becomes a big problem when it is used for more than that. Look at the crud that is Visual Basic and it is clear.

Java can be hard for beginners, but I think higher-level APIs done with Java can go a long way to helping there.

I think we're seeing that computers are mostly 'fast enough' to write truely generic and reusable game code. Something like the original Doom was stunningly good looking at the time, and ran blazingly fast. Yet try and get it to do a different game type and you'd be stuck.

Compare that to now when theres a large number of reusable code - not just graphics like Renderware, but full blown math engines for all that rag doll loverly-ness. Something like the UT engine has huge amounts of flexibility in it, and games like Neverwinter Nights have toolsets mature enough to be unleased on the general public (with both a WYSIWYG editor *and* a built in simple scripting language). Its just taking time for the really complex stuff to be off-loaded into reusable libraries.

Maybe when I said BASIC I upset a few language zealots here... BASIC can be anything you want it to be; but one its better points is readability. You can have classes and abstraction and encapsulation in BASIC.

What I'm trying to say is that there is no fourth generation language for games development. Powerbuilder really, truly is the choice for c/s database applications development because, simply, no tool comes close to it in terms of productivity and power. It has fallen from fashion recently largely through catastrophically poor management from Sybase (a joke of a company if ever I saw one).

A 4GL is specifically geared towards providing syntax and a RAD development environment for the task for which it developed. BASIC would be ideal because its syntax is clear and simple and very easily bastardized. In fact, Powerscript (as used in Powerbuilder) is just bastardized BASIC. One of their killer language features was just simply being able to type SQL directly into the code.

So I'm still saying - Java "the language" is just a little shift in the right direction. It fixes a few quirks and problems you find in C++ like memory allocation/deallocation troubles but ultimately the syntax is still nasty and can't be read aloud in English and there are no high-level language constructs designed to make games programming easier.

Typical database apps have more in common than most games, though (add to this that complex database apps aren't built with PowerBuilder neither).

Agreed.

Quote

A good computer/video game is an unique piece of art. You can't do that with a "game construction kit" (like in old times on the ZX Spectrum, hehe).

I'm getting fed up of people claiming that games in general are pieces of art; this is no better than claiming that games development is just like making movies. In both cases there are a *few* superficial similarities, but when you do a detailed analysis they are fundamentally different, and the comparison is mostly meaningless and unhelpful.

Quote

Jeff hit the nail on the head: an effective language/platform in addition to nice middle-ware (3d engine, physic engine, AI engine, ..) and there you go.

Uh...in many areas, we've yet to see any "nice" middelware in the games industry. The overall standard is poor (notable exceptions aside): usually the technology is good, but the interfaces are dreadful - or else fundamental functionality is missing or broken. Sometimes you feel like forgiving studios for "NIH syndrome" when you look at some of the tools that are marketed specifically at the games industry...

My favourite example is the Quake 1 licensees who allegedly thought that they'd be able to upgrade to the Quake 2 engine once it came out. Obviously this was a communication problem between vendor and licensee, but this kind of crud should NOT happen in a professional middleware vendor/licensee relationship.

Quote

I think what you want, Cas, is what Jeff's describing basically. Add to the language and "middle-ware" some more game-orientated libs, like JOGL, JOAL, Jinput, and some 2D ones maybe (which can stand between the platform and pure middle-ware). So that for typical gaming task you don't have to re-invent the wheel.

This is something that many games developers *think* will solve their problems / be the holy grail. Looking carefully at the costs (where project-failure or termination is still the biggest problem of all, both in terms of percentage of affectd games, and overall lost revenue), it would seem that middleware comes a distant second compared to "learning how to do project management".

I agree that good middleware can (and will, if we have anything to do with it) massively alter development speed, risk, costs - and thence the overall quality of individual games. But I think we need to recognize that there's a bigger problem, until we've destroyed the oft-quoted statistic that of 3500 games produced each year fewer than about 35% break-even.

Although I hate BASIC, if it can reduce the aforementioned problem then it's worth having. Don't diss BASIC simply because you know it's crud (no comment) - evaluate it in the context of the major problems for people within the industry.

So I'm still saying - Java "the language" is just a little shift in the right direction. It fixes a few quirks and problems you find in C++ like memory allocation/deallocation troubles but ultimately the syntax is still nasty and can't be read aloud in English and there are no high-level language constructs designed to make games programming easier.

...and this same problem, both in Java and in C++, is the force driving professional studios towards scripting languages in droves.

We're starting to see really inappropriate deployments of Python left, right, and centre simply because it's a heck of a lot better than just using C++, and the developers aren't (or can't afford) taking the time to properly evaluate alternatives; Python integrates with C very easily, so it's an particularly cheap way of releasing some of the pressure caused by the problems Cas mentions.

But I think we need to recognize that there's a bigger problem, until we've destroyed the oft-quoted statistic that of 3500 games produced each year fewer than about 35% break-even.

You could easily argue the reverse - the majority of game Just Plain Suck. And this is mostly caused by most of the time being spent on technology development rather than actually making a good game. With better middleware you could avoid this.

So I'm still saying - Java "the language" is just a little shift in the right direction. It fixes a few quirks and problems you find in C++ like memory allocation/deallocation troubles but ultimately the syntax is still nasty and can't be read aloud in English and there are no high-level language constructs designed to make games programming easier.

Java makes games programming easier in contrast to what's being used in 90% of the games: C++. For several reasons. Java kicked most of the nasty C++ syntax/pitfalls but is more than a language, it's a platform. It's got a big library which makes a developer's life easier. A library which works in a common way. That's the big jump compared to C++. Of course in C++ you can use all kind of external libs but for any team you start with you've to learn new libs, buy new ones, bug fix those, etc. C++ plus libs is fragmented.

Btw I liked BASIC. Used it for 10+ years or so. But its time is over IMO.

You could easily argue the reverse - the majority of game Just Plain Suck. And this is mostly caused by most of the time being spent on technology development rather than actually making a good game. With better middleware you could avoid this.

Exactly.I've seen several times that teams of larger (C++) applications in the end spent 60+ % of the time in re-inventing the wheel named basic libraries or even "middle-ware". :-( They did their own network library, their own 2d blitting engine, their own 3d engine, their own hard coded or maybe scripted AI engine, and so on. The time they need for that lacked at finetuning the application and so on.

You could easily argue the reverse - the majority of game Just Plain Suck. And this is mostly caused by most of the time being spent on technology development rather than actually making a good game. With better middleware you could avoid this.

Point taken. If you believe this, then fair enough. As it happens, from the failed games I've seen, I don't think that it's an accurate summary - apart from public failures (and whatever post-mortem info leaked out on them) I've seen fewer than 15 failed games, so it's a comparitively minute sample, and I'm open to any convincing arguments in favour of what you've outlined above.

AFAIAA, the 3500 number excludes "Joe Bloggs and his VisualBasic multiplayer Tetris clone he never quite finished", but I don't have any stats to hand where I know the original survey/source (anyone got the latest ELSPA report?)

Exactly.I've experience several times that teams of larger (C++) applications in the end spent 60++% of the time in re-inventing the wheel named basic libraries up to typical "middle-ware". :-( They did their own network library, their own 2d blitting engine, their own 3d engine, their own hard coded or maybe scripted AI engine, and so on. The time neccessary for this has been missing in finetuning the application and so on.

but...to what extent was this due to stupid decisions (i.e. bad project management) and to what extent was it due to lack of available middleware?

Do we really need more or better middleware, or just better project planning?

I'm getting fed up of people claiming that games in general are pieces of art

Well, I still think that a good computer game is a unique piece of art, like a good board game is. I didn't say that all games are art, "just" the (really) good ones. Naturally it depends on the genre, too. For example a flight simulation needn't be art, it's already a good simulation if it reflects a plane in a realistic manner.The games I am talking about are the ones with unique ideas and gameplay (several of them come with not so good technical aspects, but it doesn't kill the art somehow).To make a game you've _also_ to know the business of software engineering and planning, you're right.

Oh, off-topic again...

Quote

Uh...in many areas, we've yet to see any "nice" middelware in the games industry. (..) I agree that good middleware can (and will, if we have anything to do with it) massively alter development speed, risk, costs - and thence the overall quality of individual games.

3d engines for example are an important middleware. Physic engines in future, too. To name just two.

Quote

Although I hate BASIC, if it can reduce the aforementioned problem then it's worth having. Don't diss BASIC simply because you know it's crud (no comment) - evaluate it in the context of the major problems for people within the industry.

I know BASIC and Java: what would BASIC speed up in contrast to Java, for example? Do you mean as scripting engine?

. As it happens, from the failed games I've seen, I don't think that it's an accurate summary - apart from public failures (and whatever post-mortem info leaked out on them) I've seen fewer than 15 failed games, so it's a comparitively minute sample, and I'm open to any convincing arguments in favour of what you've outlined above.

Well how about looking at it from the other angle, sucessful games that managed to avoid getting bogged down in technology?

Unreal Tornament 2k4, building on an already well established engine, nothing really 'revolutionary' in terms of graphics, but really good artwork. Existing AI was already very intelligent. Added in a physics middleware (Karma I think) which gives great rag doll deaths and more importantly some (very) fun to drive vehicles. So they get much more time balancing the weapons, tweekng the handling and making good maps.

See also The Sims, whose sucess is well documented and uses a scripting language for all the AI (I forget which, something freaky like Lisp). Without good AI it would be pretty mundane. And for another random example, FZero. Built on the well tried-and-tested Super Monkey Ball engine, good solid physics, great sense of speed and lots of well balanced gameplay.

Just devils advocate, I personally think the reality is somewhere in the middle.

but...to what extent was this due to stupid decisions (i.e. bad project management) and to what extent was it due to lack of available middleware?

Do we really need more or better middleware, or just better project planning?

We need better and cheaper middleware and libraries (for the latter: Java does a good job). And we need better project planning, also more efficient software engineering and much more intensive quality assurance. (I hate to play today's PCs games when it's neccessary to apply the 3rd patch in order to continue.)

Oftenly a good middleware is very expensive. So the project planners judge: "Can we afford it? Won't we be able to do the same in shorter time etc".

Nothing inherently of itself. The problem is that Java, the language, is standardized, and it's standardized in a way that makes it suitable for C++ programmers to do a very general set of tasks. There are no built in language constructs to help and there won't be any, because you can't touch Java syntax without confusing the hell out of everyone. What is needed is a game programming language, integrated into a game programming IDE.

Take a look at Blitz3D to see how to do it. You can produce top-rate AAA games in Blitz if you want.

Nothing inherently of itself. The problem is that Java, the language, is standardized, and it's standardized in a way that makes it suitable for C++ programmers to do a very general set of tasks. There are no built in language constructs to help and there won't be any, because you can't touch Java syntax without confusing the hell out of everyone. What is needed is a game programming language, integrated into a game programming IDE.

Take a look at Blitz3D to see how to do it. You can produce top-rate AAA games in Blitz if you want.

Cas

Its pretty easy to look at the blits feature list and see it really doesn't give you anything more than gfx control (input and some sound to be fair). Its pretty obvious from the article (and everyones experience I'll wager) that gfx are less than 25% of a game. Blits won't help you with ai, an event system, game architecture, object management etc... You still have to do all that yourself.

I think you've touched on an interesting topic though. What language constructs would be useful in a gaming specific language?

...ultimately the syntax is still nasty and can't be read aloud in English...

"Not true" and "Who cares?" I don't want to write a novel, I want to write a game. Just as when you are writing out equations you don't spell it out like you would when reading e.g. "ten plus two divided by seven" vs. "(10+2)/7". It just doesn't make sense, symbols aren't just used for the machine's benefit - it is more efficient for people as well... to a degree.

Quote

and there are no high-level language constructs designed to make games programming easier.

What do you suggest?How would it be different in terms of simply providing an API/Framework IN Java?I don't think this is a significant issue.

"Not true" and "Who cares?" I don't want to write a novel, I want to write a game. Just as when you are writing out equations you don't spell it out like you would when reading e.g. "ten plus two divided by seven" vs. "(10+2)/7". It just doesn't make sense, symbols aren't just used for the machine's benefit - it is more efficient for people as well... to a degree.

I agree

There's often the core engine written in C++, and then some scripting language that's supposed to be able to easily create the game itself. The scripting could be done in basic or something but I think basic lacks in some areas; it's easy to begin with but difficult on the long run (I am dealing with objects in games, so I want a good OO language!). You have unrealscript which is a heck of a lot like java and has some nice game specific features but when you want to get to the bones for whatever reason or want your script to do something very fast, you also often stumble on the wall between the engine and the scripting and then you need C++ anyway (unreal has something a bit like JNI to do that).Now java has come to a point where it became suitable for both scripting (it can be simple) and engine (it has the performance and flexibility), now isn't that really great?I think this is one of the points why I think java has become a great step in the right direction of development of large game projects (what's so great about having multiple languages in such a project?).The current need for scripting languages next to C++ is just a workaround for C++ IMHO.

I want an unreal engine written in java + UnrealEd + java for scripting for doing FPS games. Not some black box with a limited scripting language that's just supposed to be easy.

etc. I find Java syntax hard to explain and difficult to read. I find curly brackets to be difficult to match up and distinguish from normal brackets. I find some of the neato ways of expressing things in a single line to merely make code harder to understand and read. I want the boundary between Java and scripting languages crossed, and BASIC is the way to do it.

Programming shouldn't be hard, and I find it really hard these days. I used to be able to program things that worked really fast, and now it takes me days, and hundreds of lines more code, and much head scratching and confusion. Maybe I'm just getting old but for some reason programming has not got any easier in the last decade despite us using 2000x more powerful computers and hugely complex OO languages in massive IDEs. What gives? Clearly something is amiss.

Is that really so much harder to read? (I hope I don't start another 'curly brackets on the end of a line sucks'-thread now )

When I compare for example VB to java, I don't think VB is that much easier especially on the long run. Having just 1 language in a project makes the project easier to manage I think. You could use a basic compiler for the JVM or even a Pascal one or whatever, but personally I don't see any benefit of adding another language because of syntactic preferences.Hasn't programming just gotten harder because you program more complex systems than in the old days, and not because of a difficult syntax?

(..)Programming shouldn't be hard, and I find it really hard these days. I used to be able to program things that worked really fast, and now it takes me days, and hundreds of lines more code, and much head scratching and confusion. Maybe I'm just getting old but for some reason programming has not got any easier in the last decade despite us using 2000x more powerful computers and hugely complex OO languages in massive IDEs. What gives? Clearly something is amiss.

Really you mean the same what Jeff said... :-)

Quote

Which is why two things will become increasingly important: (1) Coding tools designed to help manage complexity (eg Java.) (2) Middelware that offloads some of the hariest coding tasks. Complexity has reached the point where it stands as a barrier to imagination and innvoation. That can't possibly continue and have the industry remain healthy.

That's it.Programming these days is much harder than it's been on the nice homecomputers (*). It's true, but we can't do anything - except what Jeff said. Actually I understand you pretty well. In former times (8 bit) you needed less time to reach your goal: write games. For example the same time I needed to finish a complete Amstrad CPC game (including drawing the sprites), I today need to just learn the basics of Xith3d (one of those mentioned middlewares)... (but then, I'm going to use it for more than one game, hehe).

Fairly enough in former times the computer and their OS have been much simpler - and less powerful. No mice, no GUI, no event listeners, no stereo sound, no 3D graphics (which let explode the complexity of your two-dimensional game, 2d in short: it adds an entire new dimension, the 3rd one).

Still, there's no way back. Let's use comprehensive libraries likes Java's one and middleware! With just a dozen lines of code you can display your entire 3d scenegraph in textual form inside a JTree. How long would it take you to write such on a C64? You see my point?

(*) I regularly sorrow today's computer newcomers when it comes to programming: on a 8-bit home-computer you needed some hours to let your first sprites fly around the screen and in one week you did pacman. Today... you need months to open just a GUI window with mouse listener, etc etc.

Erik - I have the strongest suspicion that I have a feminised brain. I have very different language processing capabilities compared to most men. I think in words, not spatial relationships (I can't read maps and I'm crap at FPS games). When I read code, I read it aloud in my head. How do you pronounce }?

Here's another little example of just how opaque Java can be, obscuring meaning with crazy syntactical construct:

Here, in CasBASIC, I want to achieve something: can you guess what it is?

Totally spurious example syntax of course but you can see what I'm driving at. Less squiggles, less code, more meaning. This is why for example I still go on about structs despite them being technically possible without altering the language or the VM in any way - they're just 100x harder to do in Java than in C. How's that for a step backwards in usability for a task?

(*) I regularly sorrow today's computer newcomers when it comes to programming: on a 8-bit home-computer you needed some hours to let your first sprites fly around the screen and in one week you did pacman. Today... you need months to open just a GUI window with mouse listener, etc etc.

This observation has been the basis for my current project; a game creation system using rhino/javascript that provides the user with feature that would have been found on a typical 16 bit system; 3 layered tile maps, x number of sprites, and input. The user provides one image that is cut up into 32x32 tiles, another image of 64x64 sprites.

The game is implemented in the javascript using these basic building blocks much like a typical snes or sega game only with javascript instead of assembler. The application will include a map editor, script editor, and the game display.

Although not anywhere near finished, this thing consist of very little code; rhino was done by others, a syntax highlighting editor component was done by others. All I've done is the applet and the map editor and integrating them together. To me thats the real miracle of game programming today. If your willing to use other peoples work then you can accomplish alot quickly.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org