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.

Click to get the RSS master feed

FATAL ERROR: wglCreateContextAttribsARB failed

May 19, 2015, 02:54:36 AM by kat
The "FATAL ERROR: wglCreateContextAttribsARB Failed" error occurs as the result of an unsuccessful attempt by a video game to start and use a unsupported version of OpenGL. For example, if a system has an onboard Intel HD 3000 embedded graphics chipset and a game like Wolfenstein: Old Order is started, the "wgl..." error will occur because the chipset only supports OpenGL 3.1 or below. OpenGL 3.2 or above is required for such games. As the solution is driver dependant, a fix relies on the hardware manufacturer updating to include support. For older hardware this is unlikely to happen.

Note: for systems with dual graphics capabilities where one of the subsystems is Intel based, the error can be fixed by switching drivers (subject to it also providing support for the correct version of OpenGL).

Valve & Paid Content/Mods unofficial FAQ's

April 24, 2015, 11:23:56 PM by kat

(Click here for comment)

[updated 28th April 2015]

The following is an unofficial list of common or frequently asked questions about Valves new Paid Content initiative.

Notice: The following is provided for informational purposes only and should not be construed as advice pertaining to Tax or Legal matters. Persons are urged to seek advice from appropriate qualified Advisors BEFORE signing or submitting any Legal or Tax documents.

Q: Valve is taking 75% of revenue
A: It's a bit more complicated than that because it depends on how Valve manages it's Tax Obligations with respect to Workshop sales, and how permission to sell items for a specific game has been granted. With respect to the latter this is likely granted through LICENSE so a FEE or ROYALTY will be due on any transactions, paid by Valve to the licensor - the games developer or publisher. This should be from Valves split of the revenue because it's an interest THEY are obligated to as licensee's of the Developer/Publisher. However, this might not be the case and it may be taken from the overall income (which reduces the revenue of the creator and Valve, not just Valve). As this is an aspect of VALVES business it's unlikely this will be clarified[$].

Q:Modders earnings are tax-free (I)
A: To receive payment individuals are required to provide valid Tax information (IRS form W-9) before any monies are transferred. Once verified, US citizens are subject to a 30% withholding on any payment as part of their individual Tax obligation on Income. Non-US individuals however, are not, providing they file the appropriate paperwork (W-8BEN) to claim the 30% withholding. The ability to do this varies from Country to Country and is subject to Treaty between the USA and other Nations. Assuming creators are set to receive 25% from every $1.00, for US Citizens this would mean receipt of $0.175c ($0.075c with-held for Tax) not $0.25c. For non-US individuals they would similarly only receive $0.0175 UNLESS the correct paperwork were filed to claim the with-held amount.

Q: Modders earnings are tax-free (II)
A: This will depend on the local jurisdiction of the individual in receipt of monies. Generally speaking in submitting Identity and Tax information to Valve, the applicant is essentially declaring themselves to be SELF-EMPLOYED (in intent rather than specifically designation, i.e they are earning money thought their own efforts rather than someone else) making earnings TAXABLE INCOME regardless of the applicants employment status. US citizens are Taxed at SOURCE (which can be claimed back to varying degrees based on entitlements, over-payments etc.), whereas NON-US persons would be obligated to SELF-DECLARE revenue to an appropriate Tax Authority (HMRC if the creator was a UK Citizen for example). So even if earnings were received in full (as per point "I" above) giving the appearance of being tax-free earnings, they are in fact not, because a burden is due, income being regarded as Taxable and needing to be declared regardless.

Q: Mods should be free
A: As noted above traditionally speaking mods have largely been "free" because there were no viable mechanisms in place to charge money. This is not to say that mod creators have not looked to wanting this, and more important that in their not being able to do so, no revenue was ever generated; it has, but not for the mod creator - revenue is generated by the mods web hosting party through adverts positioned on the download page or their offering 'premium' or 'subscription' based services to either bypass advert display or the provision of some perks available only to paid members of said service. Creators do not receive any of this revenue.

