Upon seeing this. I plan that if I get the basics of say for example XNA/Monogame. Make 2 projects from those like pong clone and breakout game. Then move to unity for RPG style. Is that what are you suggesting? C# is the only language I know so far so Unity and XNA/Monogame is the best choice.

I somehow glimpsed over this, but my lack of an earlier reply isn’t really a major loss.
The whole area of “what to learn” is somewhat grey. I mentioned that it’s hard to predict what a smaller studio needs of new recruits, and Hodgman also notes the difference in expectations companies have when hiring for different positions.

I’d personally focus more on getting into C++ from your current position. At least that is the common denominator between the vast majority of game-programming jobs.
Then if you chose to follow my original advice to make projects in multiple engines your knowledge of C# will be there to assist you.

Beyond that it gets grey because not everyone wants to make engines rather than games, not everyone wants to make games rather than engines, and every company has some kind of balance between the 2 when seeking new recruits. You can’t predict the kind of luck you will have in finding your first job.

But given that your first job most likely is just luck-of-the-draw, what you can do is focus on what you want to do.

I originally mentioned focusing on the low-level technology and making a few projects with engines as something of a fail-safe to that end. It’s basically the generic way of saying, “learning the low-level technology is never useless, and can be applied to any form of game programming you wish to pursue, while practicing with engines opens up another set of doors too.”

If you learn the low-level programming behind the core technologies in games, but then you end up only as a regular game programmer, you are definitely going to be the top “regular” game programmer in your studio. Some studios who use existing engines also have a market for people who can modify those engines to suit their needs.

Once again, it’s overall the most fail-safe strategy.

L. Spiro

I'm not a real programmer but I'm confident that I could work in a company at many programming levels (obviously one at a time).

So I'm just a hobby programmer and started programming at the age of 19 during my studies at a mechanical engineering university, where we had a semester of C programming, than some graphics, but nothing really serious. Everything is self taught, only used a very few and mostly very specific tutorials (no internet in my first 3-4 years of programming). Learned a lot by making horrible codes, messy systems, ugly hacks, stupid mistakes and so on. Very early, I got the feel of the gut of programming: breaking down any problems to the smallest sub-problems, so even after a semester of C, there was no magic in programming for me any more.

I'm mostly a low level coder (C language), but I tried some higher level stuff and usually get the feel of them pretty quickly. Now I'm working with Labview (hated by many programmers) in my current job, made a pretty decent automation sequence editor in a week with only about 200 hours of previous Labview experience.

No using any engines yet.

So I'm programming for more than 10 years now, been offered with some graphical and other programming jobs (rejected them), had some huge gaps (years, months) but still was able to build up an okay programming portfolio (you can check my signature if you are interested). And I grew the confidence that with hard work and focus, even I could produce nice code and okay software architecture. Though I'm not doing any game or hobby programming at all for 2 years now...

So yes, do a lot of programming, do actual projects with different languages and at different programming levels. And in my opinion you should make and complete meaningful project in them, don't just try them out (I'm talking about small projects of course, like tools for example). And make other projects than games too.

Messy post from me as usual.

EDIT: C++ is missing from my "education", and I think it's something I should try someday.

Move this topic back to “For Beginners” and sticky if needed. This topic does not belong in the lounge.

L. Spiro

I see. so it depends on what do you want to be. Something I dont understand, if you're a game programmer. You will never know how the engine works. You may understand what it does but how it works is a complete mystery. So uh how can they hire you for a engine programmer?

If you're working as a professional game programmer, you'll most likely have the source code to the engine. If you're not quite sure how something works it's often worthwhile taking a peek into the code to find out. Often the documentation for intetnal code is shoddy, and the best documentation is the code itself, so you find yourself reading engine code in order to undetstand how to best use it as a client.
More rarely, you'll discover bugs in the engine by using it in new ways, and seeing as you found the bug, you might to the initial diagnosis/debugging, and pethaps contribute the final fix too.

Also, the line between game and engine code is quite grey, not black and white.
If you're building a game from scratch, there doesn't need to be any line between game and engine code! But, as soon as you make a second game, any code that you keep from that first game becomes your "engine".

