Is blender3d suitable for large scale game?

To share variables between scene :

in the first scene (where you create the global variable):

GameLogic.my_global_string = "aString"

in the second scene (where you want to read the global)

print "The global string is ", GameLogic.my_global_string

Jean-Baptiste

If it’s a game consisting of lots of smaller scenes/levels/areas, then Blender is more than capable. As others have said it’s only the large seamless worlds you’ll run into problems with. I’ve tried developing culling systems using Python for large scenes, but the engine is full of memory leaks. Just keeps using more and more resources until it eventually crashes :frowning:

All that’s stopping large scale games being made in Blender is the lack of man-power to do so. The community is mostly hobbiests, and founding a team of any size where everyone shares the same goal is next to impossible. If you had a team of salaried professional games developers working for 1-2 years on something with it, you’d have your large scale game…


All that's stopping large scale games being made in Blender is the lack of man-power to do so.

I think another big part is programmers that individually program everything. It becomes increasing important to do generic behavioural programming as the world gets larger. That takes a lot of time up front and amateurs usually dive into it and don’t do rewrites. This person is probably a good example. How many large games has he done? Probably none. It wouldn’t matter which engine he picked if that were the case, his odds would be virtually nill of making a large game with or without a large team unless he had a very experienced programmer and game designer. This is just one form of an inexperienced person about to make a gigantic role playing game that does it all.

The reason most people will never complete a large scale project is because there will always be a point where it goes from being interesting and challenging to being pure grunt work. Just getting enough content out to make the full game. This is why most will just settle with a demo. Yes a lot of new people come in way over their heads, but those that stick at it manage to complete their projects eventually (usually after many many reworks).

I wouldn’t like to spend several years stuck on one project just so it would be a ‘large game’. Instead I prefer lots of smaller projects, refining my techniques in each one as I go along :slight_smile:

A lot of people chose this engine because they don’t want to sit plowing through thousands of lines of code and recompiling it over and over. They chose Blender because you can get stuck right in!

We’re not talking about the new people that come in wanting to make the next MMORPG here btw. This is about what the engine could do in the hands of a motivated and skilled team, and large scale games are definately a possibility.

I have made some experiments with strategy games in Blender and the first limiting factor in large scale games has been object count. Especially physicalized objects. Especially with the new Bullet physics (old Sumo is much better performance wise). This is a shame because Bullet features are far superior to Sumo’s.

For example there can be hundreds, even thousands of trees, houses, lamp posts etc. in a scene and they have to be physicalized (not dynamic) so actors can’t move trough them. You could always try some tricks to make objects visible only after they are close enough to camera, but they’re still there and their physics and logic have to be calculated.

You can test this easily by creating about 1000 simple physicalized (not dynamic) cubes. I get about 5 fps using Bullet (physics take 95% of computing time) and 150 fps using Sumo (physics 7%) with P4 3 GHz, Radeon X800 XL and Blender 2.42a even when there are no objects visible. 500 objects gives 50 fps (Bullet) and 270 fps (Sumo).

In commercial games objects like trees and houses are usually separate, in Blender (using Bullet) this is next to impossible. Few objects could be joined to form one mesh but this causes various problems, like alpha sorting bugs in trees and prevents modifying single objects in runtime (for ex. making destroyable objects).

Games like Tomb Raider could be separated to different scenes because the path player takes is preplanned. But games with large outdoor scenes like Far Cry, Operation Flashpoint and strategy games can’t be divided to many scenes. So the only solution seems to be the use of Sumo physics. I really hope Sumo won’t be removed until Bullet’s performance with non-dynamic objects is improved.

PS. I still think Bullet gives Blender much more potential than Sumo. This is just one issue that can be - hopefully - fixed.

Yup that works. You’ll just need some simple scripts to call the outside .py files. I think you can escape having to release your source code for the game that way since it’ll no longer be included within the executable. Heh, but the game models, textures, etc is a different story by the way the guys explain GPL around here.

