Slashdot Mirror

Physics simulation of rotation is complicated because you are handling matrices and vectors. Google David Baraff for a good reference. Russell Smith's ODE is a good library for this.

Just because Havok costs money don't make the mistake on it being the best.

There are numerous physics engines out there that are much better which are open source.

Can you give examples please? I know of a few like ODE, which has been used in commercial games [wikipedia cite], and Tokamak Physics whose demos I've played with.

Perhaps someone like you who has experience/knowledge in this area can give some better examples than those, or even why you think they are better.

I wouldn't know!

A lot of FOSS projects fall into the closed-community trap and get ossified in place. "Write your own patch" is code for "this is our perfect little gem and we have no interest in changing it." They will never achieve an audience outside a very narrow niche, let alone contribute to what Linus called FOSS's "completely unintentional side effect" of toppling closed-source software, and they're perfectly happy with it. Here's an example:

I've played bzflag on and off since about version 1.7. It's somewhere between 10 and 15 years old. In and of itself, a remarkable acheivement in a world where computer games are flashes in a pan. It still has some heritage from it's ancient past as a game for Silicon Graphics workstations, such as support (buried in the manual) for hardware stereo screens and anaglyph mode*. But it's stuck in the past. It's played by about the same one thousand people worldwide. The exact same two dozen or so out of nearly 400 servers receive 99% of the traffic, and 2/3 of those have a distinct group that plays there for the most part.

Now, as far as I know, version 2.0 was the first to add support for graphics more complex than pre-textured boxes and pyramids. Everyone was cont significant audience, or for that matter an audience outside their existing niche.ent jumping around on boxes and would've been happy to keep doing it forever I bet.

There have been physics problems since before I started playing that still stand, and you can't complain because that's just how the game works. It's my fault when my tank gets stuck in a crevice, or on a pyramid, or between meshes, and I should stop whining. Apparently, there are no plans to use something like ODE to give BZflag actual physics. It has options for momentum and basic friction, but they're nigh-always off; Everyone is happy to just drive their inertialess tanks around and jump in parabolic arcs, because that's how the game works.

There is no armor or even hitpoints. It's "too complex" to play with apparently. I suggested it, and was met with people not understanding why I'd even want the option or even scorn. It's a bad sign that I honestly wondered whether it was a joke when someone claimed he truly didn't understand why hitpoints might be a desired feature in a FPS game. But hey, that's the game. When playing "capture the flag," I've often said that hitpoints would open up deeper strategies than lone-hero and zerg-rush, but no one cares... They're perfectly content to sit there playing sniper & thief, or on rare occasions trade waves of tanks. That's the way the game has been since time immemorial (equivalent to between one and two centuries in meatspace by most estimates), and by God that's the way it'll always be.

Have I mentioned the cheater problem? The server does no sanity checking what so ever. Cheaters can zoom across the map, hover, be shot at point blank range with area-affect and tracking weapons, to no effect. I've asked several times if the server couldn't at least run basic checks for hovering or impossible movement. But bzfs is a very lightweight server, and adding collision checking would unduly burden it - that's what I was told, in all seriousness. While 5-10 megabytes is indeed an impressively small memory footprint, how in God's name can "the client does everything and the server implicitly trusts it" have been considered a viable model unless it were being implemented with a closed, unchanging community?

At any rate, the game plods along, with a closed, ossified community happy with nothing at all changing ever. It'll never be accepted for wide playing, but no one cares, because it's our perfect little gem. Our precious, to cherish and polish forever and ever.

And you want to change it? Well bugger off... go write your own code, or fork the project.

*Actually any OpenGL program supports stereo buffers if the hardware does, but good luck finding any references to GL_BACK_RIGHT in the wild with games

It already exists, and is called the Open Dynamics Engine. It'd be nice if somebody made a version reimplemented on top of CUDA or CTM, though.

That's pretty much what a physics engine does, and there are already a number of open source physics libraries out there (ODE and Bullet are the most well supported as far as I know, the former has been used in a few big budget commercial titles). Someone just needs to port the back-end to CUDA and off we go... Easier said than done, I reckon.

I recall hearing chatter about CUDA bindings for Bullet but I'm not sure if anything came of that.

Well, there's already Open Dynamics Engine.

I'm amazed how rarely it gets mentioned, but you know, there is an open competitor, sort of. I say "sort of" because I've never actually written a game that needed physics, so I don't know whether ODE is to Havok as OpenGL/SDL is to DirectX/D3D.

