What are the programming languages that a game developer should master ?

You've never played with QBasic? I suppose you might be too young. That was one of my first languages. It was referred to as the spaghetti language because its use of GOTO everywhere made it impossible to trace. To be honest I never tried to define line numbers out of order. Don't know why, one of the more frustrating things in the language was when you ran out of line numbers after doing some refracting.

 

@Tomnnn: Give this QuickBASIC clone a shot and see. It supports running code on the site. http://www.qb64.net/

 

Sounds like they would benefit from something like sass/compass. A preprocessor! So you could do something like insert space at a certain point and the preprocessor would move up all of your line numbers to make room. Or simply leave the line numbers out and then it would fill them in before compiling.

I'll give that a look... maybe. 14 hour work days 6 days a week

 

That would break GOTO. Which was a mainstay of the language. There wasn't such a thing as a function to nicely modularise the process.

 

QuickBASIC supported labels in addition to line numbers. Microsoft's earlier GW-BASIC had a way to renumber lines and change the references to them via the RENUM command, but it couldn't reorder the code automatically.

http://www.antonis.de/qbebooks/gwbasman/renum.html

 

Actually QB has functions but they are more or less of no use (as the language now )

 

Why wouldn't they be? They're essentially no different from C's functions.

 

is that logo or qbasic?

I learrnt that programming language when i was in 4th or 5th grade

 

Simply BASIC. QuickBASIC is more typically found without line numbers.

Code (csharp):

1. Repeat:
2. PRINT "Hello world!"
3. GOTO Repeat

 

Although I personally prefer using control structures such as If ... End if, select (switch) case, for next and so forth the Goto really is not absolutely terrible. The reason why the BASICS had it is becaue BASIC was modeled after Assembly language. Assembler had only branching instructions, jump directly to code section and and jump to a subroutine.

Many people who say they hate Goto are ultimately using Gotos all of the time anyway under the hood. Sure they don't see it that way and aren't specifically coding in goto jumps themselves but ultimately as the higher level language is translated down closer to binary at a certain point (certainly when it reaches assembly language level which it has to at some point) a for next loop is a loop counting and using some kind of goto back to the top of the loop code. Switch statements will have code on the breaks to jump to the end of the switch statement. Ultimately there has to be some jumping around.

This I think is a great example of how as we use higher level languages such as C and C# people have lost an understanding of what is really going on under the hood.

 

I believe that's the point. Let the compiler deal with GOTO and memory management and the like. Having humans at that low level is inviting disaster.

 

Which is of course why I'm interested. Instead of using obscurity to stop people from cracking your software... just use a lot of gotos. They'd need to go through it line by line to copy it

 

The thing is Assembler is incredibly straightforward and very easy. You are dealing with very tiny very specific instructions. I think it is helpful for a person to work at such a low level. Helps to learn how to break down large things into smaller things into tiny things.

That being said I also enjoy the software engineering side in general. And a lot of people just want to get stuff done period so I do get that

 

That's not very american of you, mr benjamin. You should want to find the best way to get something done and then patent it so no one else can do it without paying you.

 

The thing is I am very focused on just getting stuff done as efficiently as possible. Recently I tested several different game dev frameworks just to see which is faster for me to develop 2D games in. The thing that is odd though is that for me it seems like the more lower level the faster I can get stuff done. I am not sure Assembly would be that same way but am tempted to make Mars Explorer on the C64 in assembly language as a test to find out.

Sometimes I think all of this higher level stuff actually gets in the way of getting stuff done.

 

I guess that depends on what it is.

 

Accounting, finances, company and resource management, then preferably design or art skill.

If you learn programming languages, you'll become PROGRAMMER. Programmer is not necessarily a game developer.

The backbone of gaming project is art team and design team, while programmers take backseat.

I'd recommend to start learning how to draw or model, and maybe look at using C# script within unity. I do not recommend going "full programmer" route. Programmers make game engines and plugins, not games. Artists, designers, script writers and project leads take the credit.

Do not "learn programming to make games". You can hire someone else to do that. Learn programming only if you want to program.

P.S. I'm a programmer.

 

That's true. I wouldn't say it is an absolute thing. Just that generally speaking (in my opinion) data structures and code are just so straightforward and logical they are very simple to work with and that supports fairly rapid development.

Basically anything you want to accomplish can be expressed by a data structure of some kind and when you are the one designing that data structure you can make it as simple as is needed. It's like the little Mars Explorer game I made I had a couple people ask how I did the wheel tracking the uneven terrain wondering if I had used box2d physics, read the image data (they thought maybe the ground was a long scrolling image) or what. And I told them that is actually fairly well documented in the source you can check it out. Nah, I never use physics systems like that, there is no need for that stuff and not relying on such things I can easily port my games to any system I want to.