[quote=ST150;]
The reason most people will never complete a large scale project is because there will always be a point where it goes from being interesting and challenging to being pure grunt work. Just getting enough content out to make the full game. This is why most will just settle with a demo. Yes a lot of new people come in way over their heads, but those that stick at it manage to complete their projects eventually (usually after many many reworks).[/quote]

Very true in most cases. Also it’s pretty fustrating to organize a lot of code in blender currently. It’s possible to make a huge project, but it’s not efficiently structured so things could get pretty messy. I’m looking forward to BOgre. Looking at the way the preview version was structured, it should be able to load objects, logic, etc from outside. The whole structure should make it a lot easier to handle. And plus maybe that GPL stuff won’t apply anymore since technically the objects, logic, and code might be loaded from outside.

:DBut if you have the ambition to create a large game. Go for the tombraider type since it’ll be less of a headache since you can just load scenes like everyone else was saying. Heh, but make sure you have an inspired group of people for content. Have fun.

Jason Lin

Yes, blender is capable of large scale games, although the organization can be pretty hard to manage since all resources are in one file. Really though, the biggest problem you will have, are keeping your own dedication. Doogs and I work really well together, because when I am snuffing off, he is there to bug me and get me excited about the game again, and I do the same for him when he gets tired.

One thing I’ve found, is that even when there is a lot of grunt work to do, once you get over that hurdle there is usually something fun again afterward. Keeping python seperate from the blend is definately important, I’m not happy with how much python I still have inside. I am pretty lazy, so when I do some new thing, I just make a new python really fast inside the blend, but now I have a huge stack of files in there and it is getting hard to keep track of them all. Proper naming is very important!

I guess the other thing that makes blender difficult are all the little quirks and odd bugs that seem to pop up when you least expect, forcing you to find some way to work around them. That does get a bit annoying. And the framerate is a difficult limitation. But, at least for me, the ease of working in the engine and the quick responses you get without any compiling or loading times make up for the shortcomings.

One last thing, if you are going to make a big project. Use subversion (or some other source control system) and come up with some sort of todo-list tasks system that works for you to stay on track. We use subversion+trac, although lately we’ve just been keeping a todo list in svn andupdating that with the tasks. Trac is good for bigger teams and getting a big picture of development. But yeah, svn is another good reason to keep python seperate from the blend as much as possible.

I am doing a game in blender game engine right now.
blender is very capable

Avoid 3dgame studio, and torque…

both are outdated and overpriced… (I made a joke in poor taste on the 3dgs forum, and they revoked my $200 developers licence in retaliation)

for easy development try:
Crystalspace+CEL+blend2crystal plugin+any other plugins you can find…
Crystalspace is a nice GAME engine… if you follow a few simple rules you can have some very conviveing worlds …

unlike the blender game engine, you can use high end shaders without programming, like:
parallax bumps,
simple normal maps,
simple water with real time reflections+fallbacks for lame GFX cards.

With the BGE you must write cryptic python scripts for any nice shaders (GLSL shader language knowlage recommended)

Get this, you just build a normal blender material shader, in the blender material GUI, with your normal map, heightmap,gloss/specular map, diffuse map, ETC…
then all you have to do is to let CS2blend know that you want that object in the shadowed render loop… click the check box and that is it!

CS has lots of things you will want for your type of game…
*the terrain system is very nice! adding foliage is a breeze
*particle/emitter systems are very complete, most common things have simple template, or you can start from scratch
*GI lighting is as simple as can be, add your lamps, and it will build a shadow map at runtime for you automagicaly… the edges on the shadow are very realistic and smooth.

also Try:
Reality factory (you need milkshape or 3ds for this, but has some noobie templates for simple game logic)

irrlicht (can make some nice worlds without code, you will need to script to make/compile a runtime)

sauerbraten (can make a MOD of sauerbraten very easy, makes game maps in real time… great for beginners to learn basic concepts of a 3d shooter)