Q: Does receiving money make me a 'professional'
A: In a word, yes, once a person receives money as compensation for their labor or output they should regard their activities as efforts to earn income as a "Self-Employed" or "Sole-Trader" entity (or whatever the local jurisdiction definition is for an individual working for themselves). In the UK for example this might mean the individual being required to declare such income through Self-Assessment, even if they occupied a position as an employee of someone else (exemptions may apply). Within the context of revenue generation, being a "professional" has no bearing on the quality of output and only relates to an individuals respective employment or income status with the relevant Authorities.

Q: Do I have to pay Tax on Valve income
A: Yes. Monies received are considered INCOME so tax is due on the amount received. This is either withheld at purchase, or claimed back and accounted for at year-end. In both instances there are records of all the transactions leading to revenue generation and personally identifiable information confirming the individuals declaration of their Tax (and indirectly employment) status with Valve (and IRS once Valve submit that paperwork to the IRS as part of their year-end accounting).

Q: It's about "free-expression" of ideas
A: It's not. Whether a person elects to receive payment for their output has absolutely no bearing on their ability to freely express their ideas except where they may be impeded by efforts to put food on the table, keeps the lights on etc., no different than any other occupation. That is not to say the pursuit of income may bias creative output towards the production of more populist products, a decision to be made by the individual, and as mentioned has no bearing on a persons ability to freely express their thoughts or ideas beyond having the materials available for that purpose. This is notwithstanding that, to a creator who elects to receive payment for their efforts, ideas are 'work'; to be "Made Real"™, varying degrees of expertise, skill, labor, materials, resource consumption are required that do not exist in a financial vacuum, especially for those operating under their own efforts (self-employed/sole-traders/proprietors).

Q: People will game the system to earn money
A: Whilst this may happen there are a number of deterrent in place to prevent, if not mitigate, the problem. First, Valve has the creators personal and financial details on record so shenanigans in which individuals partake may be punished retroactively through the issuance of payment reversals - this may have significant repercussions depending on the type of account the individual has associated with their Steam account. Second, whilst some individuals may attempt to game the review system, their product being open to users will likely result in their being called out in a way that either alerts individuals to problems with the item(s), or Valve that the seller is engaged in suspicious activities that need to be investigated.

Q: Creators only get 25%
A: The royalty payment due to sellers using other distribution outlets varies a great deal, for example royalty payments to Amazon, Apple and Google are typically 30% plus fees, once 30% for tax is withheld, leaving the seller with a nominal 40% royalty[1]. GOG has a 70/30 author/service split[2] but may be subject to VAT (at 20%). This also doesn't account for costs attributed to marketing and managing a given project across the Steam Network, which is considerable for Indie developers.

Q: What about selling Mods with dependencies
A: This issue here relates to whether the dependency or any files not part of the mods contents are being distributed along with it. As this is third-party material, permission to distribute WILL BE REQUIRED from the author of the dependency. As an example, if mod "A" depends upon some or all of the content from mod "B" to work, to include and distribute that material the author of mod "B" would need to give their consent (and whether or not they want to be compensated when a sale occurs). Furthermore, customers will need to be INFORMED that mod "A" depends on mod "B"[3].

Q: How do I prevent someone else selling my Mod
A: Once the situation has been confirmed, that person "A" is indeed misappropriating the work person "B", it's up to the latter, person "B", to issue a DMCA Take Down Notice to Valve's DMCA Agent who are then obliged to remove the material described in the Notice until the person being claimed against either issues a DMCA Counter Notice, or they remove the offending material. It's important to understand that it's not possible to prevent others misappropriating material without permission, the system, and Copyright, doesn't work like that - it's 'reactionary' not 'preventative', DMCA is invoked once an infringement has been discovered. For more information on DMCA click here.

Q: Apple gives a 70% cut, not 25%
A: Whilst Apple may issue a 70% split to authors, their doing so is conditional and applies only in certain circumstances that ostensibly relate to the way Tax obligations are managed. Apple and ALL US-based entities are REQUIRED by the IRS to withhold 30% of ALL income for Tax purposes, Apples own fees are c.30%, which leaves the author a nominal 40% split of sales income. If said author is exempt from withholding and applies for that exemption (the exemption MUST be applied for AND claimed), they can claim the 30% withholding, which raises the nominal 40% to 70%[4].

