• 0

Game Development Language Choices

Asked by Brian Lewis,

 Share

Question

Apprentice

Brian Lewis

Posted
Posted

Hey everyone. I'm a web developer with experience in PHP, MySQL, Ruby, JavaScript to name a few and have reached a point in time where I have plenty of free time to branch out into things I *really* want to do - specifically game development. I have a fantastic artist wife that can handle any artistic side of the project, so that leaves me to handle the development side of things. Now, I'm not going crazy saying that I want to be a one man team making AAA games... however, I do want to put some basic indie titles together (think Cave Story, Fez, Braid) eventually with a few friends (I know a few programmers that would probably jump on the opportunity - though their skills are spread out over a wide spectrum of languages/fields).

So yeah, I'm thinking 2d, maybe some isometric 2.5d stuff. Side scrolling, top down, NES style games to start.

What language should I look into learning? I've heard conflicting opinions on each option.

C# - Most will tell me to jump straight into C# and work with XNA, but that leaves mutli-platform out of the question. I'm not too concerned about multi-platform, but I think it's a good option to leave open.

Java - So, that would lead me towards Java. I'm not a fan of Java, as a user. VM always seemed bulky and slow, with tons of vulnerabilities.

C++ - C++ might be a little bit too much of an undertaking, but I can see the benefit of learning proper memory management out of the gate. However, it might add too much time to development where, say, C# has XNA that handles a lot of the work out of the box.

Python - I see Python as an alternative, but I'm not sure I want to venture too far off the beaten path. Python is a very elegant language that I could pick up rather quickly, but the games I have seen developed in Python leave me wondering how capable it -really- is.

Would love to see some opinions here. Hopefully I didn't come off as too optimistic. :)

Link to comment
https://www.neowin.net/forum/topic/1110503-game-development-language-choices/
Share on other sites

54 answers to this question

Recommended Posts

  • 0
Grand Master

Andre S. Veteran

Posted
  • Veteran
Posted
What language should I look into learning? I've heard conflicting opinions on each option.

C# - Most will tell me to jump straight into C# and work with XNA, but that leaves mutli-platform out of the question. I'm not too concerned about multi-platform, but I think it's a good option to leave open.

Java - So, that would lead me towards Java. I'm not a fan of Java, as a user. VM always seemed bulky and slow, with tons of vulnerabilities.

C++ - C++ might be a little bit too much of an undertaking, but I can see the benefit of learning proper memory management out of the gate. However, it might add too much time to development where, say, C# has XNA that handles a lot of the work out of the box.

Python - I see Python as an alternative, but I'm not sure I want to venture too far off the beaten path. Python is a very elegant language that I could pick up rather quickly, but the games I have seen developed in Python leave me wondering how capable it -really- is.

C#: XNA has a working open-source and multi-platform implementation, MonoGame. It has already been used in several commercial titles. This makes XNA an excellent choice not only for the awesome language, tooling, documentation and API, but also to develop your game for all existing mobile and desktop platforms. At a much higher level, you also have Unity, which is widely used in the game industry and is also as multi-platform as engines go. If you want to learn C#, the best book I know of is a free one: The Yellow Book. Recently updated for C# 5 as well!

Java: the VM is anything but slow: the best implementations (Hotspot) can optimize code beyond what the best optimizing C++ compilers can do. However, the Java language is kinda boring and I don't know of any good game APIs for it. If you want to target the Java platform I suggest using the Scala language; it's quickly gaining ground as a better language for developing Java-based applications.

C++: depends what you want to do. If you want to program games, bad choice. The multitude of pitfalls, slow compilation and poor error reporting will just get in your way; performance-wise, there's no way you'll beat what the .NET or Java VMs offer you unless you really know what you're doing and in specific circumstances. Most likely, your game will simply be less portable, less performant and a lot less feature-rich because you'll spend most of your time fighting the tools and language rules. Yes, C++ is widely used by the big game studios: that's because they have the specific need of extracting maximum performance out of closed and unorthodox platforms. You don't, so you don't need C++.

Python: great for learning and experimentation, PyGame is an excellent game development library. This one IS slow however, but if 2D NES-style games are your objective you shouldn't run into performance problems anytime soon.

  • 0
Mentor

Veiva

Posted
Posted

Hands down I'd recommend C#. You may be worried that there's only XNA, but that's not the case. There's a few libraries out there, such as OpenTK and MonoGame, that alleviate the problem of cross-platform compatibility. Personally, I wrote my own game library/framework based on the C-based library Allegro 5.