Also raises the question: Will Intel force everyone to use Havok to take advantage of any physics-related silicon they develop? Or will they be friendlier to ODE? Or will they not create any physics-specific silicon, and make this whole discussion moot?

There's also the zlib/libpng-licensed Irrlicht, which is my graphics engine of choice.

Then there's Lightfeather, which I'm less keen on.

As far as OSS physics engines go, I only know of ODE, but as far as I know it's rigid body only, so I doubt you could get it to do any aerodynamics. There are plenty of examples/tutorials of people integrating it with all of these graphics engines.

I've looked at the blender environment for making games. However, it has poor network support for multiplayer games (last I checked), and is meant for smaller single person games. DirectX has had a bit better multiplayer support so far, so I imagine XNA has decent multiplayer support, or soon will. Blender is licensed under the GPL, but any scripts and artwork can be under any license you choose, and can be used commercially.

There's also OGRE3D. Although, I've had my share of tracing memory leaks and seg faults enough to know that as a development team of 1, there are much more interesting things I'd rather be doing (like adding content). Given I have been using Java a bit more lately, I've been leaning towards trying to use ogre4j, although progress with this has been relatively slow over the years. (Although their automated conversion of C++ hooks to Java seems interesting.) Also of note, OGRE3D is a graphic engine, not a game framework. However, other game related components exist based on this engine, although each has their own bit of requirements. For example, Yake will not compile without the latest and greatest Visual Studio. (The free Express version won't cut it, because it has dependencies on MFC, which the express version doesn't include.) This solution is the most attractive to me, nonetheless, because games can be made with minimal publishing/license constraints (most are licensed under LGPL).

There are other solutions, such as Garage Games, but they take a huge cut out of any money your game makes (used to be upwards of 80%). They also have mediocre network support, placing them as a poor choice in my opinion. Their claim is that they will, however, handle all of the marketing for your game and get others to play (& pay) for your game. Alternatively, you could pay a $15,000 license per game to remove royalty restrictions. There are also several OpenGL game frameworks, but they require all game releases to be under the GPL.

Does anyone else know of a similar solution that does not require a GPL license for the game, has good multiplayer (or massively multiplayer) network support, and a decent (or active) game development framework?

It's $350K for heavens sake! Why not http://www.ogre3d.org/ coupled with http://www.ode.org/? Surely combining those with 2 university departments where you'll no doubt find people already familiar with the source code would be a more sensible approach to developing serious games.
Sheesh. Money to burn.

Nooo!! "Havoc" is proprietary; you should be saying "Cry 'ODE!' and let slip the hares of war!"

Ogre3D is a very nice LGPL 3D Graphics library. It does have precompiled libraries for Windows available for download, but compiling from SVN is a snap as well. While it doesn't have the other parts of a game engine (sound, networking, physics, etc), there's always other libraries that work well with it, such as: The Open Dynamics Engine for physics, OpenAL for sound and SDL for crossplatform network and input. Ogre's visual quality can easily compete with a lot of top game engines today, as well.

...and here it is!

Does anyone know where their engine came from?

Has anybody seen this card in person?

This is something that OpenSource could be doing are http://www.ode.org/ responding to this?

My guess is that this engine is OpenSource and running on some sort of FPGA. Would help if a standard such as OpenGL could be drafted.

Forget games, there's a large market for physics models in design houses.

On the other hand, graphics cards make sense for consumers because there are only two graphics APIs, OpenGL and DirectX, and they offer very similar functionality under the hood (but significantly different high-level APIs). So a graphics card can accelerate games written with either OpenGL or DirectX, but that's not the case with the emerging PPU field. In graphics, the APIs developed and converged on common functionality long before hardware acceleration was available at the consumer level, but I don't think the physics API situation is stable or mature enough to warrant dedicated hardware add-in cards at this time.

However, I think there are two possible scenarios that could change this.

1) Havok and Ageia could create open or closed physics API specifications and make them available to chip manufacturers, e.g. ATI and NVIDIA, which have the market penetration and manufacturing capability to make PPUs widely available. I could imagine a high-end PCIe card that had both a GPU and a PPU on-board.

2) Microsoft. Think what you will about them, but DirectX has greatly influenced the game industry and is the de-facto standard low-level API (although there are notable exceptions, such as id). Microsoft could introduce a new component of DirectX which specifies a physics API that could then be implemented in hardware.

