5

How do game makers/engines like Buildbox, GameSalad, Construct, GameMaker, etc work in principle? I am not interested in getting a list of technologies (programming languages, APIs, etc), but how - from a software engineering perspective - do these programs convert the user's interactions into exportable code?

What I'm looking for is only a rough outline how the software creates code/source files from the user interactions with the software. While details would be awesome, a high level overview would be sufficient.

I'm a second year CS major and have some experience with Java/C/C++ as well as some web languages and framework. It's hard to find information on how a game creation software works because there's more content on how to make games in general.

In case you don't know, Buildbox, GameSalad, Construct, GameMaker are popular drag and drop game builders. While Buildbox is exclusively drag and drop, the others have optional scripting languages as a feature.

Improve this question
6
  • Do any of them have source you can look at? – Robert Harvey Dec 5 '16 at 6:30
  • Game engines yes, game creators, not really. Most are commercial. I found this one today. it's called gdevelop, github.com/4ian/GD. Haven't looked into it much yet. – Sean Nam Dec 5 '16 at 6:40
  • Are you asking how it's posible to make games that can take user input to build the game? – candied_orange Dec 5 '16 at 6:41
  • I'm asking how game-creation software, like Buildbox and GameSalad, work. You design the game without any coding and then it'll export that into code, like an Xcode project for iOS. – Sean Nam Dec 5 '16 at 6:43
  • 2
    I took the freedom trying to make your question suitable for this site, to avoid immediate closing. – Doc Brown Dec 5 '16 at 8:26
7

The earliest of this kind of system I encountered was an engine called "HURG". They've become at lot more advanced since then, but basically they all work the same way: they have an embedded pre-programmed engine (or a few different engines for different genres of games) that have a very large number of options for customizing them, a simple way of programming behaviour for game objects graphically (and in most cases also ways of linking those objects to externally-written programs in some kind of scripting language), and a graphic asset pipeline for importing your artwork. They then have a method that packages up everything except the editor into an installable module with an executable that simply loads the engine with your options and assets and starts it.

In other words, they're really not very much different from a highly customizable game that supports full conversion mods (e.g. the Half Life series, which supports mods that are almost as well known as the game itself, e.g. Counterstrike), except that they're supplied with the development tools you'll need rather than having to obtain those separately.

Improve this answer
1
  • Thanks for the answer! This was the type of information I was looking for. And for sharing "HURG"! So all the user is really doing is changing values that affect the gameplay? Makes sense. I'm not a big FPS gamer but thanks for the tip on Half Life/CS, I will check it out some time. – Sean Nam Dec 5 '16 at 7:50
4

They work because data and code are the same thing

When you provide input to the computer as you play the game your input becomes data. When you use a game builder you're providing input that becomes data. When you write code the build a game you're providing input that becomes data.

It's all data. The secret is how you use that data.

What you're seeing is really one game. It can be renamed, skinned, level modded, and re-scripted but it's the same game. The part that doesn't change people call the "game engine". The game engine sets the limit on performance and effects. It doesn't limit content.

When people get excited about a new game having amazing effects that the last generation of games could never have done, what they're getting exited about is the game engine.

When people get excited about a new game having an amazing story, art, and chanenging puzzles they've never seen before, what they're getting exited about is content.

Infact what I'm writing right now is going to become content presented in the softwareengineering skin wrapped around the stackexchange webpage engine.

So yeah, those who make games with buildbox are game developers the same way people who post here are web developers.

Improve this answer
1
  • 1
    "Infact what I'm writing right now is going to become content presented in the softwareengineering skin wrapped around the stackexchange webpage engine" -> internet points -> stackexchange is a game engine... – Caleth Dec 5 '16 at 9:08
4

To avoid this getting too broad, what I'm looking for is only a rough outline how the software creates code/source files from the user interactions with the software. While details would be awesome, a high level overview would be sufficient.

Basically you can input data and output code.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.