The speed is nothing to scoff at, either. Obviously it's not as fast as C++ in some cases, but C# makes development so much faster because of the lack of the quirks present in C++. So regardless of if you're developing a small 2D platformer or a complete 3D engine, I do think that C# is the wiser choice in this day and age. The features and richness are just unmatched by C++, in my opinion.

On a side note, I'm actively developing a video game in C#. It has some pretty nifty features that would be absolutely annoying or impossible to implement nicely in C++. Hence my choice. Most of the time spent is not in C#-land but in the GPU (although it may not look like it, it's pretty GPU demanding because of the features I use to sustain graphics quality), if you want to know from personal experience. This is why I believe that C# is suited for games development, especially if you're not designing something on the scale of Unreal 4.

It looked like this a few days ago:

rOFky.png

  • 0
Grand Master

Andre S. Veteran

Posted
  • Veteran
Posted

XNA is no longer maintained, though there are open source alternatives.

Has there been any announcement to that effect? Microsoft hasn't announced any new version of XNA, but they still support the platform. My optimist theory is they will announce something around the same time as Xbox Next. Worst case scenario, they never update it again and we all switch to MonoGame, which anyway is more-crossplatform, Xbox excepted.
  • 0
Mentor

Lant

Posted
Posted

If you plan on writing a game in C#, you may as well start with C#. There is little point picking up the intricacies of a language that you aren't going to use.

For instance, you are going to learn a lot about deciphering compiler error messages and things like template metaprogramming with C++. Neither of which you will need for C# development.

On the otherhand you could be learning about things that are much more important to C# such as reflection, the generics system (which is very different to templates) and other ideas.

  • 0
Mentor

seethru

Posted
Posted

I think this really depends on the platforms you want to target, then decide on the language.

Yes, C++ is definitely the best one to learn if you want to write AAA games, or attempt to get a game on XBLA. However, take a look at some of the big names in indie games right now. They got their start in, and still make games in, AS3. I know there's a lot of hate out there for Flash but AS3 is an amazing language and kicks the crap out of anything else that is web based.

Just my two cents from inside the industry.

  • threetonesun
  • Like 1
  • 0
Grand Master

firey

Posted
Posted

I personally am writing a C#/XNA Game in my free time, it's nothing crazy yet, still doing the basic interface. I've been re-writing standard form controls and the whole idea of screens/forms to make my job easier. I am using purely the base includes (outside of say IO, .Net.Sockets) so doing everything inside the XNA Framework. But I've got it to the point where I can do things like:

Button btnLogin = new Button(1);

btnLogin.Text = "Login";

btnLogin.Click += new Control.ClickEventArgs(btnLogin_Click);

AddControl(btnLogin);

I don't have it as fancy as the stock windows forms, but I also don't want to use them. It's a fun challenge but it makes doing things way quicker in some ways.

  • 0
Collaborator

Pong

Posted
Posted

The number of people blindly recommending C++ is frighting. If you're not going to be making AAA titles, and you don't require massive performance, then there is almost no reason what so ever to learn and use C++.

Performance wise, Java and C# are going to be close, and unless your pushing the hardware to its limits (which you shouldn't be with a non-3D game), then you will have no trouble with either of these languages. C# probably has the advantage here when dealing with game libraries and engines, although I don't think Java is a bad choice either.

Python is easiest to learn, and with things like pyGame, you can start making games very quickly.

Look at the languages, look at the tools available and make a choice based on that.

  • 0
Grand Master

Andre S. Veteran

Posted
  • Veteran
Posted

I wouldn't recommend XNA, not since they got stuck in 2004 with DX9c-only support. :rolleyes:

I will however say that C# with SlimDX or SharpDX are very good places to start.

XNA and SharpDX have totally different goals. The purpose of XNA is to provide a complete game development framework including asset management, networking, deployment, etc., for students and hobbyists, and abstract away the hardware differences between platforms as much as possible. The purpose of SharpDX is only to provide a fast managed wrapper around DirectX: it's every bit as complex and powerful as the original API, and yet it doesn't cover half the scope of what XNA does.

So, they different tools serving different purposes. That XNA uses Direct3D 9 under the cover is not much of an issue to its target users. Plus that will all change as the open-source MonoGame implementation will use SharpDX to support Windows 8.

  • 0
Rising Star

@Leo

Posted
Posted

XNA and SharpDX have totally different goals. The purpose of XNA is to provide a complete game development framework including asset management, networking, deployment, etc., for students and hobbyists, and abstract away the hardware differences between platforms as much as possible. The purpose of SharpDX is only to provide a fast managed wrapper around DirectX: it's every bit as complex and powerful as the original API, and yet it doesn't cover half the scope of what XNA does.

