Jump to content

  • Log In with Google      Sign In   
  • Create Account

Servant of the Lord

Member Since 24 Sep 2005
Offline Last Active Yesterday, 09:09 AM

#5290168 Time - the most important factor.

Posted by Servant of the Lord on 04 May 2016 - 06:06 PM

In my head, i'm trying to figure something. I've seen that Stardew Valley has been sold for more than 1 million copies on steam. It was a game, which was developed by a single guy. That guy, according to Wikipedia, had a major in computer science. That already means he had a strong knowledge about software development in general, unlike us code monkeys who stay on gamedev and stackoverflow, and ask a million questions, just to get a million questions more.  Stardew valley is a 2D game, which was developed in 4 years. I've seen the game, and i'm trying to figure, what has took him THAT long? I mean, seriously, the game has a few base game mechanics. The game is 2D pixel art. The code might be thousands of files. What takes 4 years just to develop a 2D game? Answer the most noobish question please. 


The artwork takes time to make.... and most of what gets made is thrown away and remade better, during development. What art you see in a game, likely four times more was made and remade before it makes it in the game.


The coding takes time to make... especially when you are learning new tools and game design. Him having a computer science degree may mean he already knows how to program some times of computer applications in one language, but it doesn't mean he knows how to make games in whatever language he eventually decided to use. He likely had to learn entirely different thought processes.


Making a game takes time, in-general... especially when you're also working a job, and can only work on your game after you come home from work (though in this developer's case, it sounds like it was a part-time job).


I've been working on my RPG for nearly six years now - learning as I go. And I've certainly wasted alot of time, partly from inexperience, and partly because that's just how game development goes.

#5289936 I'm really new in this

Posted by Servant of the Lord on 03 May 2016 - 01:53 PM

can you guys tell me about a good program for sound effects

FreeSound.org <-- Free sound effects (look at the licenses to make sure you can use them commercially, if you plan on selling your game, and make sure you attribute the creators of each sound).
Audiacity for basic editing.

also any advices that you have.

Start small, add features one by one, complete projects you start, don't start projects you can't complete.

And a question, if I want to make a multiplayer game like 2D pvp, 2v2, how do I host the game so both players can connect? Do I need mysql knowledge?

No, SQL is a language for talking to databases (and MySQL is a database system). You don't need a database at all, especially not for such a small game.
And databases aren't directly related with hosting servers or making computers talk to each other - it just happens that databases are commonly used with those things also, but aren't required by them.

To host a server, you need:
A) A program that you write (called a 'server') that handles the logic of your game and coordinates between the 'client' programs that run on your players' computers.
B) A computer (also called a 'server') that'll run your server-program.

You can run that computer yourself, which is good for development, but you probably don't want your computer publicly exposed to the internet, so usually people hire a company to 'host' the server-software (the program you write) for you on their server-hardware (their computers).

You can either rent the hardware in such a way where they handle almost everything for you except writing your actual program (many such companies exist), or you can rent the hardware in such a way where you can micromanage it yourself (Rackspace, Amazon.com, Google, and Microsoft, are the big names in this area).

#5289931 Creating the game world.

Posted by Servant of the Lord on 03 May 2016 - 01:38 PM

idk dude can anyone pls recomend something i could start on to get into either game design or development?


Start here: "I want to make games, where do I start?"

And here: Sloperama's Game Biz Advice page


It takes years of hard work, so now's absolutely a good time to get started.

#5289923 Is Making The Player Read Lots of Text Unusual?

Posted by Servant of the Lord on 03 May 2016 - 01:17 PM

The Etrian Odyssey had quite a bit of reading, but not books worth, and it was always broken up into smaller chunks inbetween gameplay.


As far as I know, people like reading novels, so whatever you do, it cant be bad.

People like reading good novels. Uh, well, alot of people like reading Twilight and Eragon, and those aren't 'good', so I guess that disproves that. Harry Potter was very enjoyable, but it wasn't particularly well written (the world and plot were interesting, but the writing quality itself was merely average, and the characters were above average, but not fantastic. Still was enjoyable though, and apparently about a third of a billion other people also thought so).

@Syrena: If you are going to have alot of writing in your game, I suggest you get it peer-reviewed by a two or three people, and get some heavy constructive criticism to refine it and refine it some more (then have the same three people review it again, to give more advice and critique the changes).

