Game Engine

[oreo_cheesecake]

hi, can i ask, what are the basic parts of a game engine? because i am planning to make one using java and i dont know where to start!! need you help thanks

[jbennet]

Java game engine = slow by the way

Game engine modules usually are:

File I/O (saving,loading)
hard I/O (keyboard/mouse input)
Event handling
AI
Graphics (drawing it)
Resource management (loading the data e.g levels, graphics files, music)

The 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++ (and maybe a little assembley for the graphics)

[jwenting]

Java isn't necessarilly slow. That idea of yours is outdated by 5 years at least. For many applications Java is now as fast as C++ if not faster.

[MattEvans]

I'll agree, from experience, for most individual tasks, there's not much speed difference between C++ and Java. However; the rigid paradigm inflicted by Java sometimes restricts certain approaches to problems, approaches which, in some cases, could be faster ( or more memory efficient ) than those afforded by sandboxed pure OO... That still stands today.

[~s.o.s~]

I disagree. Even after all these years, Java still has to go a long way when compared to C++, at least in terms of Game Development. The kind of raw power achieved by C / C++ _can't_ be offered by Java.

Compare and contrast the implementation of different languages in C and Java and you would know what I am talking about (Rhino v/s SpiderMonkey). Although this _slow_ term isn't really justified in normal application development, it stands out when developing games. Plus the inclination of the industry to still use C as the core language to develop the game / graphics engine, regardless of what they use for scripting is enough proof in itself.

But I don't question the theory that the future holds a lot for newer langauges like Java, Ruby, Python but that time is yet to come.

[jbennet]

Python is actually used a bit for the AI in turn basd strategy games such as the Civilization series

[~s.o.s~]

Python is used in a lot many games. Severance - 'The Blade of Darkness', 'Freedom Force' and so on. The scripting language Lua has been used in both the original and the expansion of 'Painkiller'. Search up those and you will see these really are famous games.

The point here is that you might and should use scripting if it simplifies application development but the time when they would be used to code the time critical logic is yet to come...

[jbennet]

Thats pretty cool. I thaught it was used in more games, but i wasnt sure.

but i still wouldnt use a managed or scripted language for the core engine stuff (e.g drawing)

[PirateTUX]

My brother and I are actually in the midst of writing a "game engine", and I can tell you it is no small task. If you're looking to get a game put together in less than a couple of years (at least concerning an MMORPG), writing from scratch is probably not a good idea. That being said, it's definately a rewarding experience if you've got the patience.

From what I've seen so far, the basic ingredients are as follows:

Data(base) Engine - Load/Save information about the game
Rules Engine - Make it fair (and have a plot line)
Physics Engine - Make it look real / behave properly
I/O Engine - Make it interactive (handle keyboard/mouse)
Audio Engine - Make it sound good
Display Engine - Put it on the screen

And if you're doing a network game

Network Engine - Make it talk to the world

Again, that's what I've seen so far. It does depend on the type of game you're making, too. For example, if you're making a puzzle game, physics (at least real-world physics) aren't going to matter too much to you.

Anyway, I wish you the best of luck in your endeavor! This can be a whole lot of fun, if you're one who likes a challenge!

PirateTux

[darsh999]

I don't think java is slow many games are made in java which are leading this time atleast its better then c or c++....

[jbennet]

I don't think java is slow many games are made in java which are leading this time atleast its better then c or c++....

I disagree

[PirateTUX]

I disagree as well... From an language architecture standpoint, C and C++ are always going to be better than Java, simply because of Java's dependance on the Virtual Machine. While Java is always getting better, that layer will always cause Java to execute (for the most part) slower than any compiled C / C++ application.

For high-performance audio and video, C / C++ is the way to go.

[jbennet]

Isnt the JVM itself written in C?

[~s.o.s~]

The Java specification doesn't mandate the JVM to be written in any particular language, but yes, it's almost always written in C like other VM's out there.

But you have got to realize that Java is an interpreted and not a compiled langauge. The java code is compiled by the 'javac' tool into a class file which is then loaded by the 'java' interpreter which interprets the bytecode and executes the given program. There is on the fly conversion from the java byte code(which is machine code to the java machine) to machine specific code.

At present, there is very slick chance of interpreted languages beating the performance offered by languages which are directly compiled to platform specific machine code like C and C++.

A rule of thumb: You don't gain abstractions for free.

[jbennet]

Java is an interpreted and not a compiled langauge. The java code is compiled by the 'javac' tool into a class file

Is .NETs CLI/CLR the same idea?

[~s.o.s~]

> Is .NETs CLI/CLR the same idea?
Since I am not involved with C# in any way, I would be in no position to answer that question but it seems that C# code is compiled to an intermediate byte code called IL which is converted on the fly into machine code.

Asking the same question in the C# forums would be more yieldy.

[maddog39]

