Game Making & Editing FAQ/Q&A
The content on this page is the result of providing answers to Frequently Asked Question asked of Search Engines.
Questions that often go partially or fully unanswered that gamers, content creators and developers want to know about making games, gaming in general, game editing, modding, developing or creating content for games.
If you don't see an answer to a question you may have asked - which is what brought you to this page - then send it in and KatsBits will answer it or find one for you.
December 21, 2014, 04:52:17 AM by kat
Guest posting is OFF/DISABLED
Due to the amount of spambots and bots in general hitting the forums Guest posting has been disabled.Membership (free) is now required to post messages to the forum.
December 01, 2014, 04:12:30 PM by kat
[image courtesy Blender.org]
Note: the following concerns issues of Licensing and Copyright and should not be construed as Legal Advice. Consult appropriately qualified Council where appropriate.Q: I made a game with Blender Game Engine. Can I sell it?.A: Yes you can.Introduction
Blender Foundation has made it explicitly clear
that Blenders Game Engine (Blender Game Engine run-time) can be used to make and sell games and other projects so long as relevant components are released under the same terms as the GPL/GNU License accompanying the application.
To understand this two points need to be made however;
- 1) that anything MADE with Blender is consider OUTPUT and not related to the parent application .
- 2) this being the case, licensing only then applies to the PARENT application and its derivatives .
In other words licensing requirements apply to Blender
, Blender Game Engine
(and distributable run-time) and their direct derivatives
- re-brands, alternative builds of Blender itself, the Game Engine, would fall under GPL, NOT content subsequently made with those alternatives (subject to the following).
Understanding this is important because it directly affects the relationship game/content creators have with Blenders GPL/GNU and their material when wanting to distribute or sell BGE based games.Blender Game Engine & Content Licensing
At face value then, the principle behind GPL/GNU Licensing might seem relatively straightforward; anything directly related to the application itself, or the Game Engine (and) run-time, is subject to GPL.
This is problematic however, because depending on the authors intentions, Blender Game Engine powered games typically require project materials to be 'packaged' into a self-contained executable which then subjects everything therein contained to GPL/GNU exposure . This is another core point to understand, that anything included in the run-time is exposed to GPL
The way around this problem is to develop the project so the final game doesn't require media being packaged directly into the Blender Game Engine run-time . This may be easier said than done but essentially the final games structure would be similar to the following;
- bge.exe (2MB)
- /assets/ (200MB)
- - /models/
- - /audio/
- - /textures/
- - /etc.
Instead of this;
/myBGEgame/Link, don't Append
- bge.exe (202MB)
How this separation is actioned will depend largely on the game itself and the way its intended to work. Generally speaking however, where-ever possible "Link
" rather than "Append
" assets into a project - textures, models, audio should all be contained in external context-sensitive folders which ensures content is, and remains, outside Blender - at run-time generation only core scripts and files required to make the game function should be included, not the assets.Selling games that use Blender Game Engine
With the above in mind then, the minuté of selling a Blender Game Engine product depends on whether or not the Author is willing to provide access to content 'flagged' as GPL/GNU, a decision that should be made at the projects inception because, as indicated above, doing so informs as to the structure and utilisation of the projects assets - self-contained run-time, or not as the case may be. With this done, should a customer purchase the game and make a request for GPL'd material(s), the Author only then need provide access to the actual component(s) explicitly subject to GPL/GNU etc. - either the entire packaged contents, or just the 'exe', again as the case may be.
In terms of how that relates to store fronts, distribution channels and the end product (selling on Steam for example), GPL'd content shouldn't have an affect unless third-parties have specific restrictions on the sale and/or distribution such material(s) . Some do, so attention should be paid to their respective Terms of Service beforehand (preferably at the planning stage) to make sure the eventual project can be sold via chosen outlets once completed .
 http://www.blender.org/support/faq/ - file OUTPUT, to third-party formats as well as *.blend, is not related to Blender from a licensing point of view because it's essentially considered to be nothing more than a databump (although proprietary in format, i.e. *.blend files can't yet be open in other applications because of the way they are formatted, not because of some restrictive interpretation of the license).
 GPL/GNU requirements apply to Blender itself and any derivatives of the application. For example if a new version of Blender were produced by a company absent core features, this new version would still be subject to the same GPL/GNU license requirements as the original 'parent' application which requires source data availability for each new iteration.
 any content packed into a BGE run-time is subject to the same license requirements as Blender/BGE because it's executable package that's under license, not the content - include the latter into the former and its instantly subject to GPL.
 depending upon the version of Blender used, Game Engine project are saved from the main "File" menu, usually as "File » Save Executable/Run Time" or from "Export" menu as "File » Export » Save As Game Engine Run-time", which may need to be activated as an "AddOn" from Blenders "User Preferences".
 the reason for this generally relates to Service Providers (store fronts) not wanting to get involved with the type of issues that typically accompany Copyright or Licensing GPL'd or otherwise 'open' software, and individuals selling content they may not actually have permission to do.
 although it's technically possible to split a game in two and sell the assets whilst giving the run-time away freely, it's unlikely Store Fronts will allow this because it essentially means they are potentially liable for selling products that don't actually work (not fit for purpose).
