Which programming language did you choose and why?

Python, unless performance matters.

 

Just as context, Bloodlines embedded python in the HalfLife 2 engine and used it to drive almost all game logic through python callbacks to the game engine.

Here is a simple guide how to do something like that:
http://docs.python.org/dev/py3k/extending/embedding.html

The hooks bloodlines used specifically was that the dialog could execute 2 python lines pre and pos dialog line, and that the maps have a loading entity that is run on map load (initialization) and some other entities for the icons and world objects.

Everything else, inventory handling, pathfinding, combat behavior, cutscenes etc was run in the game engine.
Game ran fine (ok not really, but the script engine was not the bottleneck. Game logic almost never is).

 

Civilization IV (one of my all-time favorite games) is a C++ / Python design too. When I said "unless performance matters" I meant a pure Python project. One can use it to script parts of the game which aren't performance critical of course and write the rest in C++, then everything is possible. However, that would be massive over-engineering for a one man hobby project IMO.

Pure Python is efficient enough for old school 2D RPGs on modern hardware.

 

Has there been an example of a Fallout-complexity 2D game running smoothly while written entirely in Python? Heck... a Diablo-complexity game.

 

There are some roguelikes.

 

Roguelikes are stepI mean a game with an actual renderer that has to draw things in realtime, in addition to performing some other "living world" stuff in realtime, and maintain an acceptable framerate.

 

Who wants to do real-time games? We have a billion dollar industry shitting out one action game after the other. If there is something the world doesn't need it's another Diablo clone. And the industry guys will do a way better job at making those anyway.
If you want to do a 2D, turn-based RPG like a true Codex bro efficiency should no longer matter. For real-time action shit Python could be problematic indeed. However, if you are at SNES/Dungeon Master level (that's what I meant with old school) there shouldn't be any problems with real-time gameplay either.

 

I think you're misinterpreting "real-time" here. Unless you're game is a picture that you stare at, something is going to have to happen in real time.
Personally I think you'd be able to render simplistic tile based graphics in Python; this is just a hunch though.

 

Most turn-based games are realtime on engine level, because you have to scroll around while it redraws the environment at a decent framerate and handles the UI stuff/animations/etc.

Roguelikes don't have to do that. They can just work at 1-frame-per-5-minutes should you choose to take that long to make the next move.

Python may work in non-performance-intensive parts of a game engine... for scripting or such.

 

Sigh programming language fanboys are the worst kind of fanboys. It's literally like running into two handymen arguing about whether a hammer or screwdriver is the better tool. they look like faggots

edit: not that everybody here is doing this. some people actually try to point out the meaningful differences between the hammer and screwdriver. Namely you use hammers for nails and screwdrivers for screws. Yay for analogies

 

You don't need to make everything in Python just like you don't have to make everything in C++, just get an engine.
A quick google search shows Panda3D and FIFE which you can use both with Python or C++.

"Panda3D is a 3D engine: a library of subroutines for 3D rendering and game development. The library is C++ with a set of Python bindings. Game development with Panda3D usually consists of writing a Python or C++ program that controls the Panda3D library."
"FIFE stands for Flexible Isometric Free Engine and is a cross platform game creation framework. It provides you with the ability to create a game using Python interfaces. This means you need to have little to no knowledge of C++ to make a game! Don't want to use Python? That's okay because FIFE also comes as a DLL or static library so you can also use C++!"

 

Learn anything. One man army can write only that much code. At the end of the day what will matter is whether you've finished your project or not. Working code is better than perfect code. People who rant about language X being better/faster than language Y and most often than not completely clueless. If you end up having a code that needs to be optimized, you'll just start a profiler, find bottlenecks and fix them. You'll have plenty of them regardless of the language you're using. By the time you get to the point where language penalties on performance matter, you'll either be ten years older (and wiser) or on your n-th project and the question you're asking today won't matter at all. Just go and write code. There's no language that can beat that!

 

Someone give me an actual example of BOOST being a reason for your programs being slowed down or their size greatly increased. Be warned, I will deduct points if you simply don't know how to use BOOST.

 

One real-world example?
boost::regex was much too slow for compiling complex expressions (procedurally generated by or-ing a lot of different potential matches). pcre did the job perfectly. Matching time was improved too but not as dramatically.

And I wouldn't write a non-trivial parser with boost::spirit either...

Edit: And boost all-headers (I know, I know, not for everything ) approach is nice for small projects but it hits the compile times with the template instantiations and it makes huge debug object code, which slows link. A nice C middleware with a few functions to link and lean includes are a boon. Of course, you can wrap anything in your own lib.
That's why I love C++, sheer versatility.

 

Of course it does inflate the EXE. Templates are type-safe and generate extra code for each type you use with your containers, smart pointers, etc. Some are even documented as imposing significant size overhead (format for example does). Dependency on RTTI? More code. Dependency on exceptions? Extra code. Extra code = icache miss = stalls = slower code. If one cares that is.

 

Right but lot of PC programmers, even in videogames, don't know or care about this. When you put consoles in the equation, it becomes critical.
When you're making SPU code, room is very sparse.

EDIT: With lots of good care and love, you don't lose room because of templated containers, because COMDAT folding manages to fold the implementations and the variant code is inlined anyway.

 

You don't really have room for BOOST in your SPU code. As you most likely know it's a completely different breed of processor and common techniques can't be used. Writing for CELL is a twofold problem too, IMO. 1) it's hard for anyone to grasp and there's little to no valuable data available, 2) all CPUs will become heterogeneous the moment tools mature and are able to help a little bit more with the problem than they are now. Speaking of multi/many-core: anything in BOOST that deals with threading imposes pretty significant size bloat due to aligning. This can't be sugarcoated by BOOST as it requires some advanced knowledge about things like cache sizes, cache hierarchy, etc.

 

The problem is that for engineering purpose, you share common C++ code both in SPU and PPU code. So you often accidentally pull lots of stuff. Bloat and tears ensue
By the way I don't know anything about concurrency primitives in boost, I just use OS/SDK stuff, but nobody ever tried to convince me to give it a try.

 

SN System's compiler is so poor I wouldn't use C++ and stick to C for the common code. Also when it comes to BOOST - exceptions are super important and consoles don't support them at all or support is incomplete. STL is OK for console development (especially with console-friendly implementations that exist) but BOOST simply isn't.

 

We don't even use a lot of STL on our games because:
* std::allocator design makes it hard to use stack space or tls
* lots of std::sort instantiations bloat your code madly (something like 60KB on PS3 per instantiations IIRC)
* unordered containers were not production ready and good hash containers are critical
Thus we slowly replaced 99% of out STL code by in-house code during the years. It helps prototyping rapidly though. And you can still find a few find<T*> or lower_bound<T*>.
And I totally agree boost is not ok for console development, but it often find its way in a big C++ project with many programmers. Luckily the fact that the 360 toolchain explicitly forbids exceptions gave a huge argument for ditching most of it. But "passive" stuff boost::typeof, the preprocessor iterator or all the nifty type traits are not really a problem.

 

!2 == false >true
2 == false >false
2 == true >false


http://blog.regehr.org/archives/721

 

I am an academic by profession and do not use programming for development of commercial softwares. I started with C and C++, continued with Python and now use a Cython for speed and convenience. Python as a huge advantage in being easy as fuck and intuitive as sin.

 

Is there any advantage to regular Python over Cython? Seems like the performance advantages are very good.

 

If you do Python and you're interested in performance, you're probably wrong.