Planet Gamedev

Gamasutra Feature Articles

RPGs that brought something new to the table: The revenge

August 31, 2015 02:43 PM

"One of the things I most enjoy about RPGs from the 70's and 80's is that 'frontier' feeling, as no one had a blueprint on how to things, people just kept trying different things." ...

Game From Scratch

Unreal Engine 4.9 Released

by at August 31, 2015 02:38 PM


Today Unreal announced the release of version 4.9 of the popular Unreal Engine.


Unreal always have fairly massive release notes, so here is the short hand version:

  • Enhanced Support for Mobile Devices
  • Dynamic Character Shadows for Mobile
  • Dynamic Point Lights for Mobile
  • Decals on Mobile
  • Major VR Updates
  • New VR Motion Controller Support
  • Experimental Direct X 12 Support
  • Full Scene Particle Collision with Mesh Distance Fields
  • Hierachical LOD Fast Preview and Clustering
  • Arch VIS Character Controls
  • Widget Depth ordering
  • Area Shadows (For Stationary Lights)
  • Ambient Occlusion Material Mask
  • Mesh Distance Field Materials
  • Improved Distance Field Ambient Occlusion
  • Content Browser Advanced Search
  • Collection Improvements
  • Plugin Creation Wizard
  • Enhanced Curve Editor
  • Multiple Return Nodes in Blueprints
  • Construct Custom Objects in Blueprints
  • Blueprint Class Defaults
  • Blueprint Communication
  • Optimized Math Expression
  • Blueprint Asset IDS
  • Montage Element Timing Interface
  • Non-Linear Animations Blending
  • Bone Driven Animation Controllers
  • Animation Transition Rules
  • Animation Curve Evaluation Change
  • Animation Asset Metadata Support
  • Sound Quality Levels
  • Custom Audio Attenuation Curves
  • Actor Tick Intervals
  • Actor Encroachment Detection
  • Post Process Blending
  • Runtime Asset Cache
  • Volume Decals (Experimental Only)
  • UE4 Documentation Tags, Version and Skill Level
  • Updated UE4 Documentation
  • Async Real-Time Audio Decompression
  • Shared Resources for Feature Packs and Templates
  • Improved HTML5 (Easy Setup, Amazon S3 Support, Networking)


This only represents the highlighted features too, be sure to check the full release notes for more details.

Game Design Aspect of the Month

Manga and Games

by (Sande Chen) at August 31, 2015 02:36 PM

In this article, game designer Sande Chen points out parallels between amateur manga and indie game development.

One year, when I was at the SXSW Interactive Festival in Austin, TX, I decided to go to a session on manga called, “How Manga Explains the World.” The presenter was Daniel Pink, author of A Whole New Mind: Why Right Brainers Will Rule the Future.
I didn’t know anything about manga so all of this was quite new to me. I was struck by some parallels to indie game development.

Manga is really popular in Japan. Tons of fans crowd into marketplaces to get the latest comics. However, what they buy is not the official manga put out by the publishers, but the amateur manga, put out by indie creators known as ‘dojinshi.’ The dojinshi use established characters but create different, and sometimes questionable stories, with these characters.

Pink commented that in the U.S., IP lawyers would have a fit if someone did this with a Disney film. But publishers and dojinshi have an tacit agreement known as ‘anmoku no ryokai.’ The official manga industry has been in decline so the publishers look the other way because they figure the amateur manga will keep fans interested in the official manga. In exchange, the dojinshi don’t flood the market and create limited copies of their work.

In fact, this interest in amateur manga helps the publishers. They use the markets as a way to sign up new talent (and offer them a chance to create a new, original manga). They also learn about market trends by observing what fans are buying. Some of these dojinshi become as well-known as the original creators. They could even branch out and do their original stories without publisher backing.

It seems to me that the mod community is a similar model. Successful mod teams do become successful companies with publisher backing. Is the “official” game industry watching the indies? Just by looking at casual games, it appears they do. Do they look to indies as the barometer of what’s to come? What do you think?

[This article was adapted from an original post on the blog Joe Indie.] 

Sande Chen is a writer and game designer whose work has spanned 10 years in the industry. Her credits include 1999 IGF winner Terminus, 2007 PC RPG of the Year The Witcher, and Wizard 101. She is one of the founding members of the IGDA Game Design SIG

Game From Scratch

A Closer Look at jMonkeyEngine

by at August 31, 2015 01:43 PM


In this Closer Look At we look at take a look at the jMonkeyEngine.  The Closer Look At game engine series is a cross between an overview, a review and a getting started tutorial to help you decide if a game engine is the right fit for you.  The jMonkeyEngine engine is a Java based, open sourced, cross platform 3djMonkeyCloserLook_450px game engine that runs on most Java supported platforms and can target Windows, Linux, Mac and Android, with iOS and Oculus VR support currently being tested.  jMonkeyEngine is available as both a game library, or as a set of tools built on top of the NetBeans IDE.  For this closer look, we will focus on the full SDK experience.



This closer look is also available in HD video format here.



