Learning Vs. Production

Started by
7 comments, last by Kylotan 7 years, 8 months ago

Hello forum!

Currently I'm planning to create a game and facing a crucial question:

Being productive, getting something stable done, picking the right(?) tool

or

Learn and improve the knowledge of a certain language (C++)

It's by far not my first game that I'm making, however, whenever I made games in my past,

I worried less about their portability or if somebody will actually play them. I just did.

That was kind of a sake for productivity and learning about programming in general.

On the other side, I want to leave as many doors open for my future as possible - especially game development.

Sadly, I always hear about "the industry wants you to be really good at one language and one particular thing".

That would be C++, when I look at most big development teams.

But then I hear: "programming languages are tools inside your tool box".

Therefore, whenever I wanted to quickly develop a tool for all my different operating systems, I took C#/Mono.

Whenever I faced a special set of hardware, I took whatever seemed to work ( C ).

I'm simply open-minded to all kind of technologies/languages, I usually just take whatever does the job.

But now, I'm not so sure what is the right tool.

The game is just something simple, all the positive attributes of C++ seem not really to benefit me much.

However, I want to have this app not only on my Windows computer, but also on my Android phone.

Hence Java sounds like a more suitable choice.

Though, I want to improve my C++ knowledge, to not get lost at my future portfolio.

Especially, when all my (future) little to medium game projects are made in Java, just because do not benefit much from C++.

What do you think is the right decision? What would be the right tool?

I'm afraid that this is another personal decision (that only I can decide). Sadly, I cannot see its consequences by now.

Sorry for this huge post but thanks to all those, that took their time to read through it. : )

Advertisement
The important thing isn't to learn "what programming language all the cool kids are learning" but to learn patterns and concepts and the general idea of game creation. For example learn how to load and display graphics on screen and learn how to play music and sounds. Learn 3d and 2d discrete maths, vectors, transforms etc. Learn about game loops and event driven systems, entity component systems and anything else you come across.

Pick a framework to do this in or an engine, it doesn't really matter which one as your knowledge is transferable. Yes learning c++ is useful but don't dive in at the deep end.

Good luck!

Depending on your wish to go multiplatform you should start learning C++ because it is the most spread language benefit of the fact tha it is compiled into native code target platform understands and could run. You event dont need to leave your windows compfort zone when developing windows and android platform because of Visual Studio 2015 carries an native android build system within and a sample project creating APK files directly from c/c++ source without any java in there.

You should also go deeper into OpenGL or Vulkan (as vulkan is more platform independent but harder to use at all) first before targeting anything else because all the other stuff is needed in rendering as well so you will get forced to learn it automaticaly when working with GL and be motivated enougth to see what you do.

Main difference in C++ is the OS api that may be already there in java or c# but there are libraries for that also out there and STL for its own is as well as anything else at the moment.

Extending the good words by braindigitalis:

You seem to confused between tool skills and problem solving skills. To explain, consider you're a carpenter. You build houses. You use tools to solve sub-problems, like wood-working, pouring concrete, putting in electric wires, and so on.

To become the ultimate carpenter, you need to be good in several things:

- Converting the "build me a house" problem to a properly constructed collection of wood, concrete, stones, etc, such that it will pass any official inspection and that its owner will be happy with the result.

- Understand how to use a hammer, a drill, connect a wire, etc, a wide range of sub-problem solving skills.

In software, the "build house" problem skill is the overall program design skill, or how to go from "implement this" to "here is the code". The sub-problem solving skills is knowledge about programming languages, library knowledge, IDEs, debuggers, compilers, APIs like OpenGL or DirectX, etc.

So what do you need to learn?

I believe, the answer is a bit of both types of skills, and some skills a lot more. Which skills that are, depends on your preferences.

You definitely need sub-problem solving skills to some extent. Even if you never actually build a wall in a house, you do need to understand the limits in that technology before you can say "put the wall here in the house", while being confident that actually works. Like knowing not to use BASIC for programming a real time polling loop running at 50KHz..

On the other hand, there is a lot of room in becoming really good at these sub-problem skills. An expert C programmer really does program better than a beginner. An expert wall builder can build a straight wall just by feel. An expert artist can capture the idea in a drawing really well, very quickly.

The higher level problem is also of interest. Even when you're an expert hole driller, you need to be able to read the plans to decide where to drill a hole in which wall.

At higher skill levels you may be able to judge whether the indicated spot is useful, or maybe see a better spot, but on further study discover the reason why that better spot isn't so good after all.

Making such a plan is a totally different problem than reading a made plan, just like writing a design document is very different from reading what the plan suggests, or (at sub-problem level) building what the plan says.

In deciding what to do, I would suggest to follow your heart. You're going to do this for the next 50 years, so better do something you will enjoy.

The industry needs more skilled sub-problem solvers than global architecture problem solvers, which is why you only see jobs of the former kind. They are however not interested in the next 50 years, only in the first 6 months of it, ie your goal is different from theirs.

Focusing too much on a sub-problem skill has a danger of painting yourself in a corner. Maybe you're an expert hole driller, you can drill a hole through 1 meter hard concrete at a 33.5 degree angle in 10 minutes, while hanging upside down from a bridge in the middle of the night at 300 meter height while it is raining, but there are only a few such holes needed, so what are you going to do with the other 50 years - (20 * 10 minutes) time?.

You're being paralysed by thinking that you have to solve multiple problems at once. It's as if the next game you make will be the only game you ever make before getting a job in the games industry, but why should that be so?

If you want to work in the traditional games industry, you'll need to show you're pretty good with C++. No question. But that doesn't mean embarking on a 3-year project writing an engine in C++. Just make a small game and show that you know your way around the language.