Q: It complicates revenue split for mod teams[/size]
A: Valve, and their Paid Mods service, have no bearing on the way mod teams decide to split their income, a discussion that should be negotiated internally between individual team members. Doing so is a important aspect of taking the next step up the development ladder towards being a "professional" content developer or concern as the receipt of money implies.

Q: Who owns the mod once it's made available
A: In a word Bethesda. In accordance with the Creation Kit EULA, immediately upon distribution of a mod or content the author agrees to waives ANY AND ALL RIGHTS to the content, including being able to assert a "Moral Right" (Authorship) over said Content.
If You distribute or otherwise make available New Materials, You automatically grant to Bethesda Softworks the irrevocable, perpetual, royalty free, sublicensable right and license under all applicable copyrights and intellectual property rights laws to use, reproduce, modify, adapt, perform, display, distribute and otherwise exploit and/or dispose of the New Materials (or any part of the New Materials) in any way Bethesda Softworks, or its respective designee(s), sees fit. You also waive and agree never to assert against Bethesda Softworks or its affiliates, distributors or licensors any moral rights or similar rights, however designated, that You may have in or to any of the New Materials.

[$] unconfirmed at time of writing, Bethesda's cut is being claimed to be 45%, Valve's being 30% (in line with other distribution networks),
[1] the actual revenue split varies depending on the type of items is being purchased and the currency to which final payment is made (this may incur exchange fees for non-US based sellers). Non-US purchases would also be subject to VAT in Europe or other forms of Sales Tax elsewhere.
[2] GOG offers two basic revenue splits, 70/30 standard royalty, and 60/40 for an 'payment advance' split. Note that GOG being part of CD Projekt, a EUROPEAN Company, means that Tax obligations differ - there is no withholding, but VAT is applicable at 20% - so revenue splits may appear much better.
[3] where dependencies are applicable it would be a courtesy to inform potential customers whether such is available freely or for cost.
[4] this does not account for other fees and charges that may be due on the revenue, currency exchange rates, international deposit fees and so on, depending on how the money is managed, which can be especially complicated and costly for Non-US based Entities

Guest posting is OFF/DISABLED

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.

Selling Games made with Blender & GPL/GNU Licensing

December 01, 2014, 04:12:30 PM by kat

[image courtesy]

Note: the following concerns issues of Licensing and Copyright and should not be construed as Legal Advice. If in doubt, do not assume, Consult appropriately qualified Council where necessary.

Q: I made a game with Blender Game Engine. Can I sell it?.
A: Yes you can.

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 commercially 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;
  • 1) anything MADE with Blender is considered OUTPUT and not related to the parent application [1].
  • 2) this being the case, licensing only then applies to the PARENT application and its derivatives [2].
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 and content creators have with Blenders GPL/GNU and their material when wanting to distribute or sell BGE based games for commercial gain.

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, and in doing so then subjects everything contained to GPL/GNU exposure [3]. 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 be packaged directly into the Blender Game Engine run-time [4]. This may be easier said than done but essentially the final games structure would be similar to the following;

Code: [Select]
 - bge.exe (2MB)
 - /assets/ (200MB)
 - - /models/
 - - /audio/
 - - /textures/
 - - /etc.

Instead of this;
Code: [Select]
 - bge.exe (202MB)

Link, don't Append
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) [5]. Some do, so attention should be paid to their respective Terms of Service requirements beforehand (preferably at the planning stage) to make sure the eventual project can be sold via chosen outlets once completed [6].

[1] - 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).

[2] 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.

[3] any content packed into a BGE run-time is subject to the same license requirements as Blender/BGE because it's the executable package that's under license, not the content - include the latter into the former and its immediately subject to GPL.

[4] depending upon the version of Blender used, Game Engine projects 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".

[5] 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 - it's something of a grey area where third-parties are concerned (reselling OpenSource Software) so distribution channels tends to stay away from it.

[6] 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 under various 'merchantable quality' laws for selling products that don't actually work (not fit for purpose).

[Minecraft] how tall is the Minecraft player in Blender

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;
  • 1 pixel = 6.25cm
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).
  • Minecraft player height = 2 metres*
*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
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 ingame

Minecraft 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 Resources (official resources page) (official Wiki)

  • Visit KatsBits Store today
  • Blender Art Magazine