A Series Of PSAs

The following is a list of insightful public service announcements that should make it a little easier for some of you.

~~~~~ Releasing Games ~~~~~

Can you, by law of Copyright and Protection of Intellectual Property (IP), distribute your games as purchasable goods?
Usually yes, but perhaps not; You own your .blend files, they are your IP, however you do not own the executable file exported by the Blender Application, nor is the end user bound by law NOT to redistribute that very executable.
The most common work around is exporting an empty, dumby executable that loads .blends dynamically. The idea is that you wouldn’t be selling the exe, you would be selling the game content files. And that end users will be redistributing an empty application that will load a blank window.

So they can’t distribute anything?
No. But they most assuredly will. This is why you would use something like the BPPlayer, or Solarlunes little hack that locks .blend files; They cannot be opened by blender, nor can their content be appended from.

~~~~~ Render Engines ~~~~~

Why does my game look different from the 3D viewer window?
The 3D viewer window is designed to be a simple, preliminary display of your work, to demonstrate, only simply, what you’re working on. Though they are both OpenGL, the game engine uses far more GLSL:
The game engine uses GLSL shaders like fragment shaders, pixel shaders and vertext shaders. The 3D viewer simply uses BGL and OpenGL functions that are designed as simple demonstration methods.
The background will change from the interface colour, to the background colour of your “world settings” tab in the properties window.
Alpha textures will behave differently because they aren’t coded to be fully functional in the 3D viewer window, because they don’t need to be. Alpha textures in the game engine are handled far more elaborately and more accurately.
Logic steps and physics steps, by default, start as soon as the game engine starts; as soon as you press ‘P’. If anything in your logic, ANYTHING, dictates that something in your scene will change, then it will change when the logic specifies, sometimes, if you’re not careful (or even by intentional design) that change will occur in the first tick of the game engine runtime, and will not revert until, again, specified. If not specified, then it will appear as if there is a discrepency between the 3D viewer and your game, there is not, it’s just your game playing out. If it seems that you didn’t want it to happen, don’t rule out that it was pilot error.

Why does the Blender Internal Render look different to your games? And cycles aswell.
The Game Engine uses Open GL, through GLSL (I hear, though, it can use Open GL directly, but I haven’t confirmed this , nor witnessed this confirmed) which is based entirely on the GPU and it’s functions, and the rest of the Graphics Card. The Blender Internal Renderer AND Cycles are both rendering engines that use specific functions that are completely unrelated to the GPU, they work entirely on the CPU. Even though Cycles can make use of nVidia CUDA cores, it is not designed, in anyway to be used in realtime, it’s not efficient enough. Cycles and the Blender Internal use complicated ray tracing rendering for lighting. It involves sending rays from the light sources and/or the camera, and calculating the colour and intensity of light per pixel through the journey of these rays. These rays also bounce off of surfaces, or are even scattered inside surface (Subsurface scattering; SSS).
tl;dr : The BI and Cycles use ray casting and light bouncing technology. Whereas OpenGL uses fragment, vertex, and pixel shaders, and approximation techniques (for optimisation and practicality) for real time frame by frame rendering.

~~~~~ Logic vs. Python ~~~~~

An age old debate; the idea that logic bricks are easier but less flexible, and python is convaluted and difficult to learn is nonsense.

I’ve found that logics bricks are far more convaluted and elaborate when used to make game features that could otherwise be a < 100 line python script. But python is most assuredly harder to learn, and harder to understand than logic bricks.

If you’re interested in getting the game done and dusted, than you could very well use logic bricks, they can be used to do just about anything. I believe I’ve even seen an RTS being made entirely with logics bricks, and it’s magical. However, python is far less painful, limiting, and difficult to use than logic bricks. You can even use logic bricks INSIDE python scripts, because logics bricks are actually coded IN PYTHON (Really, they’re coded in C++, but interface with python through a python API, for accessibility in python scripts. Thanks to SDF Geoff for clearing that up). Not to mention that you can do far more things in python scripts than you can in logic bricks; there is only a limited amount of logic bricks. For instance, you can alter and affect game engine materials in real time with a python script (and with the addition of a little knowledge of GLSL, you can do some fancy sh*t).