Alternatively, there are lots of companies hiring Unity coders these days. C# works for them, especially if you have Unity experience too.

But none of this means your next game has to use either of those technologies, unless you intend for this to be your one and only portfolio piece.

Thanks a lot, everyone!

I think my general fear is, that I want this game to be done at some point and not spent tons of months on such a rather small game.

My C++ is not terrible, however debugging, testing and porting can eat a lot of time. Especially with the Android NDK.

On the other side, grabbing C#/Monogame, Java/libGDX, ... feels like wasting time that I could invest into my C++ study. As it seems, that I have to focus on one language - other languages are less worth in a portfolio.

While it feels like wasting time to use C++ to get this game done in a fashionable time.

Yes learning c++ is useful but don't dive in at the deep end.

What would be the deep end? Dive in sounds like I would just freshly start with C++, that is not the case.

You should also go deeper into OpenGL or Vulkan

Totally interested in OpenGL, but currently I'm trying to develop a game and not mess around with graphics rendering. Especially as I'm not in the need to do anything but sprite rendering. My focus is just a different at the moment : )

The sub-problem solving skills is knowledge about programming languages, library knowledge, IDEs, debuggers, compilers, APIs like OpenGL or DirectX, etc.

I just feel weird, when I specialise on one language, as that seems to be what people are looking for. It sounds just so limited in terms of.. well fun, to me.

Learning new languages is a lot of fun, learning about their idoms. But then, I would have to invest years of practise into them, to get a job with them - to show that I'm good at them.

Or is that simply a wrong image I have? But what if I like two languages just equally? This seems to be all so difficult, even more difficult that learning to program and design software.

Thanks for your example though, Alberth : )

You're being paralysed by thinking that you have to solve multiple problems at once.

This sounds pretty much like my current situation.

I very much doubt it will be my last game, but it will be another chance that I could practise C++ on. I just find it weird to use C++ on such a project. It feels overkill - if that makes sense.

However, as I said above, not using C++, feels like wasting time. Of course I would learn to improve my C++, that is by far no time waste. Nonetheless, I could also do other projects in terms of C++ that simply benefit from the language.

Sorry if this all sounds a bit confusing! This feels so important to me that just deciding is not easy at all.

I just feel weird, when I specialise on one language, as that seems to be what people are looking for. It sounds just so limited in terms of.. well fun, to me.

Like I said, companies have a different goal than you.

They have a project Foo, and they have a design, and now need coders in Bar language, for some months (don't know how long really, but definitely not "life time"). So obviously, they want Bar language coders today.

I think one of your misunderstandings is the skill level. What a company names "Experienced Bar coder" and what you see as "Experienced Bar coder" does not need to be the same. There is a wide range of people that call themselves Bar language coders in game-dev country, which all react to job advertisements for Bar language. Anything from "I just downloaded a tutorial", to "tried a few exercises" to "I can code an algorithm without SO or constantly looking up the name of library functions" to "wrote a game with it" to "published game" to "I can quote the entire standard on all aspects of the Bar language". I probably skipped a few levels there, but place yourself in that wide range, rather than the range from "my current knowledge" to "everything there is to know about Bar language".

My guess is (but I don't work in game dev industry) that for entry level job, you should be able to express a solution to a problem in the required language in a reasonable amount of time, nothing more.

Learning new languages is a lot of fun, learning about their idoms. But then, I would have to invest years of practise into them, to get a job with them - to show that I'm good at them.

This goes faster as you learn more languages. Programming is not about coding in a language. Programming is about the skill to turn a problem into a coded solution (at different levels of problems and sub-problems). This skill is for a large part language-agnostic. That means, it's the same for every language. The nice thing is thus, once you know it, you can apply it with every language you learn. This does not hold entirely. Different languages have different primitives, and write things down in their own way (ie different idioms). This part is unique to each language. It is however only a small part.

Don't interpret job advertisements too literally. These things are not a simple go/fail check list. It's a negotiation game from both sides. They have to explain what they actually want to you, you have to explain you can do what they want.

They start high since they want the best. You show to them you can do the job. If you don't meet a requirement, you'll have to come up with an explanation why that is not a problem. Maybe because you have other experience or skills you can use instead. Maybe you have skills they didn't ask. (This is all generic job-advice I can give you, maybe in your country or in the game-dev industry it's different.)

I just find it weird to use C++ on such a project. It feels overkill - if that makes sense. However, as I said above, not using C++, feels like wasting time.

Being able to judge which tool to use at what time is also a valuable skill. In my opinion, it's better than being able to apply a tool at the wrong time (anybody can do that).

You sound to me as being a generalist in your heart. You like exploring new languages, new techniques and new tricks, think out of the box, and find novel solutions to problems. Just because you don't see this in a job advertisement doesn't mean it's not a useful and valuable skill! Job advertisements just don't work like that. They have a plan to use C++ for their project, because that's the best they could think of to reach the end successfully. They know it will work at least, so that's their aim (ie a sound business plan). It doesn't mean they will not look at other qualities that you bring to the table.

Trying to be exactly what a company wants is not going to work. They will change their requirements at any time, by any amount. Today they want C++, tomorrow they may want Java and Objective C, the day after tomorrow they'll want Rust, or Go, or some other language you never heard of.

Don't paint yourself into a corner if that's not what your heart says. Companies are not only looking for a skilled worker, but also for a happy and motivated worker. The latter is only happening if you follow your heart.

Last but not least, do you really want to work in an area you don't enjoy for 50 years?

I'm trying to develop a game and not mess around with graphics rendering

What do you think a game needs except you are going to make a text adventure?

There's a difference between "not messing around with graphics rendering" and "not using graphics". A good engine removes the need to worry about a lot of the low level graphical issues.

This topic is closed to new replies.

Advertisement