Related
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++
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.
I'm trying to write a game and implement scripting so that later on in development I won't have to recompile everything when I want to change numbers.
My problem is that I don't know how scripts should interface with the game. The scripting language I'm using is angelscript.
Right now, I have a state: the intro state, which I'm using as a test for most of the modules in my game "engine" (it's more like a loose collection of classes). It will load and draw a picture and draw text, and use scripting to update itself, and maybe switch to a dummy state afterwards to test the state manager.
While writing it, I realized that using the script to do most of the updating would require that I register most of my game engine's modules with the script, and pretty much move the bulk of the code to the scripting language. Personally, I'd rather have the C++ portion doing the majority of the work, and have the scripting language come up with the numbers to use in the formulas/drawing/whatever.
However, if I'm right, doing it that way would entail lots of different update modules for the majority of the things in the game that need to be updated, and requiring that they all be loaded in, and that the C++ code would have to run each update function individually.
Or, there's a way to achieve script and program interoperability that I'm overlooking. Either way, could someone help me figure out what the best way to get scripting implemented into my game is?
There's no correct answer to such a large question really. You do it the same way you would do engine/game logic separation in C++. Define an API that the script can call that allows it whatever it is you want it to do. Register functions in that API with the script, and use the API in angelscript. What that API should be depends entirely on your needs and what kind of power you want to give the scripter.
If you want AngelCode (or any other scripting approach of your choice) to just "come up with some numbers", hey, use it that way -- e.g., in AngelCode, compile the scripts by exposing to them a single C++ function of yours, say "void ProvideNumberFor(string reason, number value)", and the scripts will be responsible for calling that function as many times as needed to "provide the numbers", and nothing more.
If you look at real examples like Garry's mod or games written with UnrealScript you'll find that quite a bit of logic in modern games is implemented in the scripts. C/C++ code is best for "static" and bottleneck-prone parts of the engine, like the renderer, physics engine, low-level networking, etc. Scripts are best for content (i.e., game logic).
Aside: The best game-scripting language IMHO is Lua. It provides easy intregration with C/C++, is very well-documented, and will be familiar to users of Javascript.
I've used Lua for exactly this purpose, and it does a great job. Look at all the games programmed using Lua. Also, it's blazingly fast.
EDIT: I didn't read the question fully...sorry. This is my real answer ;)
If you're familiar with Qt4/Javscript you can always use QtScript http://qt.nokia.com/doc/4.5/qtscript.html.
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).
I am considering the possibility of designing an application that would allow people to develop C++ code graphically. I was amazed when I discovered Scratch (see site and tutorial videos).
I believe most of C++ can be represented graphically, with the exceptions of preprocessor instructions and possibly function pointers.
What C++ features do you think could be (or not be) represented by graphical items?
What would be the pros and cons of such an application ? How much simpler would it be than "plain" C++?
RECAP and MORE:
Pros:
intuitive
simple for small applications
helps avoid typos
Cons:
may become unreadable for large (medium?) - sized applications
manual coding is faster for experienced programmers
C++ is too complicated a language for such an approach
Considering that we -at my work- already have quite a bit of existing C++ code, I am not looking for a completely new way of programming. I am considering an alternate way of programming that is fully compatible with legacy code. Some kind of "viral language" that people would use for new code and, hopefully, would eventually use to replace existing code as well (where it could be useful).
How do you feel towards this viral approach?
When it comes to manual vs graphical programming, I tend to agree with your answers. This is why, ideally, I'll find a way to let the user always choose between typing and graphical programming. A line-by-line parser (+partial interpreter) might be able to convert typed code into graphical design. It is possible. Let's all cross our fingers.
Are there caveats to providing both typing and graphical programming capabilities that I should think about and analyze carefully?
I have already worked on template classes (and more generally type-level C++) and their graphical representation.
See there for an example of graphical representation of template classes. Boxes represent classes or class templates. First top node is the class itself, the next ones (if any) are typedef instructions inside the class. Bottom nodes are template arguments. Edges, of course, connect classes to template arguments for instantiations.
I already have a prototype for working on such type-level diagrams.
If you feel this way of representing template classes is plain wrong, don't hesitate to say so and why!
Much as I like Scratch, it is still much quicker for an experienced programmer to write code using a text editor than it is to drag blocks around, This has been proved time and again with any number of graphical programming environments.
Writing code is the easiest part of a developers day. I don't think we need more help with that. Reading, understanding, maintaining, comparing, annotating, documenting, and validating is where - despite a gargantuan amount of tools and frameworks - we still are lacking.
To dissect your pros:
Intuitive and simple for small applications - replace that with "misleading". It makes it look simple, but it isn't: As long as it is simple, VB.NET is simpler. When it gets complicated, visual design would get in the way.
Help avoid typos - that's what a good style, consistency and last not least intellisense are for. The things you need anyway when things aren't simple anymore.
Wrong level
You are thinking on the wrong level: C++ statements are not reusable, robust components, they are more like a big bag of gears that need to be put together correctly. C++ with it's complexity and exceptions (to rules) isn't even particulary suited.
If you want to make things easy, you need reusable components at a much higher level. Even if you have these, plugging them together is not simple. Despite years of struggle, and many attempts in many environments, this sometimes works and often fails.
Viral - You are correct IMO about that requriement: allow incremental adoption. This is closely related to switching smoothly between source code and visual representation, which in turn probably means you must be able to generate the visual representation from modified source code.
IDE Support - here's where most language-centered approaches go astray. A modern IDE is more than just a text editor and a compiler. What about debugging your graph - with breakpoints, data inspection etc? Will profilers, leak detectors etc. highlight nodes in your graph? Will source control give me a Visual Diff of yesterday's graph vs. today's?
Maybe you are on to something, despite all my "no"s: a better way to visualize code, a way to put different filters on it so that I see just what I need to see.
The early versions of C++ were originally written so that they compiled to C, then the C was compiled as normal.
What it sounds like you are describing is a graphical language that is compiled to C++, which will then be compiled as normal.
So really you are not creating a graphical C++, you are creating a new language that happens to be graphical. Nothing wrong with that, but don't let C++ restrict what you do, because eventually you may want to compile the graphical language straight to machine code, or even to something like CIL, Java ByteCode, or whatever else tickles your fancy.
Other graphical languages you may want to check out are LabVIEW, and more generally the category of visual programming languages.
Good luck in your efforts.
The complexity of a nontrivial program is usually too high to be represented with graphical symbols, which are low in their information content. Unless your approach is markedly different in some way, I am skeptical that this would be of value based on past efforts.
So, practically speaking, his will be useful only for instructional purposes and very simple programs. But that would still be a great target market for a product like this. sometimes people have trouble grasping the fundamentals, and a visual model might be just the thing to help things click.
Interesting idea. I doubt I'd use it though. I tend to prefer coding in a flat text editor, not even an IDE, and for tough problems I prefer a pad of paper. Most of the really experienced programmers I know work this way, Maybe it's because we grew up in a different environment, but I think it's also because of the way we think about programming. As you get more experience, you start seeing the code in your head more clearly than any GUI tool will show it to you.
As for your question, I'd nominate templates as one of the harder / more interesting sort of thing to try to represent well. They are ubiquitous and carry information that you won't have access to as you are designing your tool. Getting that to the user in a useful way should pose an interesting challenge.
What C++ features do you think could be [...] represented by graphical items?
Object Oriented Design. Hence classes, inheritance, polymorphism, mutability, const-ness etc. And, templates.
What would be the pros and cons of such an application?
It may be easier for beginners to start writing programs. For the experienced, it may be get rid of the boring parts of programming.
Think of any other code generator. They create a framework for you to write the more involved portion(s). They also lead to bloated-code (think of any WYSIWYG HTML editor).
The biggest challenge, as I see it, is that any such UI necessarily hinders the user's imagination.
How much simpler would it be than "plain" c++ ?
It can be a real pain, when you wade through truckloads of errors which is typical of code generators.
Further, since a lot of code is generated, you have no idea of what is going on -- debugging becomes difficult.
Also, for the experienced there may be some irritation to find that the generated code is not per their preferred coding style.
I prefer hot-keys instead graphical menus and buttons.
And I think same thing will happen with graphical development tool. Many peoples will prefer manual codding.
But, source code visualizer - should be nice thing.
I like the idea, but I suspect there comes a point where things get far too complicated to be represented graphically.
However, given recent experience at work; it would be useful to give such a graphical interface to a non-techie person to use to create basic drag-and-drop programs, leaving myself free to get on with some "proper" programming ;-) If it can do the job of allowing somebody non-skilled to build something functional it can be a very good thing (even if programming logic escapes them)
There comes a point in such a system where it becomes easier to define what you want to do using literal C++ code, rather than have a user interface getting in the way; it can get frustrating to the sessioned programmer knowing the precise code that needs to be written but then only being limited to the design GUI. I'm specifically thinking about a more common application, such as html editors/designers in which they allow newbies to build their websites without knowing any html at all.
It would be interesting to see how such a system would handle the dynamic allocation of memory, and the different states of a program as time progressed; I suspect that there are some very basic programming concepts that may be difficult to represent graphically.. Polymorphism..? Virtual Classes, LinkList, Stacks/Circular Queues. I wonder for a moment how you would explain an image compression algorithm (such as jpg) successfully too without the help of a gigantic display screen.
I also wonder if such a system would even go to such a low level, and whether you would be dealing with abstracted concepts and the compiler would be working out the best way to do something.
I've been working on a new model-driven software development paradigm named ABSE (http://www.abse.info) that supports end-user programming: It's a template-based system that can be complemented with transformation code. I also have an IDE (named AtomWeaver) implementing ABSE that is in pre-alpha stage right now.
With AtomWeaver, as an expert/architect, you build your knowledge Templates, and then the developers (or end-users if you make your meta-models simpler) can just "assemble" systems by building blocks, and then filling template parameters in form-style editors.
At the end, pressing the "Generate" button will create the final system as specified by the architect/expert.
I'm surprised you think function pointers would be a particular problem. How about anything at all to do with pointers?
A programming language can be represented by a hierarchy of nodes - that's exactly what the compiler turns it into. It is very strange that the UI for editing programs is still a sequence of characters that get parsed, because the degrees of freedom in the editor is way larger than the available set of allowed choices. But intellisense helps to reduce this problem a lot.
C++ would be a strange choice to base such a system on.
I think the major problem of this kind of IDEs are that the code generated becomes unmantainable easily.
This happened to Delphi. It's a really nice tool to develop some kind of applications, however, when we start adding complex relationships between the components, start adding Design Patterns, etc. the code grows to an unmantainable size.
I believe it's also because graphical tools don't apply the concept of MVC (or if they do, it's only in the way that the IDE understands).
It can be really helpful for prototypes and very small applications that don't tend to grow, otherwise it can become a mess for the developer(s)