C++ or C#

[Guest]

TL;DR

I need to write a server & clients. They will talk over the internet. What networking APIs do you recommend for C++?
I will send maps as txt files, & be running a real time video game over the network at the same time.

Or should I just use C#? I know C# quite well.

 

Long:

I'm making a video game. I started a demo a while back using C# for the server with sockets & Unity with C# for the client. I want to get away from Unity & I want to develop the game for Linux.

My map creation tool is written in SFML with C++ (I made a thread about it a while back (1-2 years ago) as I had a bug)

 

I'm going for a more traditional game development route where I kinda make everything. Engine, tools so fourth.

 

 

Pros C#

1. I can stick with C# and just sorta continue where I left off.
2. I can write a 3D engine using a tool called OpenTK using the deprecated Open GL api which is still functional but easy to use.
3. I know C# extraordinarily well.

Cons C#

1. The AAA industry uses C++ still & I want to work in AAA development. I'm making a AAA game to target AAA HR.

 

Pros C++

1. My map tool is already written in C++.
2. The AAA industry uses C++.
3. I'm about to take C++ again in college class.
4. I'll learn a lot about C++ as I don't really know it that well.

Cons C++

1. I haven't used C++ since I made the map tool & it's been a lot longer before that.
2. C++ works differently to C# and I have to get to grips with it again. I don't know how for the life of me to program Open GL in C++.
3. I'm going to have to figure out how to get it to run in SFML or SDL & I can't figure SDL out like at all.
4. Most of development may be figuring out how to use C++ and the APIs in C++.

 

I would be interested to know which language you think I should go with.

If you have any advice on C++ development, that'd be very helpful. I have good documentation for everything C#.

I need API recommendations for C++. C++ has standard headers but from porting my map tool to Linux, I learned not all standard headers are standard & most solutions on stack overflow are windows specific.

 

Naysayers:

Spoiler

Spoilerzzzz? I tHInk NOT. ON GUARD!