#5289913 Creating the game world.

Posted by Servant of the Lord on 03 May 2016 - 12:27 PM

Personally i think small goals are stupid.


Yes, and no.


If someone means, "aim low because we won't achieve anything better", then yes, that's (likely) self-defeatism that prevents them from reaching higher and stretching themselves.


But if someone means, "aim high long-term, but figure out intermediary stepping stones to reach to our long-term goals", that's smart planning. That's what people mean when they say, "start small and work your way up", because starting small teaches you the important information you'll need when you go big. But trying to start big is like trying to fly a 737 commercial airliner before learning to fly a smaller two-seater plane: your crash is guaranteed, and when you crash, not only is there alot more destruction that costs alot more money, you also bring down all the people you convinced to ride in the plane with you. It's worse for you, and for them.

#5289819 Procedural Universe: The illusion of infinity

Posted by Servant of the Lord on 02 May 2016 - 08:31 PM


odds are an octree is overkill for both collisions and culling.

Strongly disagree, on what experience do you base that assumption?
I always have had big speed ups using octrees for both culling and collisions in practical cases.




odds are an octree is overkill for both collisions and culling.

Based on my personal experience octrees are not just efficient but also practical. Their structure makes space division natural and intuitive, but these are just bonuses, performance is greatly increased when properly used.

I don't have any personal experience in this area, but I found this article interesting, about DICE rethinking how they do culling when making Battlefield 3.

#5289803 Creating the game world.

Posted by Servant of the Lord on 02 May 2016 - 06:17 PM

Okay thanx for telling me how. But for real. Im only 14 so I have time,

The sooner you start and the harder you work, the better you'll be compared to people who start at 15 and only work 90% as hard as you do.

i dont see why we shouldn't shoot for perfect.

We absolute should shoot for perfection. But with our current hardware, absolute simulation of the universe is impossible.

So for individual developers working on projects today, our goals are 'what does perfection mean within our existing limitations'.

Also, as I pointed out above, "perfection" and "realism" is different. We should aim for perfection, but we have to pick and choose what parts of reality we want. If we make it 100% realistic, that means we can't fly or shoot fireballs, for example.
If we make it 100% realistic, that'd mean we can in theory break down a concrete wall, but it'd also mean in-practice, we'd have to spend five hours with a pickax doing very boring things instead of jump-kicking skeletons in the face.

i think once we can replicate every speck of dust i most certainly think we will be able to hack into the brain at that point.

But those two are unrelated. By the time we successfully colonize Pluto, surely we'd have learned how to make perfect curry.

But if what I want is perfect curry, I should become a cook, not an astronaut.


Why focus on replicating specs of dust if what you really want is to inhabit a virtual world with 'presence' and 'agency'?

#5289791 Creating the game world.

Posted by Servant of the Lord on 02 May 2016 - 04:50 PM

My whole point was to talk about a concept in which every little detail in the world is individual. Each grain of sand each stalk of grain, each brick and each spec of oxygen.

That'd take far too much processing power and far too much data storage.

Why waste resources on oxygen?

Making things more realistic doesn't always make things better. Take, for example, western comic book art or the Japanese' anime and manga - Good artists have long since realized that by carefully simplifying (unrealistically) or exaggerating (unrealistically) certain things in their works, they can communicate information in more exciting, enjoyable, and compact ways.

We can make "perfect" art by taking a photograph using a camera. But that photograph is a different category of thing from say, a great watercolor painting.


It would probably make more sense if I stopped saying game and instead said virtual reality. A nature engine is how I was thinking but I honestly still don't understand game engines.

Saying 'game' is fine. Don't use the word 'engines', because that word is already misused enough.

I was also thinking the laws of physics, how cells form, etc all of this can be written down into the engine and followed out.

We can write it down, but it'd be too much work for your computer or gaming console to run.

The more you have to write down, the more work it takes, multiplied by the number of objects you want to apply those rules to.

If you have to write down twenty lines of code, it's more work than just five lines of code (I'm greatly over-simplify programming).

If you then want to apply those rules to the 6,000,000,000,000,000,000,000,000,000 atoms on the earth, even if you can only do one billion a second, then that means it'd still take you two billion centuries before your world is generated.

Do you need to have the inside of the earth generated, or just the surface? Game development (and all art) requires skillful choices about what not to waste resources on.