e.g. It's quite possible that when working on a game for a large studio, they encounter the requirement of "AI characters who maintain formations" for the first time.
You, as a gameplay programmer, implement this feature into their new game.
Years later, they're making another game that also has this requirement; someone digs up your old code and adds it into the engine project as a standard part of their AI library. Bam. You're now unknowingly an engine programmer.

Don't underestimate how complex gameplay programming is. The simplest console games I've worked on have had a dozen talented programmers writing gameplay code for a year. Often there's a million lines of code of game-specific features, most of which gets thrown out for the next game as different features are required!
A lot of this code is complex and low-level too -- e.g. do you know how to optimize DMA stalls caused by improper task DAG generation for a NUMA portability layer? A senior gameplay programmer might...

If you started out as a person making game from scratch then releasing it, you got a higher chance of getting into that company as oppose for person who had just use a pre existing engine? So it means that doing a game from scratch(not a general purpose engine but only for the game your doing) is much preferred?

Not necessarily.
If you've never driven a car, can you be expected to design a car from scratch which is comfortable to drive, has high performance, and is easy to maintain?
If you've never used a big engine, can you design one from scratch that's productive for users, has high performance, and is easy to maintain?
At the very least, using Unity/Unreal/etc is useful as a competitor analysis and market review! (or as a laundry list of features to consider copying )

Also, the quality and impressiveness of a project isn't determined by which technology it's built on top of.
Sure - if two candidates both shoe an identical FPS game, but one says they made it from scratch while the other says they used Unreal, then the first candidate is way more impressive (or is discarded for lying ).
But that's usually not how things work.

Usually the from scratch games we see are things like Mario clones, or arcade games.
The simple "engines" that are used in these projects really have almost nothing to do with big commercial engines, so it's often not at all impressive when people show off their own "engines"... especially when their "engine" has no toolchain, nor any gameplay-level helper libraries. It's often just a demonstration that they know how to glue together a few open source libraries like SDL, etc...

On the other hand, people using big engines can often talk in depth about some specific feature they implemented -- e.g. "I took a sample Unreal FPS project, and I added logic for AI formations, so that they maintain a 'V' shape while attacking you".
Doing something like this can be more impressive. Also, one of the most important skills at large companies is the ability to be able to read other people's code and quickly understand it. Often, you'll only be writing ~10 lines of code a day, but you'll be reading thousands of lines of other people's code. If you only ever work on projects from scratch, then I guarantee you that you'll be terrible at this when you start out as part of a large team. By working with something like Unreal 4 and adding new features to their engine, you'll be practicing something that's a lot closer to what a real engine programmer's job looks like!

There's no rule here either way. Both are a chance to show off your coding style and range of abilities. Both options handicap you in different ways.

If you have time, do some projects from scratch, make your own engine, make some projects using the big popular engines, and make some mods. Do everything!