I just look at the problem at hand: Make the wheels track the uneven terrain. The entire stage is made out of tiles. It was a very simple solution. Just build a little lookup table that tells me the height of the terrain image data within the tile rectangle. More specifically tell me the offset from the top of the tile rectangle to the top of actual image data. To give it a little higher resolution I actually stored values for the left half and right half of each tile. Wheel goes over a tile, lookup the offset based on the tile directly below the wheel and use that information to position the wheel accordingly. Take the average of all of the wheel offsets and use it to move the vehicle frame simulating the suspension system. No messing with colliders, tweaking physics values or anything.

Another example is in my Unity game Santa's Rocketing Christmas Drop. It doesn't use the built-in physics system at all. Snowballs hit the gifts I adjust the velocities of the impacted gifts accordingly. The gifts hit the roofs and their state changes to SlidingDownRoof. It is fully under my control. So how do the gifts slide down a roof? Again simply looking at the relationship of the height of the roof and the width of the roof a very quick calculation gives me the exact distance the gift should be moved horizontally per each unit of vertical movement (or vice-versa).

That is the kind of thing I mean.

 

I like your post in general, but I don't agree with this bit. Art can be the driving force of a game project, but it's hardly a rule.

 

The point of higher level languages is portability. With assembler you're forever locked into single CPU and operating system. Moving away from assembler will be hard and would require cpu emulator.

With higher level language you can move to another operating system and different architecture, easily - by abstracting things away. That's the point of "higher level stuff". It does what you need, and you don't need to worry how exactly it does that.

That's the reason why C was originally created.

"Doing thing efficiently" is essentially a trap, by the way.

Making a program have two costs: immediate cost (how much time would it take to write it) and delayed cost (maintenance). When language is inherently error-prone and has no safety nets (like assembler), you may have low immediate cost but very high delayed cost.

The ultimate goal of programmer is to solve problem by writing as little as possible (or without writing anything), at zero maintenance cost and at maximum payment.

So, you need balance. You need to solve problem quickly, at little immediate and maintenance cost, and get paid for that. Usually it means that you can't go for the simplest solution, the most elegant solution, or the perfect solution and will need something in between. Usually that would mean that new code you write should be clean, bugs that are not related to your current problem are untouched, you use existing frameworks and functions when possible, and do not go all the way to the madness of "perfect solution".

Also "profile before optimizing".

 

I believe it is the rule.

Project lead comes up with concept, art teams produce design, programming team provides means to make that happen, or reports that it is impossible, and design goes through the next iteration.

I can remember only two programmers from all the games I saw and those guys are David Perry and John Carmack. The rest are unknown or forgotten.

When people finish your game, they do not remember software design. They'll remember gameplay, characters and interaction with them. Even in something like MMO people will remember environments first (although if there are BUGs and issues, programming team will get some flak along with the rest of the studio). All the amazing work that programmers did is forever hidden under the hood and is invisible to the players.

There are exceptions where lead programmer is also a lead designer, but as general rule, most of the time the core art/design team and the guy with the main idea lead the project. Not programmers.

 

I know what you are saying. This is definitely touted as the advantage and I disagree with it. The lower level your code is meaning the more you break it down and rely on very simple instructions the more portable it becomes it in my experience.

The more you rely on higher level commands, proprietary data stuctures, apis and so forth the more you are locked into that specific language and framework.

For example, make a game in Unity using the same way as most people do. Use the physics, the built-in colliders and all of that good stuff. Now port the game to HTML5 or java or GameMaker Studio. Or if 3D port to other 3d frameworks and whatever languages they are using.

If you write those higher level commands and create the higher level data structures yourself then yes it is highly portable. Because you can then implement the same stuff using a bunch of lower level commands in whatever language you are porting to.

 

I did something like that with an infinite runner that involved jumping, a jetpack[oxford comma] and a grappling hook. Some obstacles came up in front of you so you had to jet up a bit and shoot the hook backwards to pull yourself out of the 'kill' area

I agree with you but exhaustion prevents me from forming a response that indicates such.

 

Sure, but there's a huge spectrum between "lead designer" and "taking a back seat". I guess it comes down to exactly what you think a "back seat" role looks like. To me it implies having little to no say in where a project goes, which certainly isn't my experience.

 

Actually it was QBasic..... But what you did here.... we are never taught till 8th and from 9th its Java....
We are forced to use line numbers....

 

You do realize that all the problems you listed can be dealt with, right? That includes porting unity project to gamemaker studio (that one would require some serious voodoo, time, funding and manpower, though). And you do know that there are simple strategies to avoid getting locked into platform, correct?

Going low-level worked for your examples, because you were dealing with simple toy problems. If you increase complexity, however, project will collapse under its own maintenance cost.

You simply will not be able to maintain codebase with decent size (over several megabytes big) when it is written in assembly. That's the main reason why higher level languages exist. Another benefit is tools. With higher level language you get large number of tools that can deal with anything. With assembly, you get pretty much nothing.

What I meant that programmers are less important. They're replaceable, while changing lead designer will have significant impact on the project.

 