There are laws of diminishing returns. Why waste a bajillion times more effort, for only twice as good a result, if you can instead apply half that effort to something else (like gameplay) and improve it ten-fold?

Then the editor is a step by step process of creating things using the laws of our world plus the magic of computers.

That's what some procedural generation does. Depending on the amount of detail needed, some developers have done things like plot the course of rivers based on the rainfall on the mountain, and wear down the mountain with thousands of years of rain and wind.
As I'm sure you know, computers aren't really magic - we don't get to do an infinite amount of work for free.

So, we pick and choose what work is most important. Each grain of sand or puff of oxygen won't be noticeable, but slightly more intelligent dragons or slightly more breakable walls might be.

Instead, if necessary, depending on the amount of detail needed and the amount of resources available to each game, we on-the-fly generate extra detail on the ground when players "lean in closer" to the ground, and remove unneeded detail

All art has limitations, whether a book, a movie, a painting, or a game - the key is to make enjoyable works within those limitations. Because of limitations in game technology, we basically have a "budget" of what computer power is available on a device, and try to spend that budget as best as we think possible given

As those "budgets" of technology has improved, we've made better and better sound, graphics, physics, AI, and so on, but we still have alot more work needed not just in improving the (for example) graphics in a general sense, but making intelligent choices about should we improve the graphics in this game, or should we allow players to climb walls instead? Should we allow players to break through walls, or should we allow players to fly instead?


We can't have everything, and can't do everything, within one game. But as computers get more and more powerful, and as common solutions to common problems (like water flowing, trees growing, and fire spreading) become better refined and take smaller percentages of our enlarged budgets, we can cram more of these features into every game and make them commonplace. Once they are common place, players will take them for granted within two years or less, and demand more things we haven't yet done, without removing the old.

You could either learn to program and help us speed up the next wave of innovations, or sit tight and wait another ten years until what you are picturing today is commonplace. At that point in time, you'll be bored of it and want something else anyway.  :lol:


Gaming still has a long way to go. But saying, "Why don't we make it perfect right now?" might be fun, but just isn't realistic once you dig a little more under the surface.


What you are suggesting, we are already doing in many places, and pushing the hardware to its limits. But even with better simulations, it doesn't automatically make games more enjoyable.


Note: Don't hit the "quote" button. Just type in your reply in the box at the bottom of this page, without quoting me.

#5289510 Creating the game world.

Posted by Servant of the Lord on 30 April 2016 - 09:19 PM

Well, then why not create , probably the word I am looking for is a game engine,

What you are describing is more of a world editor or level editor. Which requires a game engine under the hood, but mostly what you are describing is the 'editor' part.

that can create a program that will simulate a world similar to earth but easily edited with really generalized tools to shape areas,

You can google "procedural generation" and "height maps", if you like.

People have been using procedural generation for earth-like (and non-earth-like) terrain, including rivers, forests, islands, mountains, caves, entire planets, and even man-made structures like building exteriors and interiors and entire cities. Also, for games with thousands of characters walking around, each person can be uniquely generated, and each tree can be uniquely generated. Grass is generated, flowers, stone walls, rocks, etc... Even sound effects and (occasionally) music is sometimes generated by computer algorithms (but music is not yet good enough to be very common).

Minecraft is a popular example, but Minecraft wasn't the first, and many tools and games take it far beyond what Minecraft does.

then more fine tuned tools to create areas for the main game to take place.

After using the procedural generation algorithms to generate whatever size of an area you need, then you use your editor to fine-tune or hand-craft the areas you want differently, and to manually place what you want to manually place.

Now I know this would take a lot of data storage

Depending on how it's designed, it can actually take less data storage.

Have you ever played any older real-time Strategy games like, say, Age of Empires?

Each Age of Empire world is procedurally generated (with very basic procedural generation - it can be alot more complex than that) using what is called a "seed".

A "seed" is a random number, like '228945723934'. The procedural generation algorithms take this one number and can generate the entire terrain that the match takes place in (it could just as easily generate an entire world).