I have a few textbooks that are aiding me. Absolute C++ by Walter Savitch; Game Engine Architecture by Jason Gregory; AI Game Programming Wisdom Edited by Steve Rabin; Open GL Superbible (Which kinda starts off by saying "yeah just use these files we don't tell you how to get. Thanks. I'll have to double-check it though.)

I've been around the forum & worked on some decent stuff so I'm not a complete noob.

 

Don't derail by saying "This is a stupid project." I'm doing the project, not you. I'm in the pre-pre-production stage gathering information before planning out designs, schematics, & psuedocode.

 

[Aaron_T]

There are some situational issues that you need to be aware of with regards to C++ vs C#.

 

First, there is nothing wrong with using C# (.NET Core) for your server side development, and since .NET Core is platform agnostic, you can easily have this function on a linux based platform. Just be sure to use a serializable communications protocol so that you can send and receive your data via any disparate systems.

 

Second, you DO NOT want to use C# anywhere that could affect your game's framerates. I developed a HD-SDI video encoding and overlay system for an in house video processing pipeline and tried to use C# for actual frame overlay processing, and ultimately gave up and switched back to C++ for that portion of the code because the .NET CLI was much to slow to keep up with high frame rate streams. Also keep in mind that if you try to build the game engine in .NET then "import" C++ CLI packages, you aren't actually solving the problem. When you compile C++ CLI code you are getting all the bloat that comes with .NET, so you have to use pure C++ for the engine, or anything that could affect framerates.

 

As for the type of API you'll want to use, it does depend a bit on how you design the game and your server side interaction with said game. If you want best possible speed from your server side API, you'll likely want to build it out with RESTful APIs using JSON for your data packages. On the other hand, if you want the best reliability that you can get, then you'll likely want to use SOAP APIs to ensure reliability, WCF for instance. As for implementation packages, .NET has both built in. And it should be easy enough to find implementation packages in C++ for either, for example, "Google" "C++ RESTful APIs".

[wanderingfool2]

Full disclosure, I haven't done any game programming since exiting school; and steered away from the industry...so I might not be the best when it comes to all of this.

 

If your ultimate goal is geared towards entering into the AAA industry, go with C++...it will give you the most benefit in the future.  Actually I find C# is a good tool for quick inhouse programs (as it offers an ease of flexibility for the GUI and coding aspect of it...but it comes at a cost of performance).

 

Are you doing a 3d or 2d game...if it is a 3D game, then I really would recommend trying some open source graphics libraries/physics engines (Ogre 3d is okay, https://en.wikipedia.org/wiki/OGRE and c++ using MIT license).  There are a lot of aspects that go into making a game, and I find that when you go for high end 3D graphics it comes down to more math (so do learn math well).

 

Most titles these days are actually based off of engines anyways (and they just make modifications to the engine to fit their needs/artstyles, so it can be good learning it that way, being able to adapt different engines to fit your needs)

 

Anyways, just my 2 cents.

[Guest]

On 2/13/2020 at 12:28 PM, AaronThomas said:

Second, you DO NOT want to use C# anywhere that could affect your game's framerates. I developed a HD-SDI video encoding and overlay system for an in house video processing pipeline and tried to use C# for actual frame overlay processing, and ultimately gave up and switched back to C++ for that portion of the code because the .NET CLI was much to slow to keep up with high frame rate streams. Also keep in mind that if you try to build the game engine in .NET then "import" C++ CLI packages, you aren't actually solving the problem. When you compile C++ CLI code you are getting all the bloat that comes with .NET, so you have to use pure C++ for the engine, or anything that could affect framerates.

I was mostly considering working in C++ just cuz it's the standard. I posed the C# vs c++ because I wasn't sure if the headache would be worth it or not.

Quote

As for the type of API you'll want to use, it does depend a bit on how you design the game and your server side interaction with said game. If you want best possible speed from your server side API, you'll likely want to build it out with RESTful APIs using JSON for your data packages. On the other hand, if you want the best reliability that you can get, then you'll likely want to use SOAP APIs to ensure reliability, WCF for instance. As for implementation packages, .NET has both built in. And it should be easy enough to find implementation packages in C++ for either, for example, "Google" "C++ RESTful APIs".

Thanks! This will help me find some API. I thought REST was a language or something built into JQuery or something so I never looked into it as I don't want to make websites. (Even though web development is IMO the best way to make applications nowadays.)

 

 

 

18 hours ago, wanderingfool2 said:

Full disclosure, I haven't done any game programming since exiting school; and steered away from the industry...so I might not be the best when it comes to all of this.

I can see why you stayed away from the industry but I'm curious what kind of programming you did for games. I studied a little bit of Game Development finding it lackluster & CS to be way more beneficial.

Quote

If your ultimate goal is geared towards entering into the AAA industry, go with C++...it will give you the most benefit in the future.  Actually I find C# is a good tool for quick inhouse programs (as it offers an ease of flexibility for the GUI and coding aspect of it...but it comes at a cost of performance).

As C# is so easy I posed the question of doing the entire project in C#.

Quote

Are you doing a 3d or 2d game...if it is a 3D game, then I really would recommend trying some open source graphics libraries/physics engines (Ogre 3d is okay, https://en.wikipedia.org/wiki/OGRE and c++ using MIT license).  There are a lot of aspects that go into making a game, and I find that when you go for high end 3D graphics it comes down to more math (so do learn math well).

I've heard of OGRE before. It's a whole technology suite for Game Development. I am aiming for a 3D game though it could probably work in 2D. I want to work in AAA so I may be obligated to work in 3D. I don't want to remain my own collective. If I was fine with it, I'd do whatever. (Which would still probably be 3D haha)

Quote

Most titles these days are actually based off of engines anyways (and they just make modifications to the engine to fit their needs/artstyles, so it can be good learning it that way, being able to adapt different engines to fit your needs)

I've considered this but Unity & Unreal are so bloated that it's like... I have no idea what to modify & anything I modify won't be worth modifying anyway.

Most other Engines are annoyingly confusing, basic and/or closed source. I'd have used Leadwerks but I had a vote for 1 of 3 game ideas & the one picked needs to be developed this way.

 

 

Thanks to both of you for the input!

If anyone else has any useful information, please let me know.

[wanderingfool2]

On 2/14/2020 at 4:06 PM, fpo said:

I can see why you stayed away from the industry but I'm curious what kind of programming you did for games. I studied a little bit of Game Development finding it lackluster & CS to be way more beneficial.

Yea, there can be a lot of burnout in the industry (or worse, people getting let go because of their age...but things have changed a bit I think).

 

I focused on the physics engine in my school project (built it from scratch), I also did the UI element (but I really am horrible at art).  I used Ogre3d for graphics.  Getting to know how to adapt and utilize things like graphics engines is just as important as learning how to program in my opinion...95% of real world projects \ (in my experience) I find is re purposing tools you have to do other things.

 

(Sometimes people want to get into making video games, but they also realize that they are more into game design as well vs programming).   [I have also tried networking (used a prebuilt physics engine and ogre3d to render and adapted it accordingly) and game design in other school projects].

 

Actually another cool thing to look at is torque 3d  (again MIT license...I love MIT licenses)

[Trinopoty]

On 2/15/2020 at 7:34 PM, Erik Sieghart said:

This kind of game design should only ever be C++. You're not going to get the performance you need anywhere else.

 

Also a note about bloat: that's a term people use but it just means feature rich. It's not a negative to have a lot of options.

Bloat is usually used to refer to unnecessary shit that gets in the way of doing things.

If I say my new phone of bloated, I usually mean it's got shit that I will never use that I can't get rid of.

Having lot's of features is good, but bloat is never good. If it was good, we wouldn't be referring to it as bloat.

[Dat Guy]

On 2/15/2020 at 1:06 AM, fpo said:

I was mostly considering working in C++ just cuz it's the standard.

Huh?

 

Which standard?

[Guest]

4 hours ago, Dat Guy said:

Huh?

 

Which standard?

Video game industry standard 

[Dat Guy]

Where can I find the numbers?

[Guest]

29 minutes ago, Dat Guy said:

Where can I find the numbers?

I don’t know. However, I see c++ in nearly every game development job posting for programming. 

[Trinopoty]

2 minutes ago, Erik Sieghart said:

Well that's what people think anyway. You should read some of the old Joel on Software articles.

 

Words change meaning over time. I don't care about a 10 year old meaning unless I'm reading a 10 year old article.

[homeofmew]

First of all, C++ was the first programming language I learned.
Having a good C++ base is great when learning any other language.  

You see C++ Required more over any other Language for jobs.   They may mention C#, Java, Python, ect, but you won't get anywhere without C++.
Learning Assembly was easy as pie after learning C++

[asquirrel]

C++ for the engine, C# for anything that isn't the engine *if you want to*. As for the network, you're going to find that any APIs or libraries you use for networking are all going to do the same thing under the cover:

#ifdef <some OS flag> 
	#include <osspecificheader1.h> 
#else
	#include <languagegenericheader1.h>
#endif

Sometimes this works great and the API simply saves you headaches. Most of the time (IE: Boost) this is a problem that leads to you tearing out all the work you did with the API down the road because in the API's march to 'be universal' it can't do something you need it to do. Just start down the path where you solve the problems you hit yourself.

 

As for transferring data across the network, here is my formal recommendation: Create a standard struct (literally a C++ struct) for network data. Define these fields in it:

1. Message type
2. Message length
3. Message payload
4. (optional) checksum/verification

The important part of making that work is that message type and length need to be a fixed size. So, say, message type might be 1 byte (so you could have up to 255 different message types) and length might be 2 bytes (no single message will be larger than 65535 bytes). Why? Because in this way you can package *any* data (maps, movements, firing commands, etc) into standard payloads and send them across the network very, VERY efficiently. As in, I have used this to saturate 40Gb trunk lines efficiently (no, I'm not joking). The reason being that you can read the network packet directly into the struct and then do all your processing directly on the message type (opcode), then have a handler for each message type that can further decode the payload if needed. The CPU can do all this in less than 10 instructions if you code it right.

 

In case it still isn't clear, message type and length need to have a fixed size and location so that you always know where they are in the bytestream you receive. And you want to be able to send a bytesteam, rather than individual packets, because networks operate *far* more efficiently with bytestreams than hand-crafted packets. You are not smarter than the OS's TCP/UDP implementation. Say it with me: "I am not smarter than the operating system!" You aren't. I've known far too many programmers who thought they were and got proved wrong.

 

If you have something large, like a 1GB map file, you don't even need to convert it to anything. You have one message type that says "map download start", and within the payload for that message type, your handler defines that the first byte of the payload contains the total number of map download chunks being sent, and the second byte is the index of this specific chunk (since they might arrive out of order because you WILL be using UDP for your game. Right? RIGHT!?). This will allow you to re-assemble your map file in memory *very* efficiently by simply memcpy() ing the 3rd bit in the message payload into the map array at payload_size * index. This solution also multi-threads well, because while school teaches you that having multiple threads working on the same memory object is unsafe the reality is that in a large array, as long as nobody needs to write or read the same data, it's perfectly fine to have 10 threads writing to the same array at once.

 

So, your send handler will just take the 1GB map, figure out how many max-length messages it will take to send it, and then start creating the message payloads to transfer the file. The receiver will need to decode the same thing, and re-assemble the file in memory. You exit the re-assembler when:

 

1. A timeout value is hit (connection died, index got lost and needs to be retransmitted, etc) OR
2. You receive all of the indexes you were expecting AND
3. You receive all the bytes you were expecting

Be sure to check 2 AND 3 together, don't rely on just one.

 

Doing all this in C++ will make you a better programmer. You'll understand *why* you are doing things, rather than simply shoving bits into a magic API and stuff 'just happening'. Never fear learning, even if it's slow.