Game Engine - Page 2

[MattEvans]

Swing indeed. And before that AWT (which is still at the back of Swing in the non-visual area).
There's nothing like that for C++. Each compiler and platform has its own user interface libraries, and often a plethora of them, some of which work only on some platforms and libraries and others on others.

Yeah, if you make a C++ application and insist on using one of the operating system's GUI systems/APIs directly, you're gonna run headfirst into portability issues. If you use a multiplatform layer inbetween, something like Qt or GTK or similar: your app will work the same on windows, mac, and linux.. the portability issue disapears ( as long as those are your target platforms.. ). Same with 3D even; use SDL + OpenGL, and all necessary porting is taken care of, between windows and linux atleast. I see the 'C++ apps aren't portable' argument as a myth; from experience with 2 largish apps: as long as I'm careful and avoid ( or allow the switching of [ which is rarely necessary ] ) all platform-specific code, and use multiplatform libs where appropriate; building the same code on windows and linux is trivial.

[jwenting]

those multiplatform APIs however are non-standard and hard to use.
Their licenses are also often such that you don't want to use them (forcing your application into GPL for example, or extremely expensive).
There's also no standard.

Yeah, IMHO the express editions are almost exactly the full ones except for the lack of some things relating to databases, deployment, source control and mobile development

They also lack documentation, can't be easily (if at all) extended, etc. etc.
The full product is well worth paying for if you're going to use Visual Studio for non-trivial tasks.

[MattEvans]

I'll agree, the Qt licensing sucks. GTK isn't bad though; it's LGPL, which is reasonable.. It (GTK) IS a messy API to use directly, but the Glade XML format is handy. Neither of these really aim to be standards; they are multiplatform APIs for user interfaces, that's all, and they do that well.

Anyway, I know where you're coming from, but if a standard for the runtime and GUI gets Java + Swing; I'll stick with no standard GUI, threads or networking; and C++ & libs / engine code. It's totally a preference thing, but there are good reasons for having that preference - and it's nothing to do with running speed ( or resistance to change - I learnt Java before I really understood C++ ) : it's mainly the lack of the same amount of groundwork in games libraries on Java as is on C/C++, but also a dislike of the simplicity of the Java language, which actually makes it highly complicated to use at times. Also.. for all of Java's proclaimed multiplatform-ness, I don't see a JRE on the Wii, DS, Xbox360, PS3, PSP, etc..

[jbennet]

i know, i dont get how java runs on my phone but they dont make a CE edition

[maddog39]

those multiplatform APIs however are non-standard and hard to use.
Their licenses are also often such that you don't want to use them (forcing your application into GPL for example, or extremely expensive).
There's also no standard.

They also lack documentation, can't be easily (if at all) extended, etc. etc.
The full product is well worth paying for if you're going to use Visual Studio for non-trivial tasks.

I entirely disagree with your statement. I think you are completely wrong. I think that proprietary APIs are the WORST at providing documentation and are usually far more complex and require a much higher learning curve. Have you ever tried easily finding the full documentation with full code examples for the Windows API or the Apple API. I didn't think so. Although you could argue that you have MSDN at your disposal on the Microsoft side. Trying to find ANYTHING on MSDN is like trying to find the worlds smallest needle in the worlds largest haystack. Not to mention that Microsoft's APIs for C and C++ are some of the worst I have ever used.

Whereas the Open Source APIs are far easier to learn while not sacrificing flexibility. They make more sense logically in your code. When you go to their websites, all the documentation is right there in front of you, easy to navigate, and most provide many tutorials and code examples on how to use their API for free. Most are licensed under the LGPL. In Qt's case, you have a choice of the GPL or the QPL. And then you have WxWidgets which has its own open source license and uses native widget toolsets on all platforms. The same thing applies to graphics APIs

[bnastic]

Interesting thread... too predictable, unfortunately.

May I ask how many of you suggesting Java is "as good or even better than c++ for gamedev" have actually worked in games industry? Or at least have worked on a game, from start to finish?

There is that old saying, "right tool for the job", it fits in this discussion pretty well. Java is not the right tool for the job.

[maddog39]

Well I can say that I have. But then again, I wasn't one of the people supporting Java for game dev. I think it'd be terrible for full blown 3D games. Not to mention slow. Having to translate the bytecode into machine code at runtime. You'd get an ass-wooping of lag every time you did something.