Is .NETs CLI/CLR the same idea?

Yes, I'm pretty sure that that's the case. I know for a fact that .NET requires a VM and I do a little bit of Mono and a runtime VM is required to run any mono application.

[jwenting]

The JVM can actually mean that your Java bytecode will run more highly optimised than any native compiled C or C++ code can.
The JIT compiler can provide runtime code optimisation which in a native compiled language is impossible.
As a result it can provide far more tuning of the machine instructions to the exact specs of the computer it is running on than is possible with a native compiled language.

The main area where code running inside a VM is slower (if the VM is good, and the JVMs provided by Sun and some others are very good) is in the loading time of the executable code, as that has to include final compilation into machine code which native compiled code doesn't need.
When finally executing, it will often run as fast as or faster than that native code.

This is shown time and again when doing realistic comparison between Java and native code.
If the application is shortlived, native code is faster (in extreme cases completing before the JVM has completed loading). For longlived applications though the Java code will execute at least as fast as comparable C++ code (if both are written to the same quality standards, rather than as is often the case with "tests" setting out to show that "Java is slow" the C++ code being highly optimised and the Java code deliberately poorly constructed).

And oh, Java is NOT an interpreted language.
It used to be, in the 1.0 release, a language that used interpreted bytecode.
Since the introduction of just in time compilers around 1997 it has been native compiled.
It's just that that native code is constructed on the fly during class loading rather than in advance during initial compilation.
Effectively the JVM is presented with what in C/C++ lingo would be object code, the code that's output by the compiler and presented to the linker.

[VeAr]

Java itself is not slow, as others have already said it. But garbage collection (memory reorganization), which the JVM does from time to time can halt the execution of the program for some time. This manifests itself as a short lock in a real-time application like a 3D game. The Java program can be optimized, so that it produces no garbage, so no garbage collection will happen. Sadly this optimization is tedious work, just like optimizing C code. The best approach is using both Java and C, and linking the compiled C library dynamically to Java. If you are interested in a simple to learn Java game engine, check out jMonkeyEngine.

[MattEvans]

I can't see any gain in using Java over C++ in games unless it was always much faster in execution speed than C++, or provided some functionality or freedom that C++ doesn't; which it isn't, and doesn't. Like C++, Java can only ever hope to equal the speed of optimized machine code, and if it met the speed of machine code generated from C++ :- so what, it doesn't have the same existing 3rd party useful-for-games libs as C++ does at the moment, the standard library isn't as good ( I like simple and general rather than complex and all-encompasing ) all acccess to the OS/videocard is via a higher abstraction layer as exists in C++, garbage collection is a problem I suppose ( but the same strategy VeAr just outlined - minimizing collection, should be employed for C++ games anyway, i.e. minimizing allocations/deallocations on the heap during time-critical periods of runtime- even pre-arranging heap objects using estimated usage frequency/order, but you couldn't hope to do that in the Java as I know it ), the language architecture just isn't optimum anyway beyond prototyping - if I know the lifetime of an object, and that it should be stack allocated, I want to specify that explicitly in the code, not perhaps imply it in the design.

There's nothing special in Java that doesn't exist in C++, thread stuff is arguably made simpler across different platforms, and the general multiplatform aspect is a good thing - but this doesn't matter if you're releasing for a number of specific platforms. C++ can easily be written in a write once/compile anywhere way, and optimized for either platform at compilation - which is as good as compile once run anywhere in any case I can think of. The only other possible benefit for using one language over another is flexibility, and there's not much between the two, especially in terms of what most games require. A better model IMO is to use C++ and/or C for the raw engine and embed to or call from a very dynamic interpretted language, one that is significantly different to C++, either in terms of capabilities, application scope, or simplicity. Think Lisp, Prolog, Python, Lua or ECMAScript << none of these are 'C++ like', and all have different usefulness/simplicity/structure/writing-style scope. What's the scope of Java that falls outside that of C++???

There are certainly good places to use Java - server applications, mobile phone/web-based games, etc. But not for the client end of a 3D FPS engine on PC/console with hot physics, graphics and the rest. Why even try? You'd have little to rely on in terms of existing libraries, you wouldn't be able to hand optimize the code as far as you can in C++, you'd have to adopt OO religiously and be unable to use an 'objects are laid-out memory' approach anywhere, you'd have to wrestle with a garbage collector and have no idea where allocated objects 'go' rather than being able to just allocate in one place and remember to clean up; and for those setbacks, all you'd potentially gain is speed in that you'd only be writing network/thread code once rather than n times ( where n is the number of target platforms ), and a reflection system which honestly isn't very appropriate during realtime, nor particularly special.

C++ provides all a game developer really needs for the rawest part of the engine; perhaps a scripting framework ( inside or outside ) could augment that, but Java as the scripting language? Might aswell write the whole game in C++.