September 23, 2014, 06:39:32 PM by kat
How tall is the Minecraft Player
It depends how the unit of measurement
is defined. By default the blocks that make up the Minecraft world are regarded as being one cubic metre in size, and textured with a 16 x 16 pixel image
. This means each pixel
, at face value, represents 6.25 centimetres
exactly (100cm / 16 = 6.25cm). So;
With this unit of measurement calculated it's then possible to work out Minecrafts player size based on the pixel distribution of the texture assigned to it. Again at face value, the 64 x 32 pixel PNG breaks down to (in pixels);
- head = 8 x 8 x 8
- torso = 12 x 8 x 4
- legs = 12 x 4 x 4
- arms = 12 x 4 x 4
And using the above calculated unit of measurement, in centimetre this represents ([units]
x 6.25cm = [n]
- head = 50cm x 50cm x 50cm
- torso = 75cm x 50cm x 25cm
- legs = 75cm x 25cm x 25cm
- arms = 75cm x 25cm x 25cm
For a total height of exactly 2m (200cm), the height of two building blocks (as seen in-game, notwithstanding camera angle).
*It's important to note these measurements assume textures and their respective distribution across surfaces is uniform for all world and character objects alike, i.e. whilst the calculations may be correct in a absolute sense, it does not necessarily mean they relate to the character actually being the determined height in-game because, as a dynamic entity, it could be being resized/rescaled in-game for any manner of reasons to look slightly shorter or larger even though its underlying dimensions are fixed (similar to the way Blender can 'Scale' an object whilst leaving its underlying dimensions untouched).Problems with Minecraft character height in Blender
- Minecraft player height = 2 metres*
Having worked out the characters height logically per the above, it is however at odds with other aspects of the game that suggest slightly different dimensions when used to determine player height in Blender.
For example, the characters hitbox
- the area used to define the players volume for collision/interaction with objects in the world - is given as being 1.8m
high by 0.6m
wide by 0.6m
deep (1.8m x 0.6m x 0.6m - based on console output), making is slightly shorter and less wide than the general dimensions of the character. Whilst not specifically meaningful on it's own, using this information to define character height can be problematic as a result - the player is too short a slightly too wide.
Similarly, the players eye-line
(the cameras POV) is defined (again) by console coordinates as being 1.62 metres
from the ground. In terms of pixels measurements however, the eyes occupy the fourth row up from the bottom of the head and are actually 168.75cm
from absolute ground level, and 25cm
from the top of the head (occupying a row between the two and just below the middle of the head, of 6.25cm high). Similarly using this data to determine Minecrafts player height can be problematic, leading again to it being slightly shorter than the above two metres.
Minecrafts building blocks are regarded as being one cubic metre (left), two of which approximate the height of the player. Using the way textures are assigned and their relative pixel density, it's possible to work out just how large the player should be in Blender - the hitbox (shown right) is often cited as a height reference but results in a character that's a little too short compared to ingameMinecraft Player height in Blender
For the purpose of making animated scenes and other Minecraft related content in Blender then, there are a number of ways to go about sizing the character in relation to other objects in a Scene. The most straightforward is to translate pixel dimensions and numbers directly into Blender Units. This will work so long as other content is then appropriately adjusted and proportioned, i.e. if the player is 32 pixels high, in Blender this can be interpreted as 32 Blender units or 3.2 Blender units etc. (depending on where the decimal should be placed if used), making a world block half that at 16 or 1.6 units cubed. However, doing this can become confusing if Blenders Grid
is not set to use different "Subdivisions" and "Scale" which by default is using 10 subdivisions - in relation to the former, the Grid might be better set up akin to content production for BSP idtech/UDK type editing so "Subdivisions:8" and "Scale:8" might provide better grid arrangements than the defaults (although each block representing one metre, but being subdivided by 16 does make for an odd combination).
When Minecraft measurement is translated directly into Blender units it can mean the resulting character being extremely large (shown right). Using a lesser unit size, centimetres for example, the character is more reasonably sized relative to the Scene (shown middle) but is technically a little too tall to work exactly with other items (world blocks being 1 x 1 x 1 for example). Whereas once the correct unit size has been determined (shown left) the result fits perfectly within context (but does mean a direct 1:1 conversion of units isn't possible and some math needs to be used)Character Skin info & generic templates
Default texture sheet for a typical Minecraft character is 64 pixels high
by 32 pixels wide
(64 x 32) in PNG format
(with transparency where required).Additional Resourceshttps://minecraft.net/community
(official resources page)http://minecraft.gamepedia.com/The_Player
August 18, 2014, 06:46:43 AM by kat
Q: How many feet, inches or centimetres are there per Quake Unit?A: None.Long Answer
Although content used in Quake and other BSP based games can be modelled in various 3D applications using real world units of measurement, doing so does not
directly translate into anything meaningful in idTech (Quake/Doom engines). This is because 'unit', as that term is normally understood, is an arbitrary value relative to the real-world and other software - whilst the former has physical attributes that ensures the 'unit' has meaning, the latter does not - a simple cube measuring one inch cubed (1x1x1) exported from Blender, 3DS Max, Maya or any number of other 3D applications, may be comparatively different sizes (when placed next to each other).
This generally means when building content, for example a wall 256 "units" high, the actual 'unit' reference, i.e. whether measured in "Metric" or "Imperial" units, should be ignored in terms of preferentially indicating the size of objects because, relative to the aforementioned game engines, they have no meaning. In other words;
One "quake unit" is not equal to
one "inch", "centimeter" or "foot". It is equal to one Quake Unit
For example, a typical door in RtCW is 64 units wide by between 120 or 128 units high. Relative to a standard AI Soldier's physical attributes, realistically the door should be approximately 48 units wide by at most 112 high (more often 104). This doesn't work in game for two main reasons; 1) character collision boxes and 2) differential size of characters and their affect on the former - B.J. is about 6' 2" (six foot two inches) and looks down on most of the enemy AI, making them significantly smaller (which is often why they look tiny walking around a level; when building and running through a game, the players point of view is significantly different; one of the reasons why switches and buttons look fine to the player but like gigantic fairground mallet hitting targets when an AI stands next to them).
In other words, if a door is modelled properly to represent real-world sizing (approximately 2' 6" wide by 6' 6" high) it can cause navigation issues for both the player and AI because it's likely going to be too small despite being visually (or technically) correct (again relative to the real world) - doors, like everything else, need to fit the relative size of the players perspective and each characters physical dimensions, rather than being specifically 'measured' to a given size as represented by real-world units.
To ensure objects and characters are correctly sized, the best approach is to make use of a set of Radiant/UEdit references blocks
, that way everything is sized relative to a fixed, common, reference.
June 13, 2014, 09:32:28 PM by kat
Occasionally Blenders User Preferences
pop-up window either does not show, or when it does is corrupted when accessed from "File » User Preferences
" main menu. The likely culprit is a graphics card driver with broken or poorly implemented OpenGL which can manifest in problems displaying multiple layers of OpenGL content (which Blender uses to draw it's interface). Whilst not a fix in of itself, the following tip should allow access to User Preferences, not as an overlay, rather as an 'Editor'.Solution
From any view (typically the 3D View), click the "Current Editor Type
" button far-left of the menu-header under the active window and select "User Preferences
" from the list. If there are no fundamental issues with Blender itself, the view should switch to the appropriate window absent and display issues. If not then it means there is a fundamental problem either with the installation of Blender (in which case re-download and re-install the file, or download an earlier version to see if the same problem exists).
User Preferences not properly displaying when accessed from the "File
Instead of accessing from "File" menu, select "User Preferences" as a "Current Editor Type" view
User Preferences shown as an 'Editor' type. Switch back when done