[VeAr]

Not to mention slow. Having to translate the bytecode into machine code at runtime. You'd get an ass-wooping of lag every time you did something.

This is the stereotypical wrong view most people have. Java bytecode is compiled to machine code at load time and optimized at runtime. It means you will have longer loading time, and the performance will be sub-optimal for about 30 sec, until the JVM fully optimizes the code.

It is not the question if todays games are made in C++, they are. The traditional game libraries are for C++, not Java. Using those in Java is possible through JNI, but its another layer of code which needs to be written. The inner loop of the engine can be written in C++ (or ASM if you will) and linked to Java. The Sun JVM has been open-sourced, so it is possible to directly integrate custom C++ code with the JVM. I hope that a more game friendly JVM will emerge from the open source JVM.

[jwenting]

The anti-Java attitude of the C++ "fanboyz" is highly predictable. As are the utterly flawed arguments they keep repeating again and again to "prove" that "Java is slow".
Java WAS slow, back in 1999 and before. It no longer is.
We run realtime systems in Java, systems were seconds can mean loosing or making millions, systems that according to the "Java is slow" "wisdom" could never be built in Java, and not at all using EJBs. We've done it, it works, and it screams (if the database and network can keep up, sometimes they can't).
It's fast enough in fact that we had to artificially restrict the flow of data in order to prevent overloading our customers' systems.

It may not be a 3D game, but it's mission critical and realtime. And they told us it couldn't be done because it was going to be Java...
There are similar stories all over the world.

What's hurting Java for game development is mainly the lack of easy to use libraries like the ones that most game studios have had at hand for C++ for a decade or more.
Performance is used just as an excuse, "measured" by people with no practical experience in Java using deliberately skewed "benchmarks" created by people like them who had a preconceived conclusion ("Java is slow") in mind when they set out.
Run those against old JVMs (based on the also flawed preconception that noone has anything newer than 1.1 installed on their systems), and the results are predictable.

But you're essentially comparing the speed of a BASIC implementation of something running on an XT and comparing it with a C implementation of the same thing running on a 486.

[bnastic]

^ No, all that simply does NOT apply to games. Having servers that scale does not translate to games. I've been working on games for 7 years now and I am also well aware what Java can (and can not) do.