~~~~~ Sound files ~~~~~

When using sound files in games, it’s best to use the smallest, most compressed files that diminsh the least amount of quality possible. Commonly, game makers use wave files (.WAV), these are HUGE, but hold the best, rawest quality. However, .WAV files are Microsoft files, and have compatibility issues with Linux and Macintosh.

What is the best sound file type?
The situation isn’t: one size fits all.
MP3 files are small, and globally compatible, there are even devices that play ONLY MP3 files. They are very small, and very good quality. HOWEVER, MP3 files, under certain encoders, WILL ADD EXTRA EMPTY SPACE TO THE START OF A FILE; when exporting MP3 files, the encoder will add a second of silence, if not accounted for in the development of your game, there WILL BE a delay between the causation of the sound, and the sound itself.
Ogg Vorbis files (.OGG) have very similar size and quality to MP3 files, but are less compatible; their compatiblity is only limited to Linux, Windows, and Mac, and some mobile devices. Other mobile devices do not recognise OGG Vobis. They also, on the other hand, do NOT add silence in encoding.
When it comes to deciding what file type to use for sound, it’s usual that MP3s are used for music, because the time the music starts isn’t as important hearing things react in space, in real time. However, .wav files are usually used as the smaller, shorter sound effects, like gunfire, collisions of small objects, small speech, and footsteps. I would personally recommend OGG Vorbis files for EVERYTHING. .wav files are much too big, the size of a game can very much influence someone’s decision to download it at all, and .mp3 files are far too inconvenient with that God awful silent introduction.

Something to note, though:

Though we can’t confirm any reason why this would happen, it’s safe to bet that it’s probably because WAV files are raw sound files that don’t need to be de-encoded and uncompressed, whereas; mp3 files need de-encoding and thus, use up the logical process. (Unconfirmed, but the statistics support the idea that raw is better for performance, but compression is better for storage and overall file size)

~~~~~ Texture files ~~~~~

You hear a lot about streamlining games with specific types of image files. For instance, TarGA (.tga) is said to be the fastest because it compresses the best. Portable Network Graphics files (.png) is also said to be best used for small textures with alpha channels; such as foliage, fire, smoke, and glowing effects. And JPEG (.jpg | .jpeg | .jpe) is claimed to be the most common, and best compressed (No alpha channel though).

What IS the best file type?
Much like sound files, image files are also highly dependant of the situation the textures are used in. As mentioned earlier, .png uses alpha texture, as does .tga, and these are best used as smaller textures when alpha texturing is enabled in the material settings. They both compress very well, but no better than .jpeg.

With a colour image compression test, with no alpha texture:
The JPEG compressed the 512 x 512 image to 160kb
The PNG compressed the 512 x 512 image to 161kb
And the TGA, 512 x 512 colour image, 855kb

With an alpha compression test, PNG vs TGA:
The PNG compressed the 1024 x 1024 image to 874kb
The TGA compressed the 1024 x 1024 image to 3.56mb

So overall, it would seem the TGA file format is actually useless. However, compressing with PNG takes a lot of power and time, simply using the maximum compression on a small, 1024 x 1024 image, it took more than 5 seconds. That doesn’t seem like a lot, but compared to the instant compression of TGA or JPG, it’s more than approx. 30 times slower. So when compressing large terrain textures or height maps, use .jpg, don’t use white and alpha, use black and white.

Alternatively: (As pointed out by BluePrint Random)
DirectDraw Surface (.dds) texture images are optimised for compressed states in vram, to save storage and improve performance. Accessible in GLSL through the ARB extentions, available since Open GL 1.3.
I’ve not used them so I can’t really comment further, but I would highly recommend acquiring a GIMP plugin to export with .dds texture formats (Or Photoshop, if that’s your preferred image manipulation application).

If anyone would like correct anything I claimed or remarked on, you absolutely should; It’s better to be right than proud.