So, they different tools serving different purposes. That XNA uses Direct3D 9 under the cover is not much of an issue to its target users. Plus that will all change as the open-source MonoGame implementation will use SharpDX to support Windows 8.

What networking does XNA offer beside Game for Windows Live, which was a short-lived cancer and thankfully, has almost completely passed away?

Yes, XNA simplifies things a little. I used it for my degree project and it was nice. But other than the content pipelines, it really has little purpose. If you want to focus on content creation, use a made engine such as Unity or UDK. If you wish to learn engine development, invest the [little] extra time and learn a more encompassing framework. In the long run, the so called advantages of XNA are minor and unimportant.

I used XNA because when I was developing my project, I wanted to use C# and there were only XNA and Managed DX, and the latter was a mess.

This topic is now closed to further replies.
 Share
Go to question listing

  • Posts

    • A 13 billion year old secret about our Universe's origin was revealed

      By hellowalkman · Posted

      A 13 billion year old secret about our Universe's origin was revealed by Sayan Sen Image by Pascal Küffer via Pexels Researchers at the Max-Planck-Institut für Kernphysik (MPIK) in Heidelberg had recreated a key chemical reaction from the early universe, producing results that could change scientists' understanding of how the first stars formed. The study focused on the helium hydride ion (HeH⁺), which is widely regarded as the first molecule to form in the universe. Scientists believe HeH⁺ appeared around 380,000 years after the Big Bang, when the universe had cooled enough for electrons and atomic nuclei to combine into neutral atoms in a period known as recombination. This marked the beginning of chemistry in the cosmos. Immediately after the Big Bang about 13.8 billion years ago, the universe was extremely hot and dense. As it expanded and cooled, hydrogen and helium became the dominant elements. Once neutral helium atoms formed, they could react with ionised hydrogen nuclei, or protons, to create helium hydride ions. Although simple in structure, HeH⁺ played an important role in the young universe. It was the first step in a chain of reactions that eventually produced molecular hydrogen (H₂), a molecule made up of two hydrogen atoms and now the most abundant molecule in the universe. Molecular hydrogen later became a key ingredient in the formation of the first stars. At the time, the universe had entered a phase often called the cosmological "dark age." Matter had become transparent to light following recombination, but there were still no stars or galaxies producing visible light. Several hundred million years would pass before the first stars appeared. For those first stars to form, large clouds of gas had to collapse under their own gravity. To do that, the gas needed to cool by releasing energy. While hydrogen atoms can help with this process at high temperatures, they become less effective below about 10,000 degrees Celsius. Molecules can continue the cooling process by releasing energy through rotational and vibrational motions. Scientists have long considered HeH⁺ a potentially important coolant because of its comparatively large dipole moment, a property that describes how electric charge is distributed within a molecule and allows it to release energy efficiently. The amount of helium hydride present in the early universe may therefore have influenced how easily the first stars could form. At the same time, HeH⁺ was constantly being destroyed. Under primordial conditions, its main destruction mechanisms were recombination with free electrons and chemical reactions with hydrogen atoms. These reactions ultimately helped produce molecular hydrogen, linking the formation and destruction of HeH⁺ to the chemistry that shaped the early universe. For many years, theoretical studies suggested that reactions between HeH⁺ and hydrogen atoms would become much slower at low temperatures. Scientists believed there was an energy barrier along the reaction pathway that reduced the chances of the reaction taking place in the cold conditions of the early universe. The new study suggests otherwise. To investigate the process, researchers recreated a closely related reaction using deuterium, a naturally occurring isotope of hydrogen that contains one proton and one neutron in its nucleus. When HeH⁺ collides with deuterium, it forms an HD⁺ ion and a neutral helium atom. This allows scientists to study the reaction in a controlled way while closely mimicking the behaviour of the original reaction involving hydrogen. The experiments were carried out at the Cryogenic Storage Ring (CSR) at MPIK, a specialised facility designed to recreate conditions similar to those found in space. Researchers stored HeH⁺ ions in the 35-metre storage ring for up to 60 seconds at temperatures just a few kelvins above absolute zero and merged them with a beam of neutral deuterium atoms. By adjusting the speeds of the two particle beams, the team measured how the reaction rate changed with collision energy, which is directly related to temperature. The researchers found that the reaction rate remains almost constant as temperatures decrease. In other words, the reaction does not slow down at low temperatures as earlier models predicted. “Previous theories predicted a significant decrease in the reaction probability at low temperatures, but we were unable to verify this in either the experiment or new theoretical calculations by our colleagues,” explained Dr Holger Kreckel of MPIK. “The reactions of HeH⁺ with neutral hydrogen and deuterium therefore appear to have been far more important for chemistry in the early universe than previously assumed,” he continued. According to the researchers, the reaction appears to be barrierless, meaning there is no energy obstacle preventing it from taking place efficiently even at very low temperatures. The findings support recent theoretical work led by physicist Yohann Scribano, whose group identified an error in a widely used potential energy surface, a mathematical model used to describe how the energy of a system changes during a chemical reaction. The error appears to have caused previous studies to significantly underestimate reaction rates under primordial conditions. The new calculations closely match the experimental results. Together, they suggest that helium chemistry in the early universe may need to be re-evaluated. Because molecules such as HeH⁺ and molecular hydrogen played an important role in cooling primordial gas clouds, the findings could help scientists build more accurate models of how the first stars formed. By showing that helium hydride was likely destroyed more efficiently than previously thought, the study offers new insight into the chemical processes that shaped the universe during its earliest stages and helped set the conditions for the emergence of the first stars. Source: Max-Planck Institute, EDP Sciences This article was generated with some help from AI and reviewed by an editor. Under Section 107 of the Copyright Act 1976, this material is used for the purpose of news reporting. Fair use is a use permitted by copyright statute that might otherwise be infringing.
    • Politically funny images of the World

      By PsYcHoKiLLa · Posted

      "What an interesting smell you've discovered"
    • Poll: Grand Theft Auto VI price predictions, cast your vote

      By thartist · Posted

      It could EASILY be 70 for the base game BUT + lots of FOMO to make it up to 100-120, like a few days Early Access, online money, pre-order bonus cars, weapons, missions, clothing, avatars or profile stuff, etc... And still WAY TOO MANY people would buy those and make Rockstar insane money.
    • Why you need to take back control of your synced passwords and how to go about doing that

      By Nick H. · Posted

      Just to understand: your solution to getting rid of an online password manager is...another online password manager?
    • Cjam 2.5.0.0

      By Copernic · Posted

      Cjam 2.5.0.0 by Razvan Serea Cjam is a lightweight and fast MP3 editor for Windows that lets you cut, join, and edit MP3 files without re-encoding. This means your audio quality remains untouched, and edits happen instantly. Cjam is ideal for quick, lossless edits—whether you're trimming music, combining tracks, or preparing audio for learning tools or podcasts. It features batch processing, scripting support, cue and playlist file handling, and a simple interface. Cjam is perfect for anyone who needs efficient MP3 editing without the complexity of full audio suites. Cjam requires a PC running Windows 10 or later and Microsoft .NET 6.0 or later. Key features for Cjam: No Re-encoding: Edit MP3 files without losing quality. Cut and Join MP3: Easily cut, trim, and combine MP3 tracks. Batch Processing: Edit multiple files at once for faster workflows. Scriptable Interface: Automate tasks with a custom command language. Cue and Playlist Support: Handle CUE and playlist files for seamless audio management. Fast and Lightweight: Quick processing with minimal system resources. Lossless Audio Editing: Ensure your edits don't affect audio quality. Simple User Interface: Clean, intuitive design for easy navigation. File Format Support: Works with MP3, Cjam-specific file formats (CJAMC, CJAMJ, CJAM). Cjam 2.5.0.0 changelog: Added clipboard-based import/export support for mp3DirectCut Added clipboard-based export support for REAPER Added support for naming IMP3 elements Changed the Reset behavior to preserve Undo/Redo history; use Shift key + Reset button to clear it Added a new command parameter (qcp) Added 8 new entries to lang.txt (main_c124-126, main_d150-151, main_m082, vme_c014, vme_d005) Fixed a bug where the il parameter was incorrectly applied when pasting VMP3s into the main list Fixed several other minor bugs Download: Cjam 2.5.0.0 | 1.4 MB (Freeware) Links: Cjam Home Page | Cjam Manual | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware

  • Recent Achievements

    • Dedicated
      JuvenileDelinquent earned a badge
      Dedicated
    • First Post
      DrWankel earned a badge
      First Post
    • Reacting Well
      DrWankel earned a badge
      Reacting Well
    • Week One Done
      Supreme Spray LV earned a badge
      Week One Done
    • Week One Done
      Genuinetonerink- Dubai earned a badge
      Week One Done

  • Popular Contributors

    1. 1
      +primortal
      504
    2. 2
      +Edouard
      163
    3. 3
      PsYcHoKiLLa
      91
    4. 4
      Steven P.
      75
    5. 5
      Michael Scrip
      72
    Show More

  • Tell a friend

    Love Neowin? Tell a friend!