But unless one of those things happens, I don't think proprietary PPUs are going to make a lot of sense for consumers.

Yeah, BSD licenses sure have killed a lot of projects.
That's just five minutes of searching for BSD licensed projects, I didn't look for MIT licensed projects.

While I agree that hands on experience is important, do not underestimate the power of educating yourself. Writing a game might be about programming, but developing a game isn't.

Let's consider you're writing a multiplayer game, consider a MUD (or even an MMORPG), which is something I'm confortable with. You'll have to understand issues like:
- Psychology (Character progression curve, interest):
How fast does a character have to develop itself in order to maintain interest. What is the breakeven point for challenging progression and boring progression? You'll want a bit of maths. For instance, knowledge on how to plot a negative exponential distribution curve will help you balance the game. Understanding that stair-stepping (levelling, titles, etc ) is usually better than proportional progression in terms of feeling the effects of "achievement" is another important issue.
- Economy (Resource drains, gameplay rewards):
New resources are brought into the world every instant, usually by the simple fact that NPCs drop items and money behind. How to avoid the world getting rich? What mechanics are inplace to counter this and maintain Archimedes law?
- Physics:
If you're writing anything 3D, you'll want to have a firm understanding of simple physics and be friends with our old friend Newton (velocity, acceleration, force). I suggest visiting ODE and check out their library.


In the end, what you'll want to attack is GAMEPLAY. To make the game fun and pretending to be realistic (while actually being cinematic).

Here two mistakes I have commited myself while developing for an mmorpg, to illustrate another point:

Problem: Expecting players to develop their Horsemanship skill in order for them to use better horses (war horses for instance). The less skill they had compared to the required skill to ride the horse, the more likely they were to fall off the horse.
Result: An outcry. Eventually I realized most people wanted to be able to ride them horses just for the looks of it.
Solution: You would only be thrown off-horse if under a stress situation (eg, combat or running at top speed). Otherwise, we'de assume people were in control enough to parade with their horses.
Final result: Both kinds of players satisfied.


Problem: Macroing. People would let their characters standing and doing stuff, just to raise their skills.
1st attempt: Banning macroing - obviously didn't work.
2nd attempt: Make it easier to obtain a skillcheck (a successful skill raise attempt), but then for a period of time, you wouldn't be able to learn. This makes lots of sense, and made raising a skill less of a random thing. People stopped bothering leaving their characters to macro and started caring a bit more about going to play. Many (those who actually played and not just macroed) still complained that it wasn't fair that a part of the time wasn't being rewarded.
3rd attempt: yield larger skill rewards for things that require the player to actually be in control, like combat yielding more experience in aggressive-filled areas you couldn't recall from (leaving a character macroing in there would result in certain death).
Final result: The combination of all these measures reduced macroing just for resource gathering characters (miners, lumberjacks) and craft professions. Each of these had a different approach. Understanding that macroing was a sign of a game with not enough interaction was fundamental to dealing with it, and generating interest in the game aswell.


All this to say that many of the final solutions came from reading and trying to understand people's frame of mind. I got many insights from numerous humorous articles on the web that tried to depict the stereotypes of players. None of this came from programming itself. Surely not all games are that demanding in terms of understanding players, but the bottom line is, developing a game has as much to do with programming as building a wood house

How about ODE? You see tons of commericial/proprietary projects based off it, but you don't see very much development work on it there on the site do you? This may not be the best example, but it's the first one I thought of... I guess another good example would be how much code have you seen Microsoft contribute back to BSD even though they use some of their network components? ..or so I've heard...

but if you read the documentation, you'll find the following:

"ODE emphasizes speed and stability over physical accuracy"

Which means that ODE, the "Open Dymanics Engine", isn't really very good at solving ODEs, the ordinary differential equations.

Most of the game developers I know cheat by using an ODE library. e.g.:

ODE.org
ODEJava.org (Java bindings for ODE)

Mmmmm. Apparently there is an open source lib for physics.

http://ode.org/

But your point about a standard like OpenGL not existing is true. We'll probably have a rehash of the early graphics library incompatabilities again. ::shudder::

You think people would learn. Open standards help a new technology to expand and to become accepted. It helps *everybody* in the industry.

