That's my view.

Theoretically, the deal could result in Oculus getting the funding it needs and Facebook just uses the development team to help them integrate Oculus into whatever VR platform they want to create.

But there's far too much room for Facebook to start integrating itself into Oculus.

http://www.forbes.com/sites/briansolomon/2014/03/25/facebook-buys-oculus-virtual-reality-gaming-startup-for-2-billion/

So Oculus VR just sold itself to Facebook.  What do you think of this development?

Personally, I can't see anything good coming out of this.  I see only lockdown, integration, and data mining.

Game [engine] programming is all about balancing flexibility with performance.

While polymorphism, dynamic linking, and reflection give the programmers a lot of flexibility with regard to configuring and extending the game engine, they all incur performance costs, either with direct overhead or memory incoherency.

If a game engine becomes completely modular, you end up with something like LOVE or Panda3D: a scripting layer for a native backend.  While they are quite flexible and easy to use, they cannot match the performance of an engine specifically written for a single use case.  Engines like Unity lie somewhere in between: while they are still quite powerful, they are not completely flexible.

Although I want to be able to sell my game, I also want it to be open-source.  The model I was envisioning was the ability to look at and fork the code, but not to be able to redistribute the original assets or use derivative works for commercial purposes.

Anybody know what the best license to use would be?  I'd prefer to avoid a viral license such as the GPL.

How much is your budget?  You could probably get 2 or 3 browser-game-capable Thinkpads for about $300.

It totally depends on what kinds of features you'd like your terrain to have.  However, most terrain systems will benefit from some added texturing features, such as multitexturing and triplanar texture mapping.  So theoretically, the same surface vertex shader could be used for both objects and terrain, but a different pixel shader is probably desired.

Multitexturing just involves blending multiple textures together, usually using weights sampled from single-channel splat textures.  The weights could also be derived from the terrain height so you can vary vegetation and snow by altitude.  For example:

Code:

// grass texture (base)
vec4 grassColor = texture(grassTexture, position.xy);

// road texture (splatted)
float roadAmount = texture(roadSplat, position.xy);
vec4 roadColor = texture(roadTexture, position.xy);

// snow texture (height-based)
float snowAmount = (position.z - 800.0f) / 200.0f;
vec4 snowColor = texture(snowTexture, position.xy);

// mix
outputColor = mix(mix(grassColor, roadColor, roadAmount), snowColor, snowAmount);

Triplanar texture mapping is usually used to make terrain appear more rocky as its gradient approaches vertical.  The effect is much more pronounced when using volumetric terrain, but it works fine for heightmap terrain as well.  In reality, you'd probably want to bias the blend weights towards the planes, but this example should illustrate the concept:

Code:

// textures
vec4 xColor = texture(rockTexture, position.yz);
vec4 yColor = texture(rockTexture, position.xz);
vec4 zColor = texture(grassTexture, position.xy);

// mix
outputColor += xColor * normal.x * normal.x;
outputColor += yColor * normal.y * normal.y;
outputColor += zColor * normal.z * normal.z;

When packaging libraries when distributing your game, you would usually just put all the shared objects (DLLs) that you need in the executable folder.  The statically linked parts of the libraries are just included along with the executable.  Theoretically, if the library API stays constant but the implementation gets an update, all you need to do is patch the DLL and everything will still work.