Although we are going to focus on the complete set of tools including in the jMonkeyEngine SDK, keep in mind it can be used in library form if you prefer working in Eclipse or IntelliJ.  You will however lose access to some very convenient tools.



Meet jMonkeyEngine


As I mentioned earlier, jMonkeyEngine ships in two forms, as a set of libraries, or as a complete SDK build on top of the Netbeans IDE.  You can download load the SDK for Windows, Mac or Linux right here.  As of writing, 3.0 is the current released version, while 3.1 is available in development on Github.  This version marks the first public release using the Github platform.  jMonkeyEngine has a few prerequisites before installing, but they basically boil down to having an OpenGL 2 compatible video card and JDK 6 or higher installed.


Once downloaded and installed simply run the jMonkeyEngine SDK application.   This is jMonkeyEngine:



As mentioned earlier, this is actually a preconfigured version of the Netbeans IDE with a set of plugins and extensions to support jMonkeyEngine development.  This means in addition to the various jME tools you get a complete modern Java development environment, meaning code completion, project management, refactoring tools, debugging and more.  I won’t be specifically covering Netbeans functionality in this guide.  If you’ve got prior experience in Eclipse or IntelliJ, you should feel right at home.  Personally I rate the Netbeans experience somewhere between the two, with IntelliJ being quite a bit better, while Eclipse is many many many times worse.  That all said, that is purely opinion, each platform has it’s strength and weakness, it’s fans and haters.  If you prefer to use Eclipse or IntelliJ you can.


Hello jMonkeyEngine


It is often easiest to start with a simple project, so let’s do exactly that.  Select File->New Project



A New Project wizard will appear.  All of the standard project types supported by Netbeans are available, but also the new jMonkeyEngine templates are available too.  Select BasicGame and click Next.



Pick a name and location and click Finish.



Your project will now be created.  You can have several projects open in the IDE at the same time, just be sure to select the right one in the Projects panel:



The wizard will have automatically created a project hierarchy for you:



It’s optional to use this layout, but you are making life more difficult for yourself if you do not.  File paths for textures in imported models are absolute, forcing your hand somewhat in how you import your data.  Again, you can code around this design, but you are making your life more complicated.  For the most part I found the layout fairly logical, but the suggestion to import your models into the Textures folder then relocating them to Models ( well discuss this more later ), well that simply a gross kludge.


The New Project wizard also generated a default source file for us,, with the following contents:


package mygame;

import com.jme3.material.Material;
import com.jme3.math.ColorRGBA;
import com.jme3.math.Vector3f;
import com.jme3.renderer.RenderManager;
import com.jme3.scene.Geometry;
import com.jme3.scene.shape.Box;

 * test
 * @author normenhansen
public class Main extends SimpleApplication {

