Nowadays the trend in game development is to use the component entity system which works really nicely with languages like C which don't actively enforce rigid object orientation.
At work we tend to write fairly typical C code using similar patterns to Gtk+ for our small amount of object orientation but then we attach components to a single type akin to Unity's GameObject. We do however use the GNU C++ compiler so we can access some of the really useful C++ functionality like std::string, std::vector, smart pointers etc. We also use external C++ and C libraries so using a C++ compiler was the most compatible choice.
Also, it seems easier to interface with C code from a Java or Objective-C shim layer (for mobile devices), than C++.
My personal favorite feature of C over C++ is that if you define the struct in the .c file and just have a forward declaration of the struct and corresponding functions in the .h file, it is much more encapsulated than even a class with everything private in C++ since other developers can't even see the data and you have complete control over any aspect of the data being exposed. This can't seem to be done so well in C++ without rewrapping all the functions because the class contains the functions so has to be exposed. Thus the pimpl idiom which I find a tad messy and convoluted.
Ah good point, it is worth mentioning that Emscripten provides SDL 1.x (and soon SDL 2.0). However, since the emscripten version of the SDL API has been tweaked to run in a mobile browser (i.e touch events) and is already 3D accelerated, it is likely to stick around for many years to come (and will almost certainly still outlive commercial proprietary products like Unity).
Whao, that's sounds amazing, i think it's the time to learn SDL. Thank you!
Luckily SDL also has some fantastic tutorials written by GameDev.net's own LazyFoo (http://lazyfoo.net/SDL_tutorials/). These should help you get started. For 2D games it covers pretty much everything.
As an added bonus, when compiled with Emscripten, your SDL games will actually be hardware accelerated because they use the web browsers HTML5 canvas underneath.
FlasCC unfortunately still targets the unportable proprietary Flash stage system.
My software always uses either SDL or Glut and OpenGL so it has been very easy to put out a web build. I highly recommend these technologies if you want to keep with C++ but also target the web (as well as every other platform under the sun ;)
We use the Microsoft C++ compiler in much the same way as GCC on Windows. The following is a few examples from our Makefiles if it helps (personally I find the documentation for commandline MSVC usage to be really lacking!).
Take comfort in the knowledge that SDL is already written (and open-source) for you to always use rather than having to rewrite something similar yourself.
Also, using SDL with C and C++ is easy. Just like using .NET (C#) is easy whereas if you look through the source code of Mono (or shared source (rotar) versions of Microsoft's .NET) it is incredibly complex.
I tried porting Microsoft's .NET to a modern version of FreeBSD (it originally was created for Windows XP and FreeBSD 4.7). I got as far as the PAL abstraction layer before I started to get the shakes. Now I am writing games until I recover from the experience haha.
A website with pictures, an embedded video and downloadable 32bit Windows exes or perhaps an Android APK* of the game is usually your best bet. This also has the added benefit of letting your viewers get a local copy of your game to pass around so not having to worry about internet streaming which is quite a benefit (whereas many web games need internet or a small local html server (like mongoosehttpd) to be provided). Or even worse, they need horrible web plugins**!
With Python, you might want to use a packaging system since Python isn't very common on Windows machines for a typical user. If you can modify your install of python to be portable, then you might have some luck creating a self extracting .exe using WinRAR.
* Android is the most common tablet OS (rivaling even that of desktop systems) and seeing as you are not trying to sell your showcase game (at this point in time) your viewers can sideload it without the faff of developer certificates from something like iOS or Metro.
I find one thing that helps in a language is that cleanup is automatic but also deterministic (i.e in C++). This way, it is possible to send a message as soon as a local object is destroyed. There are many ways round this when using a garbage collected language but I prefer not having to think about this issue.
Posted by Karsten_
on 12 September 2013 - 09:02 AM
If it is necessary, don't be afraid of creating your own tools. We have an internal tile editor but it certainly isn't in the same state as Tiled and is a long way off commercial tools. It is however more fit for purpose for our game than any of the others we had found. In other words, it would take longer to understand how the plugin system works for a 3rd party tool than it did to just knock together our own.
Here are a few of our tools. You can see how rough they are ;)
(One day we do aim to clean them up to release to allow modding for the actual game but polishing is pretty time consuming lol)
This map editor isn't actually tiling. Our days or tiling map editors ended once we realized none of us were very good at pixel art ;)
Both were coded in C++ and wxWidgets and it works on all our development platforms (something proprietary tools fail to do). All in all, it probably took about a day or two for each one but features were added as we needed them so I am not sure of total coding hours. Well worth it though because now we aren't relying on companies owning tools like Unity or Spine to stay in business or to keep up support of a feature
Posted by Karsten_
on 10 September 2013 - 08:57 AM
The term "engine" is perhaps a bit overused in game development. Typically it is just a collection of other separate libraries (i.e OpenGL, glm, OpenAL, SDL, libpng etc...) with a bit of glue code to hold it all together as a framework (often including extra things like a scripting layer, serialization, etc...).
Posted by Karsten_
on 08 September 2013 - 12:10 PM
A typical programmer will certainly need to know a few languages so it is always worth improving your knowledge of a language. I guess just try to avoid falling into the trap of always flittering between different languages and never specializing in any.
I only ever choose to use C++ (and it has paid off since I like to think I am pretty good at it now ;). However I still need to know C# so I can understand example algorithms that are written using it. I also need to know C# so I can implement glue code between Microsoft technologies.
For example, I also needed to know enough Java so I could kickstart my native C++ game on Android. I also needed to know enough Objective-C to kickstart the same game on iOS.
Programming languages are like cars. Once they crash and burn, you need to be able to move onto something else in order to get to your destination.
Posted by Karsten_
on 06 September 2013 - 02:57 AM
Since C++ is on a much lower level Socket programming makes use of sockets implemented for each Operating System
Although C++ makes it easier than Java or .NET to work directly with low level C code, generally there is no reason that you should.
However as Khatharr mentioned, the sockets API on most platforms is very similar (Mainly because Winsock was designed based on BSD sockets a long time ago).
This combined with the fact that using the sockets API directly isn't that difficult (i.e not too much boilerplate code required to get quick results) so I probably suggest wrapping your own socket library. I could give you a link to loads of premade socket libraries but personally I dislike using other peoples wrappers for this kind of thing.
Below is a list of simple examples. I use these as a basis for my own netcode.