As for the Steam Runtime, it just looks like an SDK that includes SDL and GCC, as well as some tools and scripts for patching, cross compiling, and file organization (I'd assume the Steam application runs some of these internally).

If you want to get started with something easy I'd try Lua and LOVE.

http://www.lua.org/
https://love2d.org/

I use C, so I'm more limited in my choice of simple architectures.  However, I believe that the way C intends you to do "singletons" is much better than the way OOP languages want you to.

Since I don't have generics, I tend to just implement each resource manager separately.  Essentially, the public interface is exposed by free functions inside a header.  The actual code and memory that the manager uses are all declared and implemented within the source file.  So although the memory is theoretically global, it's not declared except where it's needed, and other source files can only see the functions.

Seems like it could work for the background of a magic system.

Generally speaking, the narrative is the least important element of designing a game. Either start with mechanics, or a general feeling you're trying to invoke, then as the game takes shape you can devise a narrative that ties it together. If you start with the narrative you may find yourself quickly getting boxed in trying to make mechanics or encounters that fit within the narrative but don't make sense on their own; that's one reason I think that games based on movies tend to be bad.

Still, there's nothing here that seems out of place. I could see this being the background for a magic-heavy game and there's some potential for mechanics to be born out of indirectly controlling magic.

The key point is that there is no narrative.  At least, I'm not the one creating it: the narrative evolves from the world generator and the actions of the players and NPCs.  Mechanics such as the magic system are the only things that are constant throughout the "universe" of the game, and thus are the elements that need to be fleshed out.

Normally I don't really like OOP all that much, so I'd vouch for SDL if you were programming in an imperative language like C(++).  However, since you're already forced into using OOP with C#, you might as well go with SFML, especially if you want a higher-level framework that has a lot of features implemented already.

[Concerning Magic]

Just wanted to pitch my ideas for a magic system in my game to you guys and get some feedback.  It doesn't really concern the mechanics, but rather the lore explanation which is used as a base.  The game in question is a procedurally-generated sandbox RPG with emergent gameplay like tabletop Dungeons & Dragons and other traditional RPG games.

Concerning Magic

Magic is not a thing in itself.  It's an abstract concept that encompasses all phenomena that occur as a result of the actions of spirits.  Although humans have ways of controlling or communicating with spirits and indirectly causing magic, humans, or any other physical beings for that matter, cannot intrinsically perform magical acts.

Concerning Spirits

Different types of magic are linked to different types of spirits.  As always, there are a number of atomic elements, including fire, water, air, earth, light, and dark.  There is a hierarchy of spirits, with elementals at the bottom and deities at the top.  Weaker spirits are closer to nature, while stronger spirits are closer to people.  Stronger spirits tend to not cause magic directly, but instead control weaker spirits.

Concerning Magicians

A magician is someone who has the ability to deliberately induce magic by controlling or communicating with spirits.  While anybody can technically cause magic, magicians hone their abilities and focus on working with spirits.  There are two main ways that magicians can cause magic, which differ in their attitude towards spirits.

Concerning Faith

Faith-based magic is based on communication with spirits, and their voluntary responses to the magician.  Faith usually deals with strong spirits, and involves more complex magic.  Generally, faith-based magicians are members of a church or cult dedicated to a deity, such as priests, clerics, and bards.  However, magicians like druids or shamans are more closely connected with elemental spirits.  Faith is not guaranteed to produce the intended result, due to the spirits' volitions, but is generally much stronger than the alternative.  Faith may require the use of a sacrifice, which can be anything from a feather to a pure maiden's blood.

Concerning Sorcery

Sorcery-based magic is based on the control of spirits.  Usually, weak spirits are bound to enchanted objects like wands or talismans, but exceptionally powerful sorcerers can control stronger spirits as well.  Sorcery is more accessible to non-magicians, because anybody can pick up a wand and cast a spell without knowing how to communicate with spirits.  However, the bindings between spirits and catalysts are temporary and usually result in weaker, however reliable, magic.

Concerning Enchantment

An enchantment is simply a connection between a person or object and a number of spirits.  Usually, a weapon or piece of armor is enchanted to give it some magical quality or ability.  In fact, catalysts used for sorcery are just enchanted objects, but the objects have qualities that lend themselves well to stronger and more forcible bonds.  If a spirit has a voluntary attachment to a person or object, this enchantment is considered to be a blessing or curse.  Like faith, blessings or curses are more powerful.  However, they are permanent and difficult to change, and can be dangerous.

I'm sure you've received complaints about this before, but I just bought the game on Steam after a while of not playing and the mouse look is, well, really bad.  I ramped up the sensitivity and it's still laggy and imprecise.

I'm running Linux, if it makes a difference.  Before, when I played on Windows, the mouse look worked just fine.

Running Manjaro and OpenBox.  I would use Arch but I could never get the video drivers working (Toshiba Satellite w/ AMD mGPU).  Manjaro's pretty good because you get to use the AUR but it all comes in working order with a nice installer.

The absolute best thing to do would be to create a level editor and a binary format.  Defining everything using a markup or programming language is going to hurt storage usage and load times.  It's also much easier for both you and modders if you're using an editor and not just typing it into a file.

That's not to say that Lua can't be embedded into your binary format, and it can be written in your editor to handle things like triggers or other level-specific behaviour.  You could even go one step further and use the editor to create your entities!

I would advise on trying out a bare setup at first.
(write your code in a text editor, compile/link etc by using the terminal)
get a feel for the build process, compile your stuff on the terminal, with maybe some make file or something.

then you can become a IDE user who is less afraid of the weird stuff that IDE yells at you.

Totally agree with this.  If you're just starting out, I recommend Notepad++ (free) or Sublime Text (paid), or if you're a Linux user, Geany or Vim (for ricers/experts!).  They can all run a makefile and execute the output from within the program, although you'll need to write the makefile yourself.

http://www.cprogramming.com/tutorial/makefiles.html
http://www.cprogramming.com/tutorial/makefiles_continued.html

These are some pretty good resources for learning how to write your own makefiles.  Basically, a makefile just runs system commands to compile your code, but provides facilities for macro expansion and dependency resolution (so you don't need to manually compile everything every time).

They can also be used in more advanced cases to automatically pack resources, download and compile libraries from Git, etc.

Do you know if SDL allows you direct access to the textures for uploading new data once the texture has been made? I need that for my paint program to update the canvas..

Yep, you can use SDL_LockTexture() and SDL_UnlockTexture() to upload new data.

If you want to use C, SDL 2 is the go-to library to use.

If you want to use C++, I suggest trying SFML out, as it is an OOP library and a little easier to use, while SDL is procedural.

[char *stuff]

I was compiling as C++, so I switched back to C. It was giving EXACTLY the same gibberish but I switched to Release and now it isn't saying anything...
Why don't you just post a screenshot or something, I really can't be bothered to be get this working 

As far as what it's supposed to do, it just outputs "Hello, World!".  Although char *stuff, explicitly pointing to the string literal, goes out of scope, it is either a register or on the stack.  Therefore, when thing is declared, if it uses the same register or location on the stack (likely), it still points to the string literal because C doesn't initialize variables.

If you're using the VC compiler, I'm not surprised that it doesn't work because VC is never very standards-compliant to begin with.  Of course, this behaviour is not defined in the standard!

Doesn't work with VS2012 (use of uninitialized variable stops the program)
Tried with Code::Blocks, it just output random gibberish...

It works fine with GCC 4.8.1.  Are you compiling it as C with no optimizations?  I'm sure that if you enable optimizations, stuff() will get totally optimized out and printf() will read garbage.