I like this list, but have a few points to make:

logics bricks are actually coded IN PYTHON.

Not quite. They’re native C++, but with a python API

.WAV files are Microsoft files, and have compatibility issues with Linux and Macintosh.

I have yet to find anything that can’t play .wav files. Even MP3 players, cellphones, the most basic linux install etc. can play .wavs fine. You get far more compatibility issues with .mp3. Some linux installs won’t do mp3’s without installing special packages.
But yeah, I use .OGG for everything.

Other than that, excellent post.

During testing I found that using mp3 files seems to drain logic performance in game compared to WAV files.

I don’t know why, and honestly the total logic overhead is pretty small, but it’s something to take in to account.

With a shooting setup (pressing fire adds an empty set to play the sound) I got the following changes in logic tic rate:

MP3 0.12ms
WAV 0.03ms

Perhaps it wouldn’t matter to you, but if you’re making a game with a lot of short sound effects like an RTS or maybe a music synth game it’s something to bear in mind.

Huh, that’s rather interesting. I’ve responded to this idea in the main post, but that’s definitely interesting.

Please do not even mention that logic bricks are python. They are not. This leads to an incorrect view onto the whole system (I saw that already).

Logic bricks are native code!

The GUI of the logic bricks (what you can see in Blender) acts as a simple to use configuration tool. That is why even artists find it pretty easy to use logic bricks to describe behavior [this is what logic is about]. The price of this simplicity is, that it is less flexible and less dynamic.

The Python controller is a (native code) logic brick too. The called Python code is as it says Python code. This architecture allows to create a “custom” logic brick which adds the missing dynamic and flexibility.

Logic bricks can be accessed, configured and used via Python (means via another logic brick) because they are an essential part of the behavior description. The logic bricks do the same thing (just in native code). One of the frequent beginner mistakes is to forget to implement the logic brick interaction (e.g. checking the sensor status). They describe the behavior of an actuator (manipulating the scene) and wonder why it behaves like a controller (faq: double execution of the Python controller).

The above explanation sounds like you recommend to do everything in Python. This is a strange recommendation. Especially as it comes with a few but weak arguments.

I think the best way is - as usually - somewhere in the middle. Having logik bricks and Python is not a weakness. It is a strenght. Everyone who recommends to limit yourself to one aspect, limits the power you can have within your game development. Use the right tools in the right situation.

This will finally result in a mix of Logic bricks and Python controllers. When to use what tool (logic brick or Python) comes with your experience and skills. My experience says, if someone creates chaos with logic bricks, he creates even more chaos with Python too. Even with the “so primitive” logic bricks you still need to know what you are doing.

Actually, I wasn’t really recommending anything, I was just explaining the strengths and weaknesses of each; logic and discrete Python scripting. It was a very limited explanation because I have a 10,000 character limit. But I would personally recommend Python scripts that are ultra tailored and specific to your needs; Python scripts that replace logic bricks by doing the same thing, but are better suited to the developers needs.

But, if you can’t learn Python because you’re limited in time, or you feel like you don’t want to learn Python, then you can absolutely use logic bricks, because they are flexible enough to make very complicate games.

And to do with logic bricks being natively coded in C++, I was aware that everything in Blender is coded in C++, and that Python interfaces C++ in Blender; This post was aimed at people that didn’t know anything already, and that saying logic bricks were coded in Python is easier to understand than saying: logic bricks can be used in Python scripts because there are classes built-into the Python API of the game engine, that interface with the underlying C++ coding of the engine.

Very nice write-up. As a side-note, my launcher that encrypted the blend files used a hack that basically messed with the binary values of the blend file. So, Blender couldn’t load such a file or append from such a file - it’s basically not a blend file anymore at that point. It’s still very easy to reverse-engineer, but it’s something to keep most people out of there.

Saying logic bricks are coded in Python is an incorrect statement. The correctness of statements does not depend on the understandibiliy. Even more as you direct this post towards beginners it should be correct. Better look for a better phrase (I know this is sometimes hard) rather then publishing incorrect facts. They are not helpful.