Try your hand at producing some bad artwork and level designs too -- these people are also users of game engines, so an engine programmer needs to understand how these people do their job (you don't have to be good at their job, but you need to know what their needs are).

I started by modding existing games. You would be surprised how much you can learn from modding, especially if you need to look at the registry of files and folders in order to add or alter things. It really gives you a good general vision of how well designed games are structured. Mod for a few months and you'll see what I mean.

How did you start? What did you do to get in to where you are right now?(making games or working for EA or ubisoft or an indie).

guess the number - olivetti underwood 101 programmable desktop calculator - 8th grade - 1977

lunar lander for the IBM 360 mainframe - 10th grade - 1979

text mode and vector graphics d&d game in MS basic - Sperry Rand PC 64K RAM CGA card, dual 360K floppies - freshman college - 1982

flying saucer shooter in basic - 8088 XT overclocked to 10Mhz - 1983?

SIMTrek - the world's first Star Trek flight simulator - top 10 download on AOL, 10,000+ DL's the first week. Side by side reviews with Castle Wolfenstein 3D in Electronic Gaming Monthly as Best of Shareware 1990. wriiten in pascal on an IBM AT. checks started pouring in in the mail. just like that i was making 60K a year as an indie gamedev.

A number of titles after that, none did as well as SIMTrek / SIMSpace (the name changed when gene roddenberry died), until...

Caveman v1.0 written in c++ on an XP machine - 2000 - free press coverage on the evening news in Washington DC (where i live) as a last minute xmas gift suggestion So many hits on the website, it crashed the site!

If you are a beginner on this generation. Are you still going to do the oldschool style of making your own game from scratch or are you going to use an engine like Unity,cryengine or unreal?

i'm probably the most un-begginer here! <g>

first off, there's game engines, and then there's game libraries, and then there's totally from scratch.

with game engines, you hang some lower level code (callbacks and such) off of their engine. typically, the engine contains the main game loop.

with game libraries, you hang some lower level libraries off your main game code, which usually contains the main game loop.

with totally from scratch, you use no engine or libraries, other than perhaps the standard C or C++ libraries or the equivalent for your language of choice.

when i started, there were not really any game libraries or engines out there yet.

code reused from earlier games in later games became my in-house library.

I started development on Caveman 3.0 three years ago. At that time, engines were still expensive. If i were staring it today, i'd probably use unity or some other engine, if it reduced development time.

i currently use the directx libraries and my own code. at this point, its easier to complete caveman using directx than porting it to unity. and the next two planned titles can be done with the exiting in-house code and directx - no engine required.

Did you got to game programming school? or are you from different background? How does it help you from developing games?

aerospace engineering - professional student - 12 years - cleaned out GMU of all general engineering classes offered, then moved on to OSU. berlin wall fell, saw the future of defense aerospace was going downhill, switched to software engineering. finished all but the BS liberal arts electives. Then SIMTrek hit, and i quit school. had enough hours for four engineering degrees, but never got a piece of paper to show for it.

the engineering background and software engineering training are unbelievably invaluable. they are what every real gamedev ought to be learning as a basic background, before moving on to gamedev specific studies.

i mean, how can you expect to model and simulate stuff like physics, if you've never take physics?

and how can you write well designed software if you know nothing about software engineering?

My question is.
How did you start? What did you do to get in to where you are right now?(making games or working for EA or ubisoft or an indie).

Standard nerd way for me.

Started with the C64, got into serious coding with the Atari ST/Amiga as teen, then PC, then got a degree in computer science, got some coding jobs during my time at the university, got a job in standard computer software, herby resign to take a job at a small game studio, released one title, but the game studio crashed afterwards (or better said was crushed), choosed to take a job as software engineerer in the standard software industry, because the game industry was really weak in germany at this time(eg crytek was not really known at this time). Being a hobby-gamedev since then.

Did you got to game programming school? or are you from different background? How does it help you from developing games?

I got a degree in computer science. I know people who got a job at the game industry due to their coding skills/demos much like L.Spiro, but the degree helped me to get a good overview of the whole computer science, which often helps you to evaluate things which are not common in a certain branch. Eg. as a teen I tinkered a pathfinding algorithm to solve a pathfinding problem for my hobby-game at this time. I needed some weeks to get it running, at university I learned that I have come up with the djikstra alogrithm and that there are other, better ways to solve pathfinding (A*). Nowadays I would start a research in the internet, but university was a good way to teach you something like this: 'If you got problem X, then check out Y first'.

If you ever wanna get into game company as for starters will you ever gonna use a pre existing engine? our are you going to start from scratch to learn whats going under the hood as thats what most AAA company is looking for?(IMO)

At the time, when I coded for the amiga, I disabled the complete OS, put my own interrupt handlers up, wrote my own loading routine to decode the disk format, wrote directly to the framebuffer etc., pretty deep under the hood. It was a really interesting experience, but it never helped me to get a job (a degree helped a lot).

It depends on what you want to do. Being able to write cool demos, an emulator, your own OS is a good way to display your skill, which can help you to get a job, but showing off what the industry want to see, helps you more to get a food in the door. Afterwards your skill will help you to get the ladder up.