Java CAN work nicely for MMOs (actually, it's probably the best bet for server-side), but CAN NOT handle low-level cpu-intensive systems on todays gaming hardware (including PowerPC in every console today, a cpu without ANY of the tricks JVM could use). Here I'm referring to AAA titles with cutting edge physics/rendering/AI. Java could probably handle games with lower requirements, though.

[jwenting]

have you tried it? Have you actually gone out and built something in Java using the latest in available JVMs and libraries and done user experience testing on the result?

Of course you haven't. Your preconception of what would happen is all the proof you think you need.
Of course your lack of experience with Java also means you'd be unable to create that Java application to be optimised for performance, which is another problem for a new tool to gain acceptance in an established industry.

[MattEvans]

But why? I actually have tried to do it, Java worked OK for this 3D game; comparable with C++ on the same machine; most of the speed problems were introduced via naive coding style. There aren't any show-stopping technical disadvantages to using Java; if releasing for the PC. Reasoning? The CPU intensive task that most games want to do is transform/lighting/texturing/etc - this is usually written in very low level code, and always accessed via some level of abstraction whatever platform is used. If you have low-level libs for physics aswell; the rest of the code in a game is usually 'light', event-based, quite dynamic; so, in a way, it doesn't matter what language you use for that part.

I didn't finish the game because I didn't finish the engine because it got stagnant and over-engineered. I'll happily write games in any language - some of the high level frameworks provide so many useful tools/libs, even runtimes these days. But.. if I was writing a tool, lib, or runtime; 'an engine'; I would want to do it in C++. In the games world C++ is more cross-platform-compatible than Java, it's got a proven track record; you rarely need to work at a lower level, but it is quite easily understandable, useable and well documented; a new language standard is going to be released soon, I don't see C++ stopping being de-facto.

The only time I'd want to use Java for any part of a game client, is if there was some platform-based reason for which Java HAD to be used; i.e. if the game had to be deployed through a browser, on a mobile phone, etc. If I had a choice between writing a game using an existing Java engine, using an existing C++ engine, or using an engine that compiles or interprets ECMAScript ( or similar ); assuming no constraints, and the same functionality and comparable speed from each engine; I would chose in the order ECMAScript, C++, Java.

Why? ECMAScript = multi-paradigm and highly unstructured, C++ = multi-paradigm, Java = rigidly OO. After core math-intensive graphics, physics/movement-feedback system, and general structural stuff is done; the only important thing is being able to make 'the game' - and this is often laughably high-level and inherently non-intensive code.. working with person not person.submodels[0,1..n].vertices[0,1...n].. As long as the ( context -independant ) engine is fast, well put-together, and appropriate; it actually doesn't matter so much what language you use to do the work that comprises a given game. I'd pick flexibility every time; I see C++ as more flexible than Java. Personal choice.

For writing an engine, or a one-off game; if the domain is fullscreen graphically intensive games, targeted for the PC and perhaps eventually consoles; there aren't any domain-relevant advantages to using Java; but there are domain-relevant disadvantages - there's no compatibity on the consoles, an arguably higher level of abstraction from the graphics subsystem, ethereal memory management, and everything, for better or worse, is a 'platform-independant standard'. If the domain is browser-launched thin-clients for some physics-light multiplayer game ( i.e. RPGS, they don't have 'physics' like FPS do ); Java wins for the same reasons in reverse.

jwenting, you can't argue non-experience or non-ability because very few people want to spend the time using Java for a certain purpose - Java rarely gets chosen for writing the core of 'high-end' games/engines because it's never been pushed as a platform for developing the core of 'high-end' games. I don't need to know from personal experience that a drill isn't the best tool for hammering nails.. I do - and it kinda works; perhaps it damages the drill in the long term; but that's besides the point, and deviating into irrelevance.

bnastic, you can't blanket-rule 'games' as some singular - there's many types of games, and usually some development constraint on each game, Java MIGHT be the right tool for a given job, client side or server-side. Depends on the job.

[mohanrobin]

he actual plot etc... is not a part of the engine. e.g one game engine (for example, the unreal engine) powers about 50 different games.

Dont use java though. 99% of game engines are C++

[mohanrobin]

For writing an engine, or a one-off game; if the domain is fullscreen graphically intensive games, targeted for the PC and perhaps eventually consoles; there aren't any domain-relevant advantages to using Java; but there are domain-relevant disadvantages - there's no compatibity on the consoles, an arguably higher level of abstraction from the graphics subsystem, ethereal memory management, and everything, for better or worse, is a 'platform-independant standard'. If the domain is browser-launched thin-clients for some physics-light multiplayer game ( i.e. RPGS, they don't have 'physics' like FPS do ); Java wins for the same reasons in reverse.

[jbennet]

>>i.e. RPGS, they don't have 'physics' like FPS do

most RPGs these days have advanced physics, as MMORPGs are the big thing (world of warcraft/guild wars)

[MattEvans]

Why did you repost exactly what I said, mohanrobin? :p use quote tags and only if you have something to say about what i had to say.

jbennet.. physics in most RPGs isn't as heavy as physics in most FPS; only because it's not as integral to the game experience. By that statement I meant, RPGs don't need to have, and don't tend to have, the same complex physics simulation as FPS; not that RPGs don't have any kind of physics and FPS do.

'Advanced physics' implies soft body/fluid dynamics and realistic destructable/multipart objects in this day and age =P.. First-person shooter/adventure engines are starting to have them, based on ( certainly approximate ) solvers that take alot of variables into account; those MMORPGs you listed might fake this on a certain level ( i.e., breaking and fluids based on pre-written animation ), and have some degree of rigid body simulation; but.. that's not advanced anymore. I hold by my statement, that RPGs don't ( generally ) have physics like FPS. Correct me if I'm wrong; I've only played WoW once at a trade fair.

[jbennet]

yeah, i was just thinking of the arrows, catapaults, spell clouds etc

[jwenting]

the physics in any FPS I've played go no further than you sinking when you get into water.
The very best may see bullets of long range weapons drift with gravity and wind, but that's as far as it generally goes.

[MattEvans]

In some FPS games of a few years ago; physics simulation is a part of gameplay.. Think Halflife 2; you throw things ( boxes, cars, etc ) around, they affect other things; in Red Faction, which is really quite old now; you can blow holes in walls. In other FPS games that I've played briefly, but not enough to remember specifics, you can hurt people by hitting them with shrapnel from exploded objects, take cover from explosions by ducking behind short walls, etc.. That isn't so advanced anymore, but; I would imagine, based only on the history of games so far, that the 'advanced' physics in any time period will be more prevalent in FPS than RPGs. For modern, look at anything that uses Ageia's PhysX SDK ( i.e. Unreal Engine 3 ), or Crytek's CryEngine2.. CryEngine has support for realistic ( and massive ) explosions and interaction with the environment, PhysX SDK potentially supports realtime soft body, cloth and fluid simulation.. There is more to physics in games than paths of bullets and the like... what's the last FPS you played?

Any RPGs I've played don't really have even single object, rigid-body physics; the map is usually non-modifiable, and when you destroy an object it just disapears. That's not to say it'd be unreasonable to put good physics in RPGs... just that it doesn't seem to get done.

Decent gameplay-altering physics in a massively online game of any genre would be hard to do; since it'd have to be calculated or syncronized exactly at both the server and the client(s). Not impossible, but perhaps unnecesary; unless physics really is integral to the gameplay.

[~s.o.s~]

> I hold by my statement, that RPGs don't ( generally ) have physics like FPS. Correct me if
> I'm wrong
Agreed. The amount of physics in 'sports' games is also worth taking into consideration. RPG's as such don't rely much on physics as FPS and Sports games do since the focus is never on fast paced game-play or real time physics.

[Ravenous Wolf]

it seems to be that most agree that the sheer speed of c++ does not make it more suitable for games.

the real problem is rather that neither java nor c# has the libraries for games that c++ has been accumulating for decades.

does this mean that once one of these languages acquire those libraries that c++ is going to have a competitor?

[jbennet]

neither java nor c# has the libraries for games that c++ ]

C# has excellent DirectX support so your comment is wrong

[jwenting]

and Java has excellent OpenGL support and networking support that far exceeds anything C++ has to offer...

[jbennet]

Java has excellent OpenGL support and networking support that far exceeds anything C++ has to offer...

No, Java far exceeds what STANDARD c++ has to offer (which is nothing), but IMHO the libs available for c++ and java are about the same, only difference is java has a lot built in whereas standard c++ is very bare

[mariocatch]

C++ is what major software companies use to make games. End of story.

C++ will never be replaced by C# because they serve two totally different purposes... C# was not designed to make full fledged games. It is of course not imposible, but it is not feasible. You can do unmanaged in C#, but.. what's the point? C++ does that for you and is built for that reason.

I am a C# Developer and use it for the reason it was created. Enterprise Application Development.

[jbennet]

You can do unmanaged in C#,

No you cant.

[Ravenous Wolf]

>libraries

i am not talking about the standard C++ library. that i know is far more limited that either java or c#'s libraries. i am taliking about gaming libraries. those like ogre, alegra, boost and so on. i know little about games but i am sure that c++ has developed even more class libraries for gaming over the decades.

>C# for application development...
if c# was really always intended for application development then what is microsoft trying to do with XNA? are they just blowing smoke or do they actually believe that XNA and C# has a chance?

i know that c++ is faster, smaller in memory etc. but with computer power and memory size growing all the time how long is this going to be a factor?

i have tried to learn c++ and stopped since i had to start learning c# as well and there are only so many hours in a day. i did not find c++ that hard but it is still way harder than c#. if someone devotes himself to c++ then the difficulty should become negligable. so lets remove difficulty as a factor. why else would microsoft want to bet on XNA and c#? is it quicker to develop in c# when it comes to games? i know it is when it comes to application development?

@mariocatch

would you mind supplying reasons why you say its just not feasible?

[jbennet]

>C# for application development...
if c# was really always intended for application development then what is microsoft trying to do with XNA? are they just blowing smoke or do they actually believe that XNA and C# has a chance?

XNA isnt designed for serious games, its for hobbyists. They are planning for C# Express + XNA to be the next QBASIC, if you know what i mean.

[mariocatch]

Like the previous poster said, if you plan on developing a full fledged game with XNA, you're outa your mind.

And yes, you can do unmanaged in C#. Look it up.

[jbennet]

I thaught you couldnt write unmanaged C# but you can call unmanaged DLLS and embed ASM in it