While Blender is coded in C and C++ the resulting code is native code, which is not C or C++ anymore. So there us no C++ interface either.

It is the other way around. Blender and the BGE provide interfaces to the Python interpreter. These interfaces are the Python API, usually known as Blender API and/or BGE API. This way you can write Python code that communicates with native code. The Python code gets executed by the Python interpreter.

–> The Python interpreter communicates with the native code of the BGE via a defined API.

The API can but is not limitted to communicate with logic bricks (e.g. game objects, scenes are no logic bricks).

To the Python coder everything looks like Python. He looks through his Python glasses.
The logic brick coder looks through his logic brick glasses.
While both look at the exact same thing, they have a different views on it.

Indeed the Python googles show more details. The price is - the viewer needs much more skills to use it :wink: with less support (GUI).

Hint: when you exceed 10 000 characters you can split your thread. You have several topics anyway.

I would liken it to python being a screw gun, and logic a hammer,
they are both required, and one can’t do the same job as the other, they both have strengths and weaknesses.

~~~~~ Multi-Blend-file World Settings ~~~~~

When you open a blend file, from another blend file, the world settings of the first scene will carry over onto all subsequent scenes from the other blend files. This includes most scene settings and render settings. So just be careful of that.

This also occurs, limitedly, with scene changes during runtime, aswell. When your first scene is set to run at 1280 by 720 resolution, the following scene you load, through logic bricks, will also be displayed at 1280 by 720, by default, regardless of the camera setting in that scene.

To be continued…

As far as I know, though, the Framing settings are per-scene as well, so keep aware of that, too.

That is a very good point. When making a game, it’s important to match the available resolution/s to the end-user’s monitor/s. Thus, when using ONLY a 4:3 resolution for you game, the result for a 16:9 resolution screen will be awful black bars; just, a bunch of wasted space.

Two work-arounds, not using letterbox framing, and offering multiple resolutions for both 4:3 AND 16:9.

~~~~~ Helping Hands - The Free Community ~~~~~

Extra Credits

Now, ‘Extra Credits’, these guys know what they’re talking about. They discuss and analyse the deep stuff: “Graphics vs Aesthetic”, Anti-Feminine Sexism, Balance in Game Mechanics, Early Access and it’s flaws, the potential of games in Education!

This channel has an outrageous wealth of information about making games, and what games are. I’ve seen every video and I can honestly say that it is worth every second.

Game Theory

Game theory is a show that analyses and discusses anything gaming. From racism and sexism in games, to top ten game soundtracks, to how the gaming community is damaging video games. Ofcourse, it’s sometimes rather controversial, so maybe just watch and listen with a pinch of salt handy.

The Co-Optional Podcast

Ofcourse they don’t really discuss game design, or game music, or many things to do with game development (and when they do it’s usually speculative). But they are really entertaining, and have a very good insight into how GAMERS work: what gamers want, what gamers like, how gamers behave when they do well/do poorly.

Solar Lune

I recommend SolarLune for those that want to learn how to make music, although the most benefit would be for those that like to create techno and chip-tune, but the skills and techniques are transferable.

Although, he does have some rather insightful devlogs and other videos that can help you with your development process.

He also does tutorials on pixel art; there’s a video in there about using 2D sprites in the Blender Game Engine ;D


Goran does tutorial videos that are expressly from his own forum; he goes through the forum, picks a topic, and step by step makes a video detailing exactly how to do it. I, myself, have used several of his videos to help me. Very worth a look-see.

https://www.youtube.com/watch?v=bWKGFRBX1Rw // Python tutorial

AGoose is actually responsible for my having learnt python. It was his videos that taught me the fundamentals of Python, and even programming. I was an awful novice before I watched his videos, but they helped me so much I can make an entire video game on my own.

And on top of that, go explore, don’t be afraid to Youtube something. Even a simple Google search can get you on the right track. There’s A BUNCH of information out there, and plenty of people that can convey it.