There was an attempt to fork Bzflag and use an updated graphics engine called OGRE but it turns out that the bzflag code isn't very modular so it has stalled.

I think open source games are on the cusp of a major breakthrough because of the maturation of third party graphics and physics engines like OGRE and ODE. I'm helping with a project that has been running for a little under a year and we've released a pre-alpha already because we didn't re-invent the wheel.

I think a lot of people go into these open source game projects without an understanding of the amount of work involved. It's sad because a lot of great ideas and great code are lost when developers become overwhelmed with the details. Flight/driving simulators are much easier to create in an open source environment because of the lack of a plot requirement so you'll probably see them first. My point is that as soon as flegling OSS game devs look to open source middleware first then hand code things only when necessary, we'll see a lot of great stuff in a very short amount of time. An entertainment singularity :) Don't take my word for it though...
"Some good news from down under! Primed Games have won the Best Indie Game award at the Australian Game Developers Conference with their Mario-kart inspired title 'Scootarama', which is based on OGRE, ODE, RakNet and FMod. It's especially impressive considering they only had 12 weeks to come up with it with a 10-man team."

I know I would love to put together something like GTA:VC or MTA. I'm sure many others have as well. My problem is that I'm perhaps not as good a coder as I'd like to think, and I've never explored game programming before. But I have put a lot of thought into it the last year or two, and have come up with these resources:

• OGRE - an object-orientated graphics engine.
• Open Dynamics Engine - as used by the well-known stair and truck dismount games.
• DIE - a car game in the early stages of development. It uses the two previous libraries.
• Boost - C++ libraries. In particular, there is Boost.Python which allows good cooperation between C++ and Python. That could be useful for scripting the interactive behaviour of the various people, vehicles, weapons, and other devices.

As you say, the key would be in creating a flexible engine at the core. I imagine people adding new vehicles, tools, missions, and venues. I'm not sure what the "aim" of the game would be, but I'm sure people would create things to do. Here's my wishlist of improvements and other ideas:

• Climbing ability. I see lots of ladders around GTA:VC, but can't climb them. The ability to hang onto ledges like Tomb Raider would be useful as well.
• More detailed buildings. Most of the buildings in GTA:VC are just boxes. I'd like the ability to walk inside, use the stairs or elevators, find a sniping position on the balcony or window, etc.
• Focus less on violence. GTA:VC has been heavily criticised for its violence and sometimes even I find it a little too much. I'd like to see more focus on stunts and tricks, mischief, puzzle solving and just simple exploration. Perhaps make the police more likely to catch you when you do something "wrong".
• Different character classes. Perhaps not as detailed as a full-on role-playing game, but do have different types of characters with slightly different abilities. You need variety when multiple people are playing online.
• More interactive elements like light switches, garage doors, elevators, etc. Perhaps the player could obtain a garage door remote control and go around opening peoples garages.
• For the ultimate geek thrill, simulate several thousand artificial people! Get rid of the annoying "background" element of the cars and pedestrians in GTA:VC. Everyone has a house, they travel to work every morning and travel home every evening. Police and police cars actually patrol and have to travel to you instead of just appearing. Likewise with the heavier SWAT vans, police helicopter, and army trucks and tanks. Tourists travel in on planes to the airport, stay at hotels, travel around by day seeing the sights, and leave again by plane. Oh boy, lots of computation and memory and bandwidth! Perhaps a little too far-fetched for now.

Some links: There are a few open source games in development out there that are using the combination of these two OGRE (Open Graphics Rendering Engine) http://www.orge3d.org/ ODE (Open Dynamics Engine) http://www.ode.org/ SDL (Simple DirectMedia Layer) http://www.libsdl.org/

Interestingly, there's no dynamic action in Doom 3 that couldn't be handled easily by ODE. They didn't really need to roll their own physics package.

For an open source physics enging, see ODE
It also has quite a few nice demos.

ODE (http://ode.org/) is a GNU physics engine that has a simulation where you can crash a car into a brick wall .... LOT's of fun :)

ODE is a BSD licensed physics engine that is starting to gain acceptance in the propreitary game world. Open standards are no doubt important but I think LGPL and BSD licensed middleware is going to have an even bigger impact on the future of gaming, console or otherwise.

I'm working on an open source driving simulator and we're using ODE to dramatically cut the development time, looks like Techland figured it out with Xpand Rally. It's refreshing to see rampant innovation due to the reuse of code.