Of course, I "do realize". I explained to you how to do it! lol

 

You are talking to @GarBenjamin. The platforms he develops for measure their storage space in KB.

 

Well my experience working on close to a dozen commercial games was decidedly different. Most of my time was with serious studios but still fairly small, 10-100 people.

Art never drove our games. Developers were usually much closer to the game design process then artists, because we were there for the whole cycle before the final art was even being worked on. Developers as a rule get paid more, quite a bit more at the senior level. All of our senior developers made significantly more then any of our artists or game designers.

Also, the line between developer and game designer is fuzzier then you might think in the top studios. It's actually hard to say whether the current generation of game designers are designers first or developers first. So many of the problems they solve are at their core math problems. Scaling the progression of various parts of a game is all about math. Designers are the ones spending more time playing through the game to see if the math feels right.

Now not all studios are like that, but that's where they are all headed. Yes it's different then it used to be. Now days every developer is expected to know basic game design, and every designer is expected to know basic coding. From there they specialize out to various degrees, but there really is no hard distinction like you used to see. You can easily turn one into the other in a fairly short time period.

 

No, you didn't. You simply stated that dealing with toy problems using low-level approach is easy.

Is that ZX-Spectrum or something? (64kb memory total, 16 kb for bios, another 16k for screen, and storage on tape, 7 colors, 32x24 color attributes per screen, each corresponding to 8x8 monochrome pixel block, cpu frequency 7mhz)

Anyway, that would mean he's dealing with edge case. Which also means that something that may work on his hardware will not be a good idea in the rest of programming projects.

Alright, then, I have nothing to say against that, since it is your experience.I guess whoever's interested in reading in the thread can read both opinions and make their own decisions.

 

Real world experience and opinion are not the same thing. Most of us with real world experience aren't here to brag about it, but I put the fact that it was based on some considerable experience because that's important if you are going to make assertive statements. Making assertive statements on a subject without any actual experience is putting yourself on shaky ground. I'm not saying you have no experience, I'm just saying when you make assertive statements it's very helpful to know if you do have any actual experience.

 

Why does it have to be "against"?

 

What kind of argument is that?
You experience something, then you draw conclusions based on that. The conclusion most likely will be incorrect because it only applies to your life and your very specific life circumstances. Said conclusion is opinion.

The world is BIG and has many places in it.
Live in different place and you'll get different experience.
Sometimes, just living different life is enough.
I'm quite sure that I do not live in your country and that I'm not you.

First you say you "aren't here to brag", then demand to list experience on the forum.

I've been programming in C++ since 2003.

I believe you should be able to roughly guess my age, skill and work experience based on messages I left.

I see no reason to discuss my work history unless we're discussing possible employment, and I'm already busy in a project.

Have a nice day.

 

Are mods not on duty?

 

Don't you know they are all "toy problems" in the end? With experience you realize that big problems should be broken down into smaller problems. And those in turn broken down into smaller problems still. Eventually you end up with... well look at that... "toy problems".

Really not sure why you came in here with such an attitude seemingly only interested in arguing with everyone.

Ha ha! Well not quite like that but I definitely keep my personal game projects small scale. Work projects on the other hand are very different. Have to admit I do like working within limitations on color, resolution and definitely try to keep the overall size of the program down. Although I am loosening up on that and allowing more wasteful approaches to slip into things as time goes on.

 

They'll be in with the flame throwers at some point, just sit tight for now.

 

Hello from Kuwait!

Unity is your best choice, start by learning C#, and only C#, do not attempt to learn more than one language, you only need to learn one language for now to start!

Start here (I Suggest you watch this video, play a bit with Unity, watch it again, till you get the idea):

Coding in Unity for the Absolute Beginner

Unity C# Beginner Tutorial (Watch all the parts)

 

1. Learn about basic programming principles not syntax.
2. Learn the basics for how a computer works.
3. Add a bit math.

Then pick up what ever language you need for a given project.

 

+1 for this.

 

If you want to have a rock-solid career as a game developer, you should know C++ in addition to the scripting languages, in case you ever want to work at the engine level. It doesn't matter if you think C++ is a bad language, it is used beneath the hood and you can't avoid that.

 

I wasn't working on games that long ago, but why did the game industry pick C++ over C? I know in my area which is more server side stuff they dropped C++ for pretty much anything low level a long time ago. It's just flat not allowed in linux kernel drivers which covers a pretty broad spectrum of low level code.

 

Btw not that you can't find C++ in server side apps, it's just not nearly as common. Just curious on the history. I know pretty much all the talks I hear from console guys they are always talking about using C++ but not using most of the language features, and not knowing a whole lot about that area it always made me wonder why then do they even useit? Like there must be a reason somewhere.

 

TIS-100... like coding but 20x more tedious.

 

https://en.wikipedia.org/wiki/Omgrofl

 

Off-hand it was likely timing. By the time computer technology had reached the point where you weren't severely restricted by processor and memory constraints Borland had affordable compilers.