By giving the algorithm the same number again, the exact same process is gone through, and so the exact same area is generated (it's a mathematical formula, so if you give it the same numbers, the same results always pop out).

That means, when saving the big complex world, all you need to do is save the one teeny-tiny number ('228945723934') and let the player's computer re-generate the world on-the-fly as they explore. Any changes the developers make that differ from the generated world needs to be saved, though, and that is what costs memory.

Also, people like open world games where they can do many things right?

You mean like Elder Scrolls series, Fallout series, Farcry series, or Grand Theft Auto series? Each of those series make heavy use of procedural generation. No way they would bother making worlds that large by manually shaping every hill.

I want to hope that the setting of games will stop just being blocks or invincible walls.

Now that's an entirely different issue. That's destructible terrain, and some games do that. See Crackdown 3 for example - every building in the game can be destroyed.
However, most computer devices (whether consoles or PCs) are too weak for that if they want to make it look nice with real physics when collapsing and such. so Crackdown for example, uses Microsoft's network of thousands of computer servers to do those calculations invisibly while the player plays on his XBone. (this isn't necessarily required for simpler simulations, but Microsoft wanted to market their network of computer servers, and so was using Crackdown 3 to show off how convenient and powerful they are).


Everything in the real world has variables to decide strength, this is called density, everything in the real world follows the idea of gravity when on earth,

Many game objects have that - I mean, Half-life 2 was particularly famous for that back in 2004 - 12 years ago, but now it's commonplace in games' physics engines.
Ofcourse in Half-life 2, and most games, not everything has physics applied to it, for the reason I mentioned above: our computers aren't able to perfectly simulate everything continuously.

everything is separated into living and non-living in the real world, in this fake world, it should be made the same so that coding makes sense. I think the problem with programming is thinking of everything as an object instead of making multiple tiers of organized things so everything lines up correctly.

Coding already makes sense. Game developers started off with separating entities into categories like 'living' and 'non-living', and into hierarchies. This is generally called "Object-oriented programming", and though it's useful in many cases, programmers have found that on its own, it's not a silver bullet - and if overused, can make things more complex. So we've been moving more and more to what's called "entity-component-systems" (though there's alot of debate and argument around it, and whether it also makes things too complex!) mixed with object-oriented code, and mixed with other types (or 'paradigms') of code.

Personally, I think ECS (entity-component-systems) is best used at the middle level of "abstraction", with the systems being 'data-driven', and object-oriented code at a higher level of abstraction on top of the ECS stuff, for higher-level design as entity 'templates' (bundles of components with default values) that can be inherited.
But this is speculation on my part (and I'm not in the game industry myself), since I haven't had time to explore that yet; and, like I said, there's still alot of healthy debate among programmers on this topic.

then again I am not a programmer so I will shut up

The correct thing is not to shut up, but to research! (if these subjects interest you)

Coding doesn't make sense to you because you haven't yet learned it, but if you start learning it now, by the time you become competant at it in ten years, maybe our computers will be powerful enough for you to write the very tools and games you're imagining.

Design-wise, the bigger problem is, as fun as it is to say, "We should be able to do anything in a videogame!", that's fine for some games, but for most games, it'd mean they'd be "jack of all trades, but masters of none". That is to say, they'd let you do anything but be boring pretty quickly, and not really be enjoyable in any one strong way. So for a few games that's cool, but for most games it isn't. This goes into game design instead of technology, but one example is, imagine you are playing an RPG, but you suddenly have the best equipment and are super powerful so you can kill anything in one strike - it'd be exciting for about 20 seconds, and then you'd get bored. The same principle applies to other areas of games as well: If you can break though any brick wall, then locked doors serve no purpose, bosses don't need to be fought at all, and dungeon mazes don't need to be explored - just smashed through. A critical part of game design is limitations on what the player can do.

There are still plenty of improvements to technology that games still haven't reached, and there's alot of ground still to cover, but the key to making great games is to use the new technology in moderation. Because too much of an exciting thing makes it mundane. Too much freedom can (funnily enough) lead to a lack of things to do (or rather, a lack of interest in doing them). Too much power means a lack of challenge, too little challenge means a lack of enjoyment of that power. And so on and so on.

#5289469 Should i learn Win32 or UWP?(C++, Directx)

Posted by Servant of the Lord on 30 April 2016 - 03:29 PM

Which application programming interface(API) should i learn for graphic and heavy mathematics software? Win32 or UWP.




Qt is really cross-platform (Windows, Mac, Linux, and they are working on or have support for iOS and Android).

Qt is free, even for closed-source commercial use (ignore the website's intentional fear-mongering to make you pay for a license - it is dual-licensed under the LGPL license)

Qt is much easier to learn and use than Win32, and much easier to customize the appearance of.

Qt has a large community (check qtcentre.org) and fantastic documentation.


Here's a screenshot of the Qt-based program that I'm working on.

#5289373 Scrollbar similar to Windows'

Posted by Servant of the Lord on 29 April 2016 - 10:01 PM

Let me take a shot at it: (this is just me thinking it through mentally, not having done it before)


First, we have to know how large the scrollbar "groove" is (excluding the up/down scrollbar buttons), which is determined by the parent widget. Let's say, "grooveHeight = 213 pixels" as an arbitrary number. This groove represents 100% of the content in the scrollable region, including the content offscreen.


Next, we need to know how large the scrollbar "thumb" is. The thumb represents only the content onscreen, so we need to know the amount of total content (totalContentHeight = 462 pixels), and the amount of content that can be visible onscreen at once (visibleRegionHeight = 230 pixels), and get the percentage between them (visibleRegionHeight / totalContentHeight = 0.5), which means "scrollbarThumbHeight = (grooveHeight * 0.5) = 106 pixels".

(Note: you want to have the thumb have a minimimum size - say, 10-15 pixels, otherwise it could get so small it's too hard to drag (or even impossible if it becomes 0 pixels)).


Now when you drag the thumb, you don't let the thumb's top go above 0, and you don't let the thumb's top go below (grooveHeight - thumbHeight).


To figure out what region of the screen is visible, you get the thumb's top position (say, at 61 pixels from the top of the groove), and divide it by the total groove height (213 pixels) to get a percentage (0.29).

Then, you multiply that percentage against the total content height (which we said was 462 pixels, giving us topOfVisibleRegion = 134), which is the top (pixel-wise) of the visible region, with the bottom of the visible region being (topOfVisibleRegion + visibleRegionHeight).


Basically, the scrollbar groove and thumb are at a different scale than the page they represent. The scrollbar's groove represents the entire content area, but must fit into the visible content area, and so must be scaled down. The thumb (scaled at the same scale as the groove) represents the visible content area, but it obviously can't fill the visible content area, or it'd be filling the entire groove and have no groove-space to scroll.


Internally, you'd want to use a measurement that is fine enough for the entire totalContentHeight, so you should store your "position" at that scale (i.e. total content pixel scale), and only scale it down for display purposes, or when calculating the new position based off a mouse-drag. That way, when you programmatically set the location of the bar (for example, in response to the scroll wheel or PageUp/PageDown, or in response to clicks on the scrollbar's up/down buttons), you can do so with finer precision than merely the amount of height the parent widget happens to give.

#5289340 The Cat Virus: Is this a feasable project?

Posted by Servant of the Lord on 29 April 2016 - 04:42 PM

You gave virtually zero information about the project (other than, it's a first-person shooter, and unimportant theming information).

You also gave no information about your skill level, how many people are on your team, their skill levels, how large a budget you have, how much time you have to develop it, and so on.


There's not enough information to answer your question.


Is climbing a mountain feasible? Sure, if you're an experienced mountain climber, with the correct equipment, and if the mountain happens to be small, and if the weather is favorable. Is it feasible for me? Nope!  :P


Since we don't know what mountain you are talking about (other than "first person shooter involving tote adorb kitties"), and we don't know what mountain-climbing skills you have, or what the weather (budget and timeline) you're talking about, then I doubt any of us can answer the question properly.  :mellow:


Instead I'll try to help by asking you some self-reflective questions:

 - How many games have you made before?

 - Compared to your previous game, how extreme of a jump is this new game going to be to develop?

 - As far as the stepping stones of games go, getting you from the present to your eventual long-term goals, is this project the smartest next step for you, or are you trying to leap too many steps at once?

 - Are ready to make this game skill-wise?

 - If you need help (3D models, animation, music, programming, etc...), do you have the money to pay for that help upfront (not in fantasy "profit" sharing)?


If you answer those to yourself, it should also give you better insight into answering your own question.

Sometimes the answer is, "I'm ready; let's do this thing". But more often the correct answer is, "Let me slow down and go about this more methodically"


If that second answer is the case, then no worries, here's my advice: Many creative individuals have been forced to work under limiting circumstances, and often find that the limitations help their creativity shine all the more.

So my suggestion is, first figure out where you are at (skill-wise) and what you have available (resource-wise (time, money, free help)), and then decide what you can within the boundaries of your known limitations, and how far you can stretch them to create something incredibly impressive despite what you are working with.


Basically, instead of saying, "Here's what I want to do next, can I do it?", I suggestion, "Here's what I have available, what should I make?"


Hopefully that's of some use to you.

#5288948 what is meant by Gameplay?

Posted by Servant of the Lord on 27 April 2016 - 11:53 AM



Not necessarily -- its true that many scripting languages are compact or have features (e.g. actor-model, prototypal inheritance model) that lend themselves to scripting game entities and game interactions, but that does not mean that writing gameplay code in C++ has to more difficult or more verbose for the people "scripting" the gameplay elements, albeit in C++.


Many custom scripting languages are basically just stripped down C-syntax anyway.  :)


There is no reason you _have_ to use a scripting language.


[...stuff I agree with....]


With just a few people, where everyone is part engine part game implementers, and everyone already know C++ well, there is little reason to use a scripting language.


Yep, totally agreeing with that. My comment was that many custom scripting languages are just stripped down C-syntax anyway, so people might as well just use C++ which already contains that syntax, and more useful features as well!  :)

(unless they have need of the benefits scripting provides)

#5288869 Engine Subsystems calling each other

Posted by Servant of the Lord on 26 April 2016 - 10:52 PM


Wait, why are pointers so evil(according to isocpp) again? I have never been introduced to this idea before. I myself love pointers...

Probably because they want you to use smart-pointers and references.
Raw-pointers are an extremely common source of memory management bugs.


And even with smart pointers, raw pointers are still actively used. My definition of "evil" in programming means, "by default, it's not the right choice, so if you think you need it, think twice over before continuing."

The key is knowing when to use what tool, but to have your defaults ready. By default, unique_ptr and shared_ptr and weak_ptr make more sense, but raw pointers are still used for non-owning access where the lifetime of the object is garunteed to outlast the lifetime of the pointer. Usually these are and usually cycle-breaking relationships, like a child pointing at its parent (the parent is implicitly guaranteed by the code, not the documentation, to never 


By default, one should avoid GOTOs, but in hyper-rare scenarios, a GOTO can be useful.


By default, one should avoid (non-const) globals (because you want to enforce your access guarantees in your code as much as possible, not merely your documentation), but there are some cases where (A) the global truly isn't harmful, and even rarer cases where (B) the harm is actually the lesser of two evils. But by default, you want to be extra vigilant and see if there are better solutions first.


One example of a non-const global that isn't harmful is a logging system. This isn't harmful because logging systems are usually the inverse of const: They are write-only, rather than read-only, so it still makes it impossible for the logging system to invisibly change the state of your sub-systems. There are flexibility reasons why you may want more than one logging system, though, or a separate logging system for different sub-systems (or more likely, separate threads in a multithreaded project); but those are steps up in complexity, and a write-only logging system in a single-threaded project is one example of a safe global.

A rendering system might also meet this definition of write-only, but because rendering systems are alot more complex, multi-layered, low-level, and often call into the OS and videodriver, and have multiple behind-the-scenes implementations depending on the platform, I wouldn't assume it is safe until I can validate that assumption on a case-by-case basis and then enforce that in the code.


I don't use defaults to turn off my brain, I use it as an early warning system to alert my mind to be extra vigilant if I choose anything other than the default. i.e. I use code smells.

#5288866 what is meant by Gameplay?

Posted by Servant of the Lord on 26 April 2016 - 10:10 PM

One benefit of a scripting language or domain-specific language, is the hot-reloading for faster iteration - if you don't have features like Edit and Continue, run-time interpreted C++, or keep your gameplay logic in a DLL that you reload on the fly (which only partially mitigates the issue).


But another important benefit is being able to hot-reload server-side for server-side logic changes without having to restart your game servers (for ORPGs and the like). But that's not needed for every game.


Not necessarily -- its true that many scripting languages are compact or have features (e.g. actor-model, prototypal inheritance model) that lend themselves to scripting game entities and game interactions, but that does not mean that writing gameplay code in C++ has to more difficult or more verbose for the people "scripting" the gameplay elements, albeit in C++.


Many custom scripting languages are basically just stripped down C-syntax anyway.  :)