    public static void main(String[] args) {
        Main app = new Main();

    public void simpleInitApp() {
        Box b = new Box(1, 1, 1);
        Geometry geom = new Geometry("Box", b);

        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        mat.setColor("Color", ColorRGBA.Blue);


    public void simpleUpdate(float tpf) {
        //TODO: add update code

    public void simpleRender(RenderManager rm) {
        //TODO: add render code

The code is all pretty straight forward.  You game code extends the class SimpleApplication, which in turn implements Application plus implements some “out of the box” behaviour like key mappings for exiting the application and implementing a camera.  These default behaviours can easily be overridden as we will see shortly.  SimpleApplication exposes three critical methods as part of your games life cycle, simpleInitApp(), called when your app is created, then simpleUpdate() and simpleRender() called over and over by the game event loop.  Basically stick your setup code in the init() method, your update code in the update() method and drawing code in the render() method.  If these methods start getting overly complex, you can refactor your design to use States, something we will cover later on.


You can run or debug your project using the toolbar:



Or via the Run menu:



Once launched you will see a configuration Window.



Select your preferred configuration and click Continue.  You may be asking, can I get rid of this damned window?  The answer is yes you can, but you have to use code to do it.  I can’t really fathom why there isn’t a “Remember my settings” check box.  Once you click Continue, your first app will run.



As you move the mouse cursor around, the camera implemented in SimpleApplication is moving the camera position around.  You may also notice the debug details and of course that startup window.  As said earlier, this can all be override, let’s look at how.

First we can get rid of the configuration window ( which I admit, gets old very quickly ) and set a default resolution using the following code:

    public static void main(String[] args) {
        Main app = new Main();
        // Dont show window
        app.showSettings = false;
        // Create a new app settings loaded with defaults
        AppSettings appSettings = new AppSettings(true);
        // Override resolution
        // Add a title, just because
        appSettings.put("Title", "Super Awesome Megagame 9000!");


Next in our init we add the following logic to disable the camera and debug info. These need to be called after app.start(), thus why they are in init.

    public void simpleInitApp() {
        // Disable fly cam
        // Turn off debug info and FPS window
        Box b = new Box(1, 1, 1);
        Geometry geom = new Geometry("Box", b);

        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        mat.setColor("Color", ColorRGBA.Blue);



Now when you run your game, you should no longer see the config window, nor display stats when running.  Instead you should see:



Importing a 3D Model


One of the first things I do when testing a new engine is check to see how hard it is to get a 3D model imported.  In jMonkeyEngine you have a couple of options, you can import to their native format, use a Blender plugin, support an OBJ file, or import files converted using the Ogre XML toolchain, which is also available as a Blender plugin as well as several other packages.


I will use the native format (j3o) later, for now, let’s look at the process of importing a Blender model, since jMonkeyEngine has solid Blender integration built in.  In fact, jMonkeyEngine actually ships with a copy of Blender as part of the SDK install, currently version 2.69 (as of writing, 2.75 is the most current version).  When you run Blender from within jMonkeyEngine, this included version is the one that is run.  (Note, for performance, you should always prefer using the native binary format unless you have a very good reason not to).


You can add a new textured Blender cube (you don’t have to by the way), right click the desired location and select File->New->Other…



Then select Blender->Box prepared for UV texturing.



Name it and confirm the location, then click Finish.



This will run a copy of Blender and set up a cube with textures defined for you.



What’s extremely odd here is the configured cube isn’t actually ready to go.  You still need to UV unwrap the cube, attach a texture and set the UVmap.   You can see the entire process in the video if you need more details.


You can confirm that the blend file works fine, right click the blend and select View Model.



This will open the Viewer.


Be sure to click the light icon (top left) to enable lighting in the viewer.  Now that we know the Blender file works, let’s move over to the code to load a Blender file.  there is a bit of a challenge first, Blender support is actually added as a plugin, we need to add it in first.


Right click Libraries and select Add Library…



Select jme3-libraries-blender then click Add Library.



We need to add a light to the scene or the model isn’t going to show up.  Simply drag and drop SunLight from to the drop of the simpleInitApp() code and it will drop all the code we need.


package mygame;

import com.jme3.light.DirectionalLight;
import com.jme3.math.ColorRGBA;
import com.jme3.math.Vector3f;
import com.jme3.renderer.RenderManager;
import com.jme3.scene.Spatial;

public class Main extends SimpleApplication {

    public static void main(String[] args) {
        Main app = new Main();

    public void simpleInitApp() {
        /** A white, directional light source */ 
        DirectionalLight sun = new DirectionalLight();
        sun.setDirection((new Vector3f(-0.5f, -0.5f, -0.5f)).normalizeLocal());
        Spatial blenderModel = assetManager.loadModel("Models/demoBox.blend");

    public void simpleUpdate(float tpf) {
        //TODO: add update code

    public void simpleRender(RenderManager rm) {
        //TODO: add render code

And run it:



So other than Blender configuration, getting a model into a jMonkeyEngine app is fairly straight forward.


Tools in jMonkeyEngine


Code Palette

We briefly saw the Palette in action in the previous example.


This is a selection of code snippets you can drag and drop into the editor.  One major gotcha however, many of these samples depend on a library, jme3-test-data, that isn’t included by default oddly enough.  We saw earlier when we set up the Blender plugin the process of adding a library.


3D File Importer

While jMonkeyEngine supports the Ogre XML format and Blend files, working with a game oriented file format is almost always the best performing option.  Fortunately jMonkeyEngine provides just such a format, j3o.  These files can be created easily using the menu File->Import Model menu:



Then select the model



Material/Shader Editor

You can easily create shaders right clicking an Asset folder such as Materials, New->Other…



Then Material->Empty Material file



You can then define a shader using a UI tool.  You can also set a template that other materials inherit from.



3D Scene Composer



The Scene Composer can be use to assemble and create 3D scenes.  There is also a corresponding scene graph:



A variety of game nodes can be created here:



Terrain Editor

In addition to the Scene Composer, there is also a 3d terrain tool:


You can create terrain visually.  Easily pull and push terrain into shape, paint with multiple textures.  The generated terrain can be used in the scene composer.



Engine Capabilities


We only briefly touched upon the code capabilities of the jMonkeyEngine due to time and space restraints.  jMonkeyEngine is a full functioning engine with the following functionality, excerpted from their website.



Documentation and Community

jMonkeyEngine is well documented, with a comprehensive collection of tutorials and guides available on the wiki.  I encountered a few entries that were out of date or invalid, but for the most part the document was solid and easy to follow.  There is also a good reference in the form of the JavaDoc.  I may not always be the biggest Java fan, but I almost always love JavaDoc generated references!

Until recently the forums for jMonkeyEngine were pretty terrible, but thankfully they’ve recently transitioned to an improved forum.  There is an active community and questions rarely go unanswered.  They have also recently transitioned the source code to Github.




There are two books available for jMonkeyEngine.




The Video


Geeks3D Forums

NVIDIA GeForce driver 355.11 for Linux, FreeBSD and Solaris

August 31, 2015 01:05 PM

Linux Display Driver - x86 NVIDIA Certified

NVIDIA GeForce driver 355.82

August 31, 2015 01:03 PM

The latest GeForce Game Ready driver, release 355.82 WHQL, ensures you'll have the best possible gaming experience for Metal Gear Solid V: The Phantom Pain and Mad Max.

Game Ready

Gamasutra Feature Articles

Blog: Why we need to leave 'hobby' behind, as a label for video games

August 31, 2015 01:00 PM

"I will never call games a hobby, because I feel that intrinsic within that word, in the context of this medium, there is something reductive, something controlling. We're in a time of significant cultural tension." ...

Creative Assembly design director joins Sony VR team

August 31, 2015 12:59 PM

Creative Assembly design director, Gary Napper, has revealed he'll be leaving the Alien: Isolation developer to work at Sony - specifically with the PlayStation creator's Morpheus VR headset. ...

A close look at Southeast Asia, and the potential for your mobile game there

August 31, 2015 11:02 AM

"Mobile games dominate in Southeast Asia. In 2015, mobile revenues already account for nearly half the $1.4Bn Southeast Asian games market." ...

Making a game feel new again by revamping player mobility

August 31, 2015 08:02 AM

A detailed tour through the design of Shovel Knight's all-new playable character, Plague Knight, and how his completely different movement style posed both challenges and opportunities. ...

The state of the Chinese game market, heading out of ChinaJoy

August 31, 2015 08:01 AM

"Mr. Sun Shoushan, Deputy Chief of the State Administration of Radio Film Television Press & Publications (SARFTPP) reported the official government data for China's games market for the 1st six months of 2015." ...

Classic Postmortem: Deadly Premonition

August 31, 2015 08:01 AM

The open world survival horror comedy game Deadly Premonition turns five this month. We celebrate by reprinting an exhaustive Game Developer magazine postmortem of this cult classic. ...

Timothy Lottes

Atari Shock Reloaded?

by Timothy Lottes ( at August 29, 2015 02:49 PM

Maybe this post should just be called "Indie Shock". Interesting graph below posted on twitter of the number of Steam game releases over time. Saturating isn't it?

Thoughts From Personal Perspective as a Consumer
Engines like Unity and Unreal make it much easier to produce games, but the games tend to be more similar, staying within the limitations imposed by the these mass market engines. Same effect happens as independent engine tech all falls into the same local minimum, or developers limit risk by staying in the confines of well walked genre. This makes it harder for a consumer to differentiate between titles. Choice in a sea of noise is random. It is not as much the content which shapes purchase decision in that case, but rather how the consumer gets directed by marketing.

As it becomes harder to choose, and as more choices result in failure of satisfaction, the barrier to purchase increases, and even the falling price cannot compensate. The price of free is actually quite high: the opportunity cost of doing something more compelling with one's time.

"Nobody Cares" aka the Excuse For Being Mediocre
Why bother investing time to achieve greatness? Proponents of this line of thinking often present justification in the form that the average consumer cannot tell the difference between low and high quality. For a producer this is effectively a self selecting choice to continue to swim in that sea of noise. Some forms of greatness may not be perceived at the conscious level, may not be something a consumer can articulate in words, but instead may only manifest in feel and yet have profound effect.

Knowledge of excellence in some aspect which effects only a fraction of the market, say awesome multi-GPU support, establishes a hint that the producer cares about the product at a level beyond serving me a microwaved pre-constructed hamburger. It is very hard to maintain employment of the creative and driven individuals which produce top content without allowing them to strive for greatness, even sometimes at the compromise of maximum profitability.

As a consumer in a sea of noise, I select for the expression of producers looking to be the best that is possible. Who, given the limitation of architecture and time, choose paths which compromise in a way which allows a unique realization of the ultimate form of their art.

Ketogenic Diet - Working on Year 2

by Timothy Lottes ( at August 29, 2015 01:56 PM

Part way into year two on a Ketogenic diet, breaking the diet only once and a while on business trips. The diet is basically mostly fat, some protein, with almost no carbs.

Initially established in the 1920s as a way to control seizures for people with epilepsy, the Ketogenic diet is being successfully used as a metabolic treatment for cancer by a few individuals, but is largely being ignored by medical professionals. The diet works by shifting the body's metabolism from glucose (sourced from carbs or converted from excess protein) to ketones produced in the liver (sourced from fat and oil). The diet has natural anti-inflammatory properties. The theory of how a Ketogenic diet fights cancer revolves around the idea that cancer is mostly a mitochondrial metabolic disease. Specifically that cancer cells tend to have damaged mitochondria which switch to a more primitive glucose fulled fermentation as their primary energy generation process. Starving cancer cells of glucose places them in extreme metabolic stress, allowing the body to fight back. One of the primary ways to track cancer is by looking at the process of tumor angiogenesis via periodic MRIs with contrast. Effectively watching over time as the cancer causes the body to develop ever stronger network of blood vessels to feed the cancer with glucose. Successful treatments of cancer can reverse this process. I suspect ultimately that everyone has cancer even if only at some undetectable amount. The question is if the body's balance shifts between a state which enables the cancer to grow, or a state which causes the cancer to die. Cancer becomes terminal when there is no longer a way to shift back the balance.

The Ketogenic diet for me is a lifestyle choice not made out of medical necessity. My personal tastes tend to really align with the diet, and it is a great way to stay in shape, more so when you have a career sitting at a desk typing away on keyboards. Counter to how the media vilifies fat as the source of the nation's obesity problem, it is near impossible to maintain body fat on the diet which involves mostly eating fat: the body is in a constant state of fat burning, instead of fat storage.

Looking back, it was relatively hard to get started. The realization that America's entire food culture and supply chain is optimized for the delivery of carbs, leaves a demilitarized zone filled with land mines for the oil fueled consumer. Just finding things which are in the parameters required for the diet can be quite a challenge. After a while, planning every meal, weighting all ingredients, measuring ketone levels or blood glucose levels, is replaced with driving by feel alone. The transition between carb burning and ketone burning body state goes through a standard process of horrible sugar withdrawal symptoms, bouts of fatigue and brain fog, eventually returning to the feeling of being normal, but then unaffected by the standard cravings carb eaters have. The first transition takes weeks, however after being ketone burning for this long, the transition now only takes me a few days.

Over time the diet becomes as enjoyable as the standard high-carb diet, and even more so in many regards, because of the ability to easily take in 70% fat at a given meal (like bacon wrapped sour cream). Unlike sugar, there is no crash afterwards, and the body provides some rather strong signals to stop eating before you over do it, instead of telling you to keep going as is the standard practice with sugars. Here is an example of the kind of foods my wife and I eat: butter on low heat, mixed in spice, garlic, and boiled shrimp. Consumed head, shells and all, with sour cream on the side straight to bring up the fat content,

Gamasutra Feature Articles

UK cops arrest PSN, Xbox Live DDoS attackers

August 28, 2015 10:12 PM

The UK's National Crime Agency has picked up six teens who allegedly participated in attacks against PlayStation Network, Xbox Live, and other online services. ...

Get a job: Wargaming is aiming to hire an experienced UI Engineer

August 28, 2015 08:19 PM

World of Tanks maker Wargaming is looking for an experienced engineer to fill an open Senior UI Engineer position at its studio in Hunt Valley, Maryland and work on PC/console games. ...

Video: Concocting The Witcher 3's dynamic crafting-based economy

August 28, 2015 07:57 PM

CDPR's Matthew Steinke speaks at GDC Europe 2015 about how he led design of The Witcher 3: Wild Hunt's crafting system and how he made it play nice with the game's dynamic economy. ...

Game From Scratch

Is it a Vacation? Or the Beginning of an RPG Tutorial Series?

by at August 28, 2015 07:42 PM


Hello All,


Just a quick note on what’s coming up at  First up, the end of summer is fast approaching and I think it’s time for a road trip vacation.  Last year I took a similar trip and it rained every single day, so this year I’ve learned from my mistake and I am bringing along a laptop and will be doing a little work while lounging by the pool ( or more likely locked inside watching the rain ).  This isn’t exactly a hardship, as I enjoy what I do after all.


Since it is a vacation however, I am going to be taking a somewhat different approach to what I am working on.  First off, there will be no videos produced, since I wont be bringing the proper equipment with me.  Second, traditional series will be on hold until I get back, so don’t expect any updates to existing tutorial series for at least a week, although I should get an in progress “Closer Look at” post out before I depart or shortly thereafter.


Instead I am intending to do exploratory work on a pet project I’ve been kicking around in the back of my head…  There is one topic that is incredibly underserved when it comes to books and tutorials.  One that is incredibly popular, but due to it’s massive nature, most people don’t really get into it for one reason or another.  Computer Roleplaying Games.


I have considered doing an RPG tutorial ( CRPG I suppose) for ages.  It was games like Ultima, Bards Tale, Might and Magic, Wizardry, Autoduel, Wasteland, etc… that truly got me hooked on gaming.  It’s the genre of game I personally am also the most interested in developing.  There are a couple problems about doing a tutorial series about RPGs.


First off, I will have to learn a ton to actually cover the subject.  I have never created an RPG before, so this is obviously going to be one of those “learning as I go” projects.  This isn’t really a huge concern to me to be honest.  It’s not actually a hugely complicated project, just a ton of tiny intricate moving pieces that need to be organized.


Second, they are massive.  There are so many subjects to cover and to be frank, a lot of what makes a roleplaying game work is actually the tooling behind it.  World editors, scripting systems, world state, databases, this kind of stuff.  You quickly find yourself creating your own game engine, scripting language, adhoc database, etc…  and quite frankly, the value of doing this is minimal, and the value of doing it in tutorial form even less.  Not many of you are going to want to use my poorly rolled engine ( I’m a fervent believe in the Make Games not Engines ethos… although I think making tools is a brilliant use of time ).


On the other hand, if I use an existing engine, my demographic is going to be small as well.  Right now I think the most popular engine in terms of potential readers is probably Unity.  So the series that might appeal to the most users is “Creating an RPG in Unity”.  This has many problems.  First is easily explained with a handy Venn diagram.



The Dark Blue portion is the most engaged audience, this represents the portion of the community that use Unity and are interested in RPGs and read GameFromScratch.  As you can also tell, it’s the smallest portion, although this is generally the way these diagrams work.  There are the two slightly lighter blue areas, and those represent people that have 2/3rd interest in the project.


Simply put, by picking a game engine, it narrows down the potential audience substantially.  On the other hand, as I said earlier, not using an engine is a very bad choice.  Also to be completely honest, without a serious amount of modification ( which would require a source license ), Unity doesn’t actually seem like a great choice for an RPG, at least for small teams.  Of course some exceptional games have been made using Unity, such as Wastelands 2, Pillars of Eternity and Shadowrun Returns, but they all had huge teams and most likely had source licenses.


It’s this limited audience that has always kept me away from the idea; and a lack of time has kept me from simply working on my own game.  This is one of the challenges of running, I need to work on either a broad variety of topics, or on topics of interest to a large enough segment of the community.  This keeps me from spending a ton of time developing my own game.  This isn’t really a big deal, I actually enjoy teaching more than I enjoy development these days.


I hit upon an idea however that I think might be useful to the greatest number of people.  To appeal to enough readers to justify the time spent, to be effective enough you could actually use the results, to be productive enough that you could actually finish a game and be interesting enough that I would actually enjoy working on it.  That’s a lot of enoughs eh?


To start out making an RPG engine of sorts, you would need a number of moving parts to start from.

  • a game engine/collection of libraries to handle the technical bits.  Rendering, input, that kind of stuff
  • a scene graph, world storage format.  Basically the data structure in memory and on disk that your game will reside in.  This could be part of the engine you chose, but for an RPG, you will probably want more control or possibly to decouple it from the engine for a variety of reasons.
  • a world editor.  This one is big.  HUGE in fact.  My thought at first was to create if from scratch, but that could literally take a single developer years.  More on this point later, as again, it’s a big one.
  • RPG logic.  There’s all kinds of things that are somewhat unique to RPG games, from massive state driven game levels, time management, to simple random generators, dialog trees, class abilities, game entities, etc.  Basically the common logic that goes into an RPG that makes an RPG and RPG, regardless to if its 2D/2.5D or 3D, sci/fi or high fantasy.
  • misc tools…  conversation / internationalization tools, sprite effect tools, world item asset creation/database, etc.  Some of these could be part of the engine, some could be part of the editor, some could be stand alone and all may depend on the RPG logic layer.  File this section under miscellaneous/everything I forgot.

There are many different choices, but all of have their strengths and weaknesses.


An immediate thought would be LibGDX.  From the game engine side of things, it certainly ticks almost all of the boxes.  There are three big downsides to this choice however.  First, I run into the Unity factor again… if I go with LibGDX, I lose all readers interest that don’t want to use LibGDX or Java.   Second, there is a lack of out of the box scripting support.  I wish there was Lua ( or jLua, or whatever the Java equivalent is ) support out of the box.  I think it would be easy enough to add in support for a scripting language for the LJGWL target, but once you start getting into Android and then the RoboVM trickery then we are talking a layer of black magic I currently do not possess.  It may not actually prove to be that difficult, but this is a portion of LibGDX that I’ve always just let others wrap their brains around.  Finally, and one of the big ones…  no level tool, at least not yet.  There is Overlap2D, but it’s just not there for me yet.  Plus frankly, trying to extend it with the ECS and MVC design its chosen… this would be nightmarish.


Those end up being the big two sticking points for me, the availability of a scripting language, but one that has to be optional… and a solid base to build a level editor upon.


In terms of level editor, one of the most immediately obvious answers is TileD.  I like Tiled… I actually looked at the source a number of times considering doing exactly this very thing… and I decided it would be WAYYYYYY too much work.  Tiled’s code is nice and clean Qt C++, that’s not really the issue… the issue is the pure amount of work you would have to do to extend it.  I believe they are refactoring towards extensibility, but this is a WIP.


Of course Unreal and Unity can be turned into level editors, but this will start feeling like a hack right away, and without Unity source you are quickly going to be stuck in the Unity design model, which for an RPG, would lead to an organizational mess almost right away.  With Unreal you get the source, but realistically you aren’t going to want to extend the editor, at least not with a fairly large developer team.  Plus that API is changing A LOT, so expect huge breaks every time there is a new release.  Pretty much ever major game shipped on one of these engines pretty much locks to a version and sticks with it…


You could also extend a content creation platform too… this is actually a pretty popular choice.  You could extend an app like Blender, Maya or Max to use as your authoring environment, but this again is a highly specialized development and of interest to a very small segment of the community.  Also it can very easily get hackish fast.


Of course, I wouldn’t have shared this massive wall of text unless I thought I had an idea now would I?  Well, it’s that idea I am going to flesh out during my vacation, decide if it’s viable, both from a tech perspective and a time perspective.


So… what are my thoughts?


Godot.  Or perhaps, sorta Godot.


Godot ships with a Unity-like 2d/3d editor, and a game engine capable of providing the technical bits in a cross platform manner.


More importantly, Godot editor is mature, 2D/3D friendly, scriptable and most importantly, modular and extensible.  In fact, the entire GDScript language is implemented as an extension module for Godot.  Therefore it should be possible to create RPG tooling ( creature editors, pathing, item inventory, conversation tools ) that can plug into Godot, but not require users to build the editor from scratch.  Basically it would enable me to create an RPG world editor using Godot, that enabled people that arent even interested in using Godot game engine, without having to fork Godot itself.  Of course you could use Godot the editor and Godot the engine to create your game.  However you could potentially use Godot the editor and say… LibGDX, or Phaser or SFML, Ogre, jMonkeyEngine, Paradox, Mono, whatever…. to implement your engine.


Obviously that just covers the editor/engine portion of the scenario… this leaves two very big missing pieces.


RPGLib.  Right now I am thinking it would be smart to provide generic RPG-esque functionality as a C++ library.  This would be usable then by the vast majority of programmers, regardless to the language they want to work in.  ideally I will use 3rd party libraries as much as possible to offload as much work as I can.  Think of this layer like the run-time that provides generic RPG-esque services to the underlying game ( the Godot editor would be a consumer of services provided by this layer ).  This layer wouldn’t care what engine you are running in, if your game is 2D, 2.5D or 3D.  It would be use to provide things like persistence, algorithms like pathfinding, a database of sorts, etc.  In theory you should be able to slot it in to a variety of games and build upon it. 


WorldFormat.  This one is tricky and is going to require a fair bit of brain juice…  basically I want to decouple the world format from the game engine.  In fact I want to decouple the world format from the game, but I dont think this is even close to possible.  Basically a world is a database, graph or tree of entities in memory.  The other side of this coin is, it also needs to be saveable to and loadable from disk.  Think about how the Tiled editor has the TMX format and all of the various game engines capable of loading it?  This would be like that, but with a great deal more database like behavior.  This would enable you to write a loader/importer for your favourite game engine of choice, and make use of Godot as your world editor of choice, but load it in whatever game engine you desired.  Of course this loader would be responsible for populating your game engines scene graph…


Think roughly this…



Now one major downside is my C++ is meh at best and extremely rusty.  Then again, only way to brush off the rust is practice, no?


The end goal is to keep each layer dependent only on the layer below it, and have zero dependencies back to the Godot editor layer.  This means a user could take and make use of just the services layer.  Or the Game Format + Services layer.  Or simply the output from the level editor and ignore the rest.  Or they could use the provided loader, the Godot editor, the RPG services, etc… and have a turnkey solution to build an RPG upon.



…anyways, that’s the thought bouncing around my head right now.  On my vacation I plan to tackle two key points.  First, I want to see if the Godot editor is in fact as easy to extend as I think it is.  Second I am going to start defining as best as I can what functionality goes into what layer.  One final thing to keep in mind out of all of this… I am not intending to reinvent the wheel.  An RPG for example requires animated sprites or models, playing sound effects and music, etc…  these are NOT the responsibility of any of this, that’s left for the game engine or game implementer to handle.  The closest this comes who thing comes to any of those services is perhaps providing resources via the Game Engine Specific loader.


Of course, I’d be interesting in know if you guess out there would be interested in a series like this?  It would take a very long time, as I will be continuing to generate the kind of content you would expect from GameFromScratch.  It would however be a fairly good sink of my time, so I want to gauge the level of interest before a dump a ton of time into this.  Also, do you see any glaring flaws in my early concept so far… and recommendations or changes you would make?


Or frankly, does this all look like the ramblings of a mad man desperately in need of a vacation? Smile

Gamasutra Feature Articles

Disney: Roughly half of Disney Infinity players are girls

August 28, 2015 07:37 PM

A Disney exec notes the company was surprised to find that Disney Infinity's playerbase is roughly 50/50 girls and boys. In response, Disney is developing the games to appeal more strongly to girls. ...

Don't Miss: The story of Blizzard's first-ever Warcraft multiplayer match

August 28, 2015 06:58 PM

"Something changed when I played the first multiplayer game of Warcraft." - Patrick Wyatt, programmer of Warcraft: Orcs vs. Humans, writes in the opening to this excellent 2012 feature. ...

How our game about the migrant crisis, Passengers, took shape

August 28, 2015 06:53 PM

"We wanted simple, factual stories. Some are sad, some are hopeful. We didn't want to bring any judgment or moral justification in the game. We just let you decide what you will do." ...

Report: U.S. average daily mobile game time drops over 30% in a year

August 28, 2015 06:34 PM

A Flurry report suggests that while the average daily time Americans spend on mobile devices continues to increase, average time spent playing mobile games has dropped significantly in the past year. ...

How Heat Signature has shifted focus away from...heat signatures

August 28, 2015 05:55 PM

We talk to Tom Francis about what happened when the central mechanic of his game Heat Signature--the mechanic that he named the game after--ceased to be the central mechanic ...

Video blog: UX without UI - Creating user experiences in action games

August 28, 2015 04:55 PM

"It's kind of a 30 minute crash course in some obscure aspects of systems design, namely: the importance of making controls ergonomic, responsive, and intuitive." ...

Funding for smaller developers: Tips from the Game Career Guide

August 28, 2015 04:25 PM

In this article from the 2015 annual Game Career Guide, Brandon Sheffield of Necrosoft Games offers tips on incremental funding strategies for smaller developers. ...

The top 6 ways mobile developers use cohort analysis

August 28, 2015 03:50 PM

"The idea of cohort analysis can seem a bit intimidating. It shouldn't. The whole point of cohort analysis is to make it quick and easy to understand what's really going on within an app and to draw conclusions." ...

Activision Blizzard set to join the S& P 500

August 28, 2015 02:43 PM

Call of Duty and World of Warcraft publisher Activision Blizzard will join the S& P 500 today, replacing Pall Corp on the stock market index. ...

PEGI gave my cartoon game an 18, but violent movies get low ratings

August 28, 2015 02:39 PM

"I've recently gone through the submission process and found that Apple's App Store and Google Play's rating questionnaires can arrive at quite different conclusions as to a game's age suitability." ...

DeNA enters the streaming game with mobile app, Mirrativ

August 28, 2015 01:55 PM

Japanese mobile outfit DeNA has lifted the lid on Mirrativ, a new iOS and Android livestreaming app that allows users to stream and share anything happening on their smartphone screen. ...

Want to conquer China's mobile market? Look to the Monkey King

August 28, 2015 01:48 PM

"The Chinese are very open to western culture (including western-type dialogues, characters, settings, etc.), so it is worth a try to combine Chinese elements and overseas gameplay." ...

Procedural World

Voxel Occlusion

by Miguel Cepero ( at August 28, 2015 01:36 PM

Real time rendering systems (like the ones in game engines) have two big problems to solve: First to determine what is visible from the camera's point of view, then to render what is visible.

While rendering is now a soft problem, finding out what is potentially visible remains difficult. There is a long history of hackery in this topic: BSP trees, PVS, portals etc. (The acronyms in this case make it sound simpler.) These approaches perform well for some cases to then fail miserably in other cases. What works for indoors breaks in large open spaces. To make it worse, these visibility structures take long to build. For an application where the content constantly changes, they are a very poor choice or not practical at all.

Occlusion testing on the other hand is a dynamic approach to visibility. The idea is simple: using a simplified model of the scene we can predict when some portions of the scene become eclipsed by another parts of the scene.

The challenge is how to do it very quickly. If the test is not fast enough, it could still be faster to render everything than to test and then render the visible parts. It is necessary to find out simplified models of the scene geometry. Naturally these simple, approximated models must cover as much of the original content as possible.

Voxels and clipmap scenes make it very easy to perform occlusion tests. I wrote about this before: Covering the Sun with a finger.

We just finished a new improved version of this system, and we were ecstatic to see how good the occluder coverage turned out to be. In this post I will show how it can be done.

Before anything else, here is a video of the new occluder system in action:

A Voxel Farm scene is broken down into chunks. For each chunk the system computes several quads (a four vertex polygon) that are fully inscribed in the solid section of a chunk. They also are as large as possible. A very simple example is shown here, where a horizontal platform produces a series of horizontal quads:

These quads do not need to be axis aligned. As long as they remain inside the solid parts of the cell, they could go in any direction. The following image shows occluder quads going at different angles:

Here is how it works:

Each chunk is generated or loaded as a voxel buffer. You can imagine this as a 3D matrix, where each element is a voxel.

The voxel buffer is scanned along each main axis. The following images depict the process of scanning along one direction. Below there is a representation of the 3D buffer as a slice. If this was a top down view, you can imagine this is a vertical wall going at an angle:

For each direction, two 2D voxel buffers are computed. One stores where the ray enters the solid and the second where the ray exits the solid.

For each 2D buffer, the maximum solid rectangle is computed. A candidate rectangle can grow if the neighboring point in the buffer is also solid and its depth value does not differ more than a given threshold.

Each buffer can produce one quad, showing in blue and green in the following image:
Here is another example where a jump in depth (5 to 9) makes the green occluder much smaller:

In fact, if we run again the function that finds the maximum rectangle on the second 2D buffer it will return another quad, this time covering the missing piece :
Once we have the occluders for all chunks in a scene, we can test very quickly whether a given chunk in the scene is hidden behind other chunks. Our engine does this using a software rasterizer, which renders the occluder quads to a depth buffer. This buffer can be used to test all chunks in the scene. If a chunk's area on screen is covered in the depth  buffer by a closer depth, it means the chunk is not visible.

This depth buffer can be very low resolution. We currently use a 64x64 buffer to make sure the software rasterization is fast. Here you can see how the buffer looks like:

It is also possible not to use our rasterizer test at all and feed the quads to a system like Umbra. What really matters is not how the test is performed, but how good and simple the occluder quads are.

While this can still be improved, I'm very happy with this system. It is probably the best optimization we have ever done.

Geeks3D Forums

Intel HD Graphics Driver v4278

August 28, 2015 09:01 AM

Download from Fujitsu
+ no vendor ID restriction
- no change log
- no OpenGL fixes since v4256


Geeks3D Forums

Microsoft Windows 10 Insider Preview Build 10532 for PC

August 27, 2015 09:03 PM

Windows 10 Insider Preview Build 10532 for PC

We are releasing a new Windows 10 Insider Preview building to the Fast ring today: Build 1053...