So I've been running into a debate at work about what the proper role of a scripting language is in game development. As far as I can tell there are two schools of thought on this:
1) The scripting language is powerful and full featured. Large portions of game code are written in the language and code is only moved into C++ when performance dictates that it's necessary. This is usually something like Lua or Unrealscript.
2) This scripting language is extremely limited. Almost all game code is in C++ and the language is only there to expose the underlying functionality to designers.
My frustration comes from seeing approach number two frequently abused, with large systems implemented in a language that does not have the features that make that code maintainable.
So I started out supporting approach number one, but after talking to some designers I realized that many of them seem to prefer number two, and its mostly programmers who prefer one.
So I'm still left wondering which approach is better. Am I just seeing bad code and blaming the tool instead of the programmer, or do we need really need a more complex tool?
The compile-link-run-test cycle for compiled C++ code when you're dealing with something as complex as a video game is very, very slow. Using a scripting engine allows you to make large functional changes to the game without having to compile the program. This is a massive, massive time savings. As you say, things that need optimization can be moved into C++ as required.
AAA engines are highly driven by scripting. Torque, used for Tribes II (and many other games!) is scripted, Unreal has Unrealscript and so on. Scripting isn't just for mods, it's key to efficient development.
I think designers need to see a language suitable for them. That's not negotiable: they have to spend their time designing, not programming.
If scripting allows fast development of product-worthy game code, then the programmers should be doing it too. But it has to be product-worthy: doing everything twice doesn't save time. So you have to keep scripting in its place. If a developer can script the inventory system in a week, or write it in C++ in a month, then you want full-featured scripting, if only to give you more time to hand-optimise the parts that might conceivably hit performance limits. So not the inventory, or the high-score table, or the key-mapping system, or high-level game logic like what the characters are supposed to be doing. That can all be scripted if doing so saves you any time at all to spend on speeding up the graphics and the physics: programmers need to be able to work out exactly what the bottlenecks are, and senior programmers can make a reasonable prediction what won't be.
Designers probably shouldn't know or care whether the programmers are using the scripting language to implement game code. They shouldn't have an opinion whether (1) is good or bad. So even if the programmers are right to want (1), why is this inconveniencing the designers? How have they even noticed that the scripting language is full-featured, if all they ever need is a fairly small number of standard recipes? Something has gone wrong, but I don't think it's that Lua is too good a language.
One possibility is that using the same scripting language for both, becomes an obstacle to drawing a sharp line between the interfaces used by designers, and the interfaces internal to the game code. That, as I said at the top, is not negotiable. Even if they're using the same scripting language, programmers still have to provide the designers with the functionality that they need to do their job. Just because designers use Lua to code up AI strategies and conversation trees, and Lua is full-featured language capable of writing a physics engine, doesn't mean your designers are expected to write their own physics engine. Or use more than 10% of Lua's capabilities.
You can probably do both (1) and (2), mind. There's no reason you can't give the programmers Lua, and the designers some miniature under-featured DSL which is "compiled" into Lua with a Lua script.
I think the balance you want is something to this effect: you want game logic in script, but game functionality in code.
One big big advantage of script is that you can set up waits easily. For instance:
enemy = GetObjectFromScene ("enemy01");
in 5 seconds { enemy.ThrowGrenadeAt (player); }
Just a contrived example. That kind of logic would be annoying to setup in C++. Script can make it easier to express this kind of logic, but you'd want the actual functionality (the functions it calls) to be in C++.
And script doesn't have to be slow. There are heavily scripted games running at 60fps on consoles, but it requires a good design and finding the right balance between your options 1 and 2 above.
I can't really see the argument that large amounts of scripted code is going to be superior to large amounts of C++. One could make the counter argument. I've seen terrible large projects written in scripting languages that started out with the scripting mentality--getting things done quick and dirty. This unfortunately doesn't scale well. There's really no way to make a code quality argument based solely on the programming language. People can write gobs of maintainable code in any language, compiled or scripted.
Anyway, its really impossible to know the line between your "approach 1" and "approach 2" without knowing where the performance bottlenecks are and what your users are going to most want to "script".
I would suggest an "approach 3" which is to do it all or in part in C++ and expose a clean SDK in C++. This would have the advantage of forcing you to write your code as if it were a user interface someone outside your organization has to use. It would hopefully cause it to be more maintainable AND have the added side effect of implementing your scripting interface for you. All your scripting interface would need to do now is forward to your SDK. Viola!
With this approach you avoid having to draw a line between the realm of what is "scripted" vs what is in C++. You and your users keep a choice to either add functionality in C++ with the SDK or use a scripting language.
As usual, I think the answer is "it depends."
There's NO WAY Halo 3 or Call of Duty 4 could have been based primarily on scripting. Top-rated AAA titles must, by definiton, push the envelope of any platform they touch. This just can't be done with scripting.
Casual games, however, are a different story. Major game eninges like Unity have lots of scripting built in.
There is also a market for mods. A solid game engine with a good scripting environment can be a platform for tweaks, derivations, and in some cases altogether new games. Counter Strike is my personal favorite example. I think you're limited in this case to FPS run-and-gun type games.
So, there is a place for scripting in games but it will probably stay in the small/casual game and modder's space.
One of the best examples of scripting in action is Civilisation IV. It uses Boost Python. As a result, it is horribly slow. A clear counterpoint to the statement that "code is moved into C++ when performance dictates that it's necessary".
The proper way is to design an architecture up fron, and decide which problems are computationally hard and which are complex to specify up front. Graphics, physics, pathfinding, instant feedback on input, text to speech - all clearly computationally hard. "Friendly or hostile stance", "defend or attack", "spend or save" type AI decisions are all complex to specify up front.
The conclusion is that you want to expose capable, but soulless actors to your scripting code. The scripting code describes what the actors should do, but the C++ code takes care of the how.
With regard to the compile-link cycle, it's important to have a proper modular architecture. When you are working on the pathfinding logic, you should never have to compile graphics code. Also, tools like Incredibuild can help speed up compile times. Big game firms probably already have a render farm, which can double up quite well as a compile farm.
Saying that games should be done just with C++ (or claiming that AAA titles are done like that) is just being ignorant. Most of the games nowadays are scripted in a way or another, be it proprietary scripting language (UnrealScript), generic language (Lua, python, C#, Java etc) or data-driven (xml, proprietary binary format etc). Just make some research and you'll find out that most engines employ scripting in one form or another.
I think the question of whether to have 1) powerful and full featured scripting language vs 2) extremely limited scripting language is approaching the problem from the wrong end. The scripting environment (language or data-driven) should be designed so that it best supports the process of creating the game. The expressiveness of the system is crucial here: the designers and scripters should be able to easily solve the problems they have without too much headaches while they shouldn't be exposed to too complex system that they have difficulties understanding and learning. Often programmers (myself included) tend to design systems by making assumptions how it is going to be used and trying to ensure that all features between earth and heaven could be implemented, resulting in complex systems. Being overwhelmed by this complexity, the designers end up using the minimum to get the work done.
For example in our game (Rochard) we designed a fully expandable and scriptable data-driven AI system, but the level designers ended up using just the stock AI patterns because they didn't have time or effort to utilize the AI system to its fullest extent. So in the end I just created a good UI for choosing those stock AI patterns easily.
I'd say there is no silver bullet in this matter.
So I started out supporting approach
number one, but after talking to some
designers I realized that many of them
seem to prefer number two, and its
mostly programmers who prefer one.
This should make obvious sense: if the scripting language is "powerful and full featured", there is an onus on the designers to have to create the systems, since this opportunity is available to them. On the other hand, if the scripting language only exposes small details of the hard-coded game, then the programmers have to create those systems, since designers cannot. I'm not saying each side is lazy, but obviously both have individual skills the project requires them to focus on (since nobody else can do them as effectively), meaning there is always an interest in getting someone else to do a given task if possible.
And following naturally on from this, the proper role will depend on how the human resources in your company are laid out, in conjunction with any performance requirements of your game. Once you have an idea of how many people will need any sort of scripting, you'll know how much of the game will require it, and therefore can decide how how wide or narrow the interface needs to be. This contributes to what the 'domain' of the language would be, as mentioned by onebyone.livejournal.com above.
(For what little it's worth, I'm a professional game developer and also the moderator of the Scripting Languages forum on Gamedev.net.)
The game development community already uses scripting as a very common way of building user interfaces and tuning AI responses. You can find lots of info on sites like Gamasutra. The interesting thing is that standard languages are starting to replace custom interpreters.
Two of the best scripting examples in AAA games that come to mind are World of Warcraft (uses Lua) and EvE Online (uses Python). EvE uses scripting on the server-side too: they have a significant investment in Stackless Python.
Update: Performance will essentially be a non-issue due to multicores. Even low end machines will end up with more cores than the display and model updates need. You might as well spend one of those cores running a scripting solution for the UI.
As has been said before; use scripting for game logic, and C++ for game functionality. An example would be scripting a game mode, but using C++ for rendering.
If we split a game into two parts: The engine and the actual game (design).
A solid top class game engine is most likely written in C/C++ and some people even optimize further with assembler code. You can do a lot of neat really fast stuff for graphics and physics with specific CPU instructions. There is no way to get performance when rendering large landscapes or multiple complex objects from a scripting language only.
When it comes to the game itself where are a lots of aspects that can be done in slower but higher level programming languages. AI and other game logic can be written in script with success. It can speed up development and it opens up for modding and community expansions in a simple way.
I think the poster here is correct to favor method #1. It is a cleaner method and will yield better long term results despite the complaints of designers. In the end the code will determine good game programming from mediocre (bad).
Related
I've studied a bit of Lua, and I'm relatively familiar with C++ but I still don't see any real reason I would want to use Lua (or any scripting language for that matter) in conjunction with C++. If I'm already making a game in C++ (a fast language) why wouldn't I just do everything in C++? After all, I'm already familiar with C++. Why should I spend time learning a new language and how to integrate it into my C++ code? I'm sure there would be issues just getting the interface set up and working. Learning would take some time, how would it really pay off? Would it really only be beneficial to large development teams?
I echo what has been said, and I want to add my own thoughts as I am integrating Lua into my game engine this very moment!
It depends on what kind of game you are making, but regardless of your feelings on allowing fans to mod your game, it's just good practice to separate engine components from gameplay components.
The first major benefit is rapid iteration. The best decision I made was connecting the F5 key to reloading the Lua state (just like a browser's F5 refresh, in case that wasn't obvious). I can edit the script and then just mash F5 in my running engine to see the result right away. This is much more effective than rebuilding native code. You are less likely to lose your train of thought, and you can debug (gameplay) problems very quickly.
I find that working in Lua makes me more creative. It helps me set aside my rigid, unforgiving engineer brain and bring out my experimental, #YOLO brain. Why does my character's HP need to be carefully and precisely stored as a 32-bit integer in a C++ object? No part of the engine needs to know about that kind of information. The higher level gameplay is the only thing that cares. HP is updated only occasionally, and it relates to "the rules", not any kind of engine consideration.
Think of C++ as your master violinist and Lua as your conductor: your violinist better be really good/fast at playing the violin, but your conductor doesn't ever play the violin; he just tells your violinist to play louder/softer/faster/slower.
Lua is slow (relative to C++), but that is fine. Lua does not need to decompress an OGG into PCM in under 5ms; that is your engine's job. Lua makes extremely high level decisions: "This is the audio I want played at this moment."
I do many projects alone, and I can honestly tell you that integrating Lua is a very good thing. It creates a very clean separation between low level technical mumbo jumbo and your actual game.
It is generally good practice to split layers of an application from each other with abstraction.
Quite often part of your application is highly performance insensitive.
If you place a scripting interface between the high performance core and the performance insensitive scriptable portion, you first gain a huge abstraction layer benefit. If done right, no errors in the scripting portion can cause memory corruption or otherwise invoke UB.
So now that code cannot intermingle, and mistakes in it are insulated from the rest of the app.
On top of that, you now get to work in a language that makes many things (object lifetime, string manipulation, runtime modification of logic, etc) really easy. The lower risk from errors plus the ease of expressing things can massively increase your ability to prototype new functionality, and reduce QA overhead before shipping it.
On top of that, because you have a scripting engine, your game can now "safely" rewrite itself: doing so in C++ pure would be much harder. And rewriting yourself is a powerful tool, if dangerous (even "safely")
Mostly for flexibility, if you want to later change the behavior of something its easier just to change your script and reload it instead of having to re-compile your server.
Here is an overview as to why Cryengine uses it(engine for the popular game series Crysis): http://docs.cryengine.com/display/SDKDOC5/Script+Usage
and this is an MMORPG project that has its core in C++ and scripting in Lua: https://github.com/otland/forgottenserver/
Okay, so I've been getting into 2D game developing/programming , and many games I've seen use some sort of scripting language too. So I'm wondering - What's the purpose of using scripts in games? I know there's not simple one reason answer, and I've been trying to consider all the possibilities. Here's what I 'think' I know so far:
1) Scripts allow for changing the game without having to re-compile.
2) Scripts are easier for non-programmers to use.
3) Scripts allow me to separate the engine from the game itself allowing me to make other games with the same components quicker?
That's about all I'm aware of. My next question is, if I'm going to be Dev/programming a game alone - do I really need to use scripts? Or could I prototype the game using something like python or ruby, to allow for rapid testing, then rewrite the code in C++ saving time and compiler bugs, etc?
Another thing I'm wondering, Am I better off using Ruby or Python since I'm most experienced with those? Or should I use Lua, Perl or something else if it better fits what I aim to achieve? Speaking on that matter, what really should I use scripts for? should I use them to position and model game menu UI's, write/read save-files, load map levels, hold arrays or structures of game terminology such as "New Game" or "Quit," all of the above, none of the above?
If I make use of scripts, won't that allow game mechanics to be edited by the end user? Or is there a way to package the scripts into one compressed file that the engine can read?
Most basically, I'm wondering:
What should I use scripting in my game for? And why?
Do I need use scripting languages if I'm working alone or with programmers as opposed to Devs?
What scripting language 'should' I use if I were to be making platformers, RPGs, or what-have-you?
your top 3 reasons are all 100% correct and are the main reasons for using scripting languages along with your game engine.
Personally I've only really had experience with Lua through Luabind. It's a little tricky to setup but it was worth it. What you can do with scripting languages is expose the data structures and/or functionality that you want the 'user' in this case yourself, to be able to use. Generally speaking the only game mechanics etc that can be editted would be the ones you allowed them to.
What should I use scripting in my game for? And why?
Asset loading, exposing features/types, ie, for our game engine (written in c++), we had a base level, and then many different types of level inherriting from it, such as wave level, death match, etc. The user simply states in the script what type of level they need, and then chucks in the assets here too. In my demo we had;
Level="wavelevel"
--Level Initial number of enemies
EnemyNumbers="3"
--Level Total number of waves
WaveNumbers="4"
--Wave coefficient
WaveCoeff="1.1"
--Size of terrain
TerrainSize="256"
--Terrain file
TerrainFile="resource/Models/mountainous.raw"
Don't worry too much about the numbers and all of that.
As you can see that does some asset loading as well as determining the level type
We also gave a lot of control for the AI to scripts, in fact, the data structures were almost completely exposed to Lua.
Do I need use scripting languages if I'm working alone or with programmers as opposed to Devs?
Yes no maybe? We all prefer 'real' coding of course. If you can make your game engine abstract enough to build completely different games just with Lua, then it means you've done a great job and have designed it very well.
The other thing you have to think about, especially if you're game engine is quite huge, and lets face it, there isn't really going to be a small one, each time you compile, it can take minutes! It's the linker that's taking time here.
What scripting language 'should' I use if I were to be making platformers, RPGs, or what-have-you?
I've only ever used Lua, so that's the only advice I can give here.
Hope this is helpful info for you.
Honestly, as this sounds like your first attempt at a game ever, you shouldn't even be worrying about this sort of thing. Instead, I'd be more worried about keeping the scope of your project down to a level where you have a snow ball's chance of actually completing something. If you haven't done something at the level of Tic-Tac-Toe or Pong yet, do that first. What you learn there will be more valuable than worrying about a scripting language.
Oh and if you are doing an RPG as your first attempt at a game. Don't. They are by far the hardest type of game to do even for professional developers with many, many times the resources available to them. Keep it simple and and use this as a learning experience.
Back to your questions:
If you are the only one who will ever see your game, your choice on using a scripting language or not. If it will save you time overall or you want to learn how to do integration of scripting with code, go for it, but beware it will be a bit of a time sink.
Yes/no/depends on your second. If the scope of your game is small, scripting isn't as important. If you doing this alone, scripting isn't as important.
Your choice on what you know or what your engine will support (or what engine tools you cna buy to support). Lua is popular, but even hand rolled scripts will work as well. It's more about decoupling data from code and design type work from engineer type work.
Your initial points above apply. Scripts keep non coders out of code and allow anyone on a team to easily change data related stuff that should be in code anyways. Scripts also act as a very high level language allowing lots of game level changes in controlled ways that would/will look ugly if placed in code. I've personally worked on games that were done both ways. Scripted games were a bit easier to maintain at the end of the game cycle - IF IF IF the script support code was mature and had been run through some debug cycles. New script support code is harder to debug than coding things straight because there are more possible points of failure. Games that were coded without scripts tended to get done a touch faster, but required a lot more programmer/engineer time which means the overall scope of things had to be limited to stay on budget.
I will say that well designed scripting and overall gaming system will always beat straight coding. Look at Unity for an example of how scripting and code and everything else can be coupled into a slick interface that allows very quick game development.
What should I use scripting in my game for? And why?
The reasons you cited are good ones. One thing that you might need to understand is that most professionnal games are still built with C++ and it's far from being flexible to change if the code base is big. So if you use C++ you'll need scripting languages to make quick changes where it's imporant to be allowed to do so accordingly to the reasons you listed.
If you don't use C++, maybe you use a language that can absorb changes quickly, making the main purpose of scripting not so obvious. I wouldn't use scripting language in a Flash or Python game for example.
Do I need use scripting languages if I'm working alone or with
programmers as opposed to Devs?
As my previous answer : it depends on the timing of changes. Think that the core rules of games rarely change but everything relative to level design will, and should be testable ASAP. If you can do it in the game's programming language, why bother? If you can't, then any way to speed-up change integration will pay.
What scripting language 'should' I use if I were to be making
platformers, RPGs, or what-have-you?
Frankly, there is no one solution to any problem. I personally use Falcon and ChaiScript, Lua is well known but any scripting language that can be used with your game programming will do. That's a question already asked around and if you have doubt, just choose Lua as it's the most common in gaming.
I'll give you a quick and short answer. Scripts are mostly for changing things while the game is still running which you can edit things faster. This is much better then recompile, reloading the assets, going to the specific point in game, activate certain conditionals (items, talking to people in specific order, etc) and etc.
Things done in script are character speech, NPC interaction with triggers (for example walking somewhere stopping to talk to another NPC, then run somewhere, scripting is used for timing), triggers or events in general and enemy stats (health, speed, accuracy, sometimes logic for said character).
The reasons you list are all valid reasons for using scripting languages in games. I'd also add another reason though: different languages are better suited to different kinds of programming tasks and a high level scripting language allows you to write parts of your game in a language that might be a better fit than C++.
The main reasons C++ is widely used in games are performance, easy access to low level native APIs or hardware (on consoles) and inertia - most games are written in C++ so most third party libraries and middleware for games are written in C++ and most easily interfaced with from C++. For many tasks however higher level languages like Python, C# or Ruby have programmer productivity benefits over C++ that can outweigh the advantages of C++ for code that is not performance critical or does not have to interface with native APIs.
A well designed C++ game engine with a high level scripting language can give you the best of both worlds - the performance and low level access of C++ where it's most needed and the productivity benefits of a high level language where they are most needed.
As a matter of fact, almost all MMORPG game servers are programmed in script.
All the C++ engin will embed a script language for logic handling, lua is a suitable script language for it.
In bigworld, python is the default embed language.
And node.js is also a good candidate for game server programming. Because its network io ability is superior. There is an open source framework in node.js:
https://github.com/NetEase/pomelo/
I've found it unhelpful to use scripts, both when I was employed in a large game studio and in my work as an indie developer. On the other hand I have friends who've used professional-grade, modern engines with scripting technology successfully. As you're doing indie game development on your own (or in a small team), I think you should avoid it. The main reasons are:
It adds overhead pretty much everywhere: one more language to master (per developer in the team), performance is slower than native, and the API the weakest link which means you often need to rebuild the binary anyway.
The only real gain with a higher-level language is less development hours up front (if you're using a mature engine), but in my experience that time is eaten up by time-consuming bug-smashing in the end.
Many game scripting languages uses dynamic typing (Lua, Stackless Python, Pawn), which I find error-prone compared to statically typed languages. If you too feel it's only good for simple things, you might as well do it natively instead.
As a side-note I do find game scripting languages exceptionally useful, but only for quick-hack/prototype apps, not for huge components within games. See my answer here.
I'm not convinced scripting interfaces for games you write yourself are so useful. I did some work on Freeciv once, and immense effort went into enabling "modding" using the scripting interface. A feature that seemed little used. I think there is a danger of the inner platform effect. You don't need a scripting language to customize your game: you already have a perfectly good programming language (C++, in your case) for doing that. It's a WTF.
What should I use scripting in my game for? And why?
As everyone (including you) has said, scripts make your game easier to edit. On a larger team scripting also has a very good productivity effect: the tech-savy folks can continue to polish the engine, while the creative people can work on the actual game, and the two teams don't have to get in each other's way.
Do I need use scripting languages if I'm working alone or with programmers as opposed to Devs?
You don't need it and depending on what you're final goal is, it might actually be a waste of time to implement scripting. I also develop a 2D scriptable game atm; I'm alone but I'm making it scriptable also as a personal challenge and also because I want the game to be easily modifiable.
What scripting language 'should' I use if I were to be making platformers, RPGs, or what-have-you?
The top two most popular options are Lua and Python. Most people recommend Lua because it's slightly faster. I went with Python because it has (native) support for classes — which works well with my existing C++ architecture — and also because I find it to be a much more enjoyable language to work with.
Okay, I know this is a bit dead, but I have to say this. There is literally no such thing as programming without scripts. It honestly doesn't matter if you write them in yourself or not, fact is, somebody wrote those scripts. Like ruby, in order to use it, you need a program like say notepad+ in order to set it up, or any computer based RPG Maker from enterbrain uses a form of ruby to operate. like it or not, when using computers to design a game, learn to script. Now as for the language, look some up and try different ones out. Don't cheap out with using a pre compiled engine, just work from scratch. trust me, you will be better off. I am still trying to decide which I like better, Lua(C++) or Ruby. I may just use pure C++
Another one of my rather ambiguous question today, sorry.
Currently I have written some half decent software that has a 'roll your own' RESTful client, which pulls data from twitter. This data is then visualized with a number of particle systems using Open FrameWorks (a framework that works with c++).
My plans for this were to run the software indefinitely on my VPS, and build some kind of front end GUI allowing users to explore the pretty particles and so on. Between the JSON library I am using, C/C++, OpenFrameworks, and freaking Xcode4 I have produced way too many SIGBIRT and GDB errors to care for. I have go to the ends of the virtual world to fix them, and re wrote everything over and over. I even managed to SIGBIRT the openframeworks draw circle method, HAH!
(TL;DR starts here) Ok so anyway I am starting from scratch, looking for a powerful language that can crunch maths and blast through a good set of particles, and run quite well over the longest periods of time. Right now I am thinking about haskell, any ideas?
Thanks in advance all!
Haskell's (or more specifically GHC's) number crunching speed is approaching that of C++ but it's a little way behind. However, it's certainly not terrible, and Haskell's advantages in parallelism may become important. That is, if you write it in straight Haskell first, there's a good chance that it'll be easy to refactor it to run in parallel now or in the future. That isn't so true of C++.
The 'vector' package (on Hackage) would be a good choice for arrays suitable for number crunching. It supports mutable arrays in case that sort of approach is needed. However, if you're prepared to go more on the bleeding edge and your algorithm can be parallelized, you might want to look at the 'repa' package, and for extreme performance on a GPU, take a look at 'Accelerate' (which works but is still categorized as experimental).
The crashes you mention sound like they could be an indication of a bit of complexity in your problem. Where Haskell does well is in managing the complexity of... well, anything. So, if the problem is complex, then Haskell will serve you very well.
The foreign function interface in Haskell is well designed, though you will need to write C glue between Haskell and C++. So, that's another option for your number crunching.
For the web interface, take a look at 'yesod' which is seeing very active development and advertises itself as doing RESTful.
AFAIK, number crunching speed is not Haskell's strongest point - it's a highly abstract language, far from the 'metal'; its strength in a numeric processing context lies in the "mathiness" of its semantics - Haskell code often reads much like a Mathematical proof, and many of its concepts are borrowed from various fields of Mathematics.
For plain old number crunching, C++ is probably still your best choice, as it allows you to stay close to the hardware and optimize tight loops at the machine level, while offering higher-level programming constructs to manage complexity.
OTOH, if you have a library in place for the heavy lifting, and you merely need to write the glue to make the various parts work together, then go with whatever you're most comfortable with - python, C#, java, haskell, C++, ... - as long as they have bindings for all your libraries, you're good. If you don't have a library, then you might also consider writing the performance critical parts in C, and then pull them into your favorite high-level language - this is trivial in C++, slightly harder in python or haskell, and pretty damn inconvenient in java.
I've been into several tutorials and links for how to integrate scripting into games--but most of these don't start early enough in the process for me. I am trying to wrap my head around the basic structure of an effectively scripted game. Here are the basics:
I'm working on starting a basic 2d RTS game in C++. The mechanics of the game and the graphics are pretty standard/simple, rather the logic and data will be extremely complicated compared to a standard RTS. Obviously, I have a lot of planning to do--and really, the point of this is more to learn C++, scripting, game programming basics rather than actually complete my project.
I'm trying to figure out which elements of my project should be handled by scripting and which should be included in my core "game engine".
For instance, the all powerful "game loop" -- do I program this in C++ as part of the engine, or will my "engine" be solely what I use for displaying graphics (tiles, characters, etc...), processing the large amounts of data, and similar tasks--and these classes get "plugged into" the game loop, which is scripted?
I would like to use C# as a scripting language, from what I've read it offers good speed while still allowing to develop in VS, which I like. But really, I'm more concerned with how it's all supposed to get set up, more from a pseudo-code level than the actual coding. There's plenty of resources I can use when I get to this point, I'm just looking for advice on how to structure the whole thing.
Any tutorials, resources, advice would be greatly appreciated! Thanks!
icnivad's recommendation for Programming Game AI by Example is an excellent one, it's chock full of practical information.
In terms of actual engines, Unity does the job and lets you script in C#, but for someone, such as yourself, who wants to learn the nuts and bolts, it may hide too much and do too much for you. Irrlicht is a pretty solid C++ engine and comes with lots of tutorials to get you started; it also has a very clear interface and a pretty active community. In terms of what you want to write in C++ and what you want to script, I suggest taking a hard look at what you actually need to script--if you need to script anything at all. You could write the entire thing in C++, which has the advantage of being more easily debuggable. Speaking of which, if you're still new to C++ and game dev you might want to stick to just C++ at first (if not, just ignore this).
"Debuggability" is one of the things you should be paying attention to, since it can often be extremely hard to debug C++ and script code at the same time (when you're shuttling data and instructions back and forth). That said, once you have your framework up and running, implementing new features and tweaking stuff can be a breeze.
You may want to take a look at Lua as a scripting language, as it's quite popular for game scripting. Luabind, a popular binding library for C++ and Lua, is pretty easy to use. SWIG is also available (a short tutorial on it popped up on a blog at GameDev.net recently).
No matter which scripting language you choose (if any), make sure you work on some separate toy programs with them first. Get used to the language and fiddle around with it. Then try small programs with minimal C++ <-> script interop. Do only a few steps at a time so you can spot errors and note what works and what doesn't. Once you feel ready to start integrating scripts into your game, do only one step at time and test it to death before moving on. Speaking of which, make sure you also plan how and where you'll connect your scripts to the game on paper first--it makes things much easier.
Generally, you'll want to put all the heavy work on C++'s shoulders (like the game loop, graphics, pathfinding, etc.). I've found that scripts are usually best for things like configuration files, behavior code for AI characters, UI, and event handling. Basically, if you're going to tweak/change something a lot or you want other people to be able to change something, it's a candidate for scripting (no recompiles for the win!). Just remember that a lot depends on your specific game--if scripting something would be too slow (use your profiler to check), too cumbersome, etc., don't be afraid to do it in C++ and call it from the script or just do it entirely in C++.
Hope that helps!
The book Programming Game AI By Example is superb, and touches on just what you are looking for regarding game loops, using scripting (like LUA), and tons of examples of stuff that seem especially pertinent to you.
By the way, potentially relevant is the Unity3D game engine that lets you use C# for scripting. And there is also Garage Games engines, including the game builder kits that could help you create an RTS type game, and I believe you may be able to code in C# for Torque as well.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm thinking of trying to make some simple 2d games, but I've yet to choose a language. A lot of people recommend either C++ with SDL or python with pygame. I keep hearing that developement on C++ is fairly slow, and developement time with Python is fairly fast.
Anyways, could anyone elaborate on this? What exactly makes development in C++ so time consuming? The programs I've made have been Project Euler-style in that they're very short and math-based, so I have no experience in larger projects.
There are two things that are relevant between C++ and Python that will affect your time-to-develop any project including a game. There are the languages themselves and the libraries. I've played with the SDL to some extent and peeked at PyGame and for your specific instance I don't think the libraries are going to be much of a factor. So I'll focus on the languages themselves.
Python is a dynamically-typed, garbage-collected language. C++ is a statically-typed, non-garbage-collected language. What this means is that in C++ a lot of your development time will be spent managing memory and dealing with your type structure. This affords you a lot of power, but the question is do you really need it?
If you're looking to write a simple game with some basic graphics and some good gameplay, then I don't think you truly need all the power that C++ will give you. If you're looking to write something that will push the envelope, be the next A-list game, be the next MMO, fit on a console or a handheld device, then you will likely need the power that C++ affords.
The power of Python is in it's ability to allow you to focus more on the problem than having to deal with testing low-level issues such as memory allocation. I can't count how many times days of development have been wasted tracking down memory leaks in C or C++. An advantage of all high level languages.
Python is very easy to learn compared to C++,so you can be up to speed a lot quicker in doing basic programming tasks. Therefore, you'll move quicker into advanced tasks as well.
C++ has a lot of power but has many ways to shoot yourself in the foot compared to Python(not saying that can't be done in Python).
The compile/debug cycle can get old sometimes in C++ depending on what you're trying to do. Although technically speaking, everytime you run a Python script it's getting "compiled" per se, it's just a quicker cycle. A good IDE can help alleviate this is in Python by automatically checking your code for syntax errors while you type it out.
If you have some code you want to test inside a larger project, it's a hassle sometimes to isolate it for testing. Whereas a good Python interpreter such as IPython, makes it easy to test a small bit of code and see how the language behaves and paste it into a file.
Python also interfaces very well with existing C/C++ code through many numerous ways. That way if a new whizbang Python module you created is really slow, then you can soup it up in C/C++ then wrap it up with Python through ctypes, Boost::Python, or SWIG.
And most of all, Python comes with a great standard library that has a lot of stuff figured out for you. It's just a matter of putting the pieces altogether! It has a great community behind it, so if it's not in the standard library, there's a good chance someone out there has solved the problem (PyGame, Numpy, SciPy, Pyserial, PyWin, etc.) for you. You can just google it, grab it and plop the code right into your program...away you go!
I've heard these complaints before about C++, but the fact is, programming in any language with which you are unfamiliar is time consuming.
A good C++ programmer can probably crank out the app much faster than an okay Python programmer and visa versa.
I think C++ often gets a bad reputation because it allows you get much lower level - pointers, memory management, etc, and if you aren't used to thinking about such things, it can take a bit of time. If you are used to working in that environment, it can become second nature.
Unless choice of language is something imposed upon you by your company, team, client, etc. I usually recommend that folks go with the language they are most comfortable with OR most interested in learning more about. If speed is the issue you are concerned with, look at the learning curve for each language and your past experience. C++ tends to have a higher learning curve, but that too depends on the person.
Kindof a non-answer I know.
Python has some big advantages over programming languages like C++. I myself have programmed a lot with C++, C and other programming languages. Lately I am also programming in Python and I got to like it very much!
You can have a quick start with Python. Since it is rather simple to learn (at least with some programming experience and enough abstract thinking), you can have fast successes. Also the script-like behaviour makes starting easy and it is also possible, to quickly test some things in the integrated shell. This can also be good for debugging.
The whole language is packed with powerful features and it has a good and rather complete set of libraries.
There was the argument that with the "right library" you can develop as quickly with C++ as with Python. This might (partly) be, but I myself have never experienced it, because such libraries are rare. I had also a big library at hand, but still lacked many valuable features in C++. The so called "standard template library" STL makes things even worse in my opinion. It is a really powerful library. But it is also that complex, that it adds the complexity of an additional programming language to C++. I really disliked it and in a company I worked in, much worktime was lost, because the compiler was not able to give useful error-output in case of errors in the STL.
Python is different. Instead of putting the "speed of the programm" on the throne -- sacrificing all else (as C++ and especially the STL does) -- it puts "speed of development" first. The language gives you a powerful toolkit and it is accompanied by a huge library. When you need speed, you can also implement time critical things in C or C++ and call it from Python.
There is also at least one big online Game implemented in Python.
It's time consuming because in C++ you have to deal with more low-level tasks.
In Python you are free to focus on the development of the actual game instead of dealing with memory management etc.
there are many things that make c++ longer to develop in. Its lower level, has pointers, different libraries for different systems, the type system, and there are others I am sure I am missing.
It takes about the same amount of time to write the same code in pretty much all of the high level languages. The win is that in certain languages it is easier to use other peoples code. In a lot of Python/Ruby/Perl apps, you write 10% of the code and import libraries to do the other 90%. That is harder in C/C++ since the libraries have different interfaces and other incompatibilities.
C++ vs Python is a pretty personal choice. Personally I feel I lose more time with not having the C/Java class system (more run time errors/debugging time, don't have anywhere near as good auto completion, need to do more documentation and optimization) than I gain (not having to write interfaces/stub function and being able to worry less about memory managment). Other people feel the exact opposite.
In the end it probably depends on the type of game. If your processor intensive go to C++ (maybe with a scripting language if it makes sense). Otherwise use whatever language you prefer
I'd focus more on choosing a framework to build your game on than trying to pick a language. Unless the goal is to learn how games work inside and out, you're going to want to use a framework. Try out a couple, and pick the one that meets your requirements and feels nice to you.
Once you've picked the framework, the language choice becomes easy - use the language for which the framework is written.
There are many options for game frameworks in C++ - pygame works for python. There are many that work with other languages/tools as well (including .NET, Lua, etc.)
Short Answer
Yes python is faster in terms of development time. There are many case studies in real life that show this. However, you don't want to do a 3d graphics engine in Python.
Do you have any programming experience at all? If not, I would start with Python which is easier to learn, even if it is not a better tool for game development. If you decide you want to program games for living, you'll probably need to switch to C++ at some point.
Note that SDL is currently slow, because it basically doesn't use hardware acceleration.
SFML is an alternative of choice, and is available in Python too.
Why limit yourself to those two options? With C# or Java you get access to a huge collection of useful libraries plus garbage collection and (in the case of C#) JIT compiling.
Furthermore, you're saying that you're looking to do game development, but from your task description it sounds like you're also looking at coding your own engine. Is that part of the exercise? Otherwise you should definitely take a look at the available Indie engines out there - lots are cheap of not free and open source.
Needless to say, working from an existing engine is definitely faster than going from scratch :)
Some people would argue that development time is slower in C++ when compared to Python.
Wouldn't it be the case that the time you saved in developing an application (or game) in python is the time you gonna use in improving performance after its developed? and in the later part when you have least options left?
It largely depends upon the purpose for which you are going to develop the application.
If you are thinking for an enterprise application in which case it is going to be hit by millions (web-app) or an application with focus on low-footprint, faster loading into memory, faster execution, then your choice is C++.
If you are projecting your application for not being use at this level, surely Python is the choice to go for.
Maintainability is considerable, but disciplined code can overcome this.
Largely depends upon long term projections. On how serious and critical the application is going to be.