szecs

Thanks everyone. I'll do more research on ME to see if its for me. But if I major in one and minor in another would there be too little free time for game dev? This is what I'm afraid of.

 

Engineering majors barely get free time. I don't know about you, but I def. would not feel like coding after studying some vector dynamics or mechanics of materials.

Brain draining major + brain draining hobby = burn out

I had plenty of time there, and I learned in the system before the Bolognese system (so the same amount of learning in 10 instead of 11 months).

It's only that power draining if you go for a summa cum laude. You don't have to be an eager-beaver though. The eager-beaver always-learning guys didn't get any further than us, who just did the job and only excelled in some areas.

The job: I don't know about other countries, but it pretty easy to get a job that's not so demanding and it's not more than 40 h/week. I heard quite the opposite from programming jobs though (>40 h/week)

I'm not a particularly smart person. If I could do ME and game programming at the same time easily, pretty much anyone can do so. And as I read these burning-out threads here, I can say it's much easier to burn out from coding than from ME, because you can choose from a lot of esentially different jobs in the ME field. Whenever I fealt that I'm burning out form a particular set of tasks, or there was any other issues, I could easily find a better job in 2-3 weeks. Can you do that with programming?

Another thing: to my experience, i't quite easy to swith from ME field to full-time programming jobs, because programming is less about paper. I'm actually rejecting programming jobs, I could switch almost any time I wanted. I don't think you could do that the other way, you can't really get ME jobs without the paper and education.

I'm not in the same situation, but I graduated as a mechanical engineer and did (do) game programming as a hobby. If you are not sure about a career and that you'd enjoy coding >40 hours per week then maybe mechanical engineering is a better choice, since it's easier to get various (easy or more demanding, creative or non creative etc) jobs in that field. And definitely easier than getting a game programming job.

Working as a mechanical engineer can also be a good base for some own little game programmer studio, since it's pretty good paying.

This path works pretty good for me, though I only started programming after starting college.

This is precisely what happened in music with the development of music theory. By learning about music theory (which is a standard part of music school) one learns about all of the guidelines about how to compose music that sounds good. One learns about all of the patterns in harmony, voice leading, chord progressions, structures, and the like. By using a set of rules which consist of patterns that have been time tested, this takes away a huge amount of guess work in the process of composing a piece. With music theory, it's possible to compose a piece that sounds good without ever needing to sit down at an instrument to hear it. When the same thing happens to game design, it will take away the need for all of that guess work, trial and error, and iteration that happens in the studio. It will be possible to put together a detailed design document of a game that works great before even needing to step foot in the production studio. This process of developing game design theory is already happening, with the help of people such as those at Extra Credits, and Errant Signal.

This is a question of preference.

The best musics I have ever heard are never one-composer musics.

Can we get over this music analogy by the way? Half of the bulk of the thread is about refining this analogy that is set for what reason exactly?

It's just lazy/coward/deferring not to try out the ideas from the beginning.

 

While it is certainly true that you can produce a painting in a free and almost improvisational manner and make up the details as you go, this is not how the Old Master painters created most of their works. Perhaps you don't quite understand the scale of their paintings or the techniques they used. Take for example, Rembrandt's "The Night Watch" - it is a painting on a massive scale. Before he applied a single stroke of paint, he had already worked out just about every single detail of the painting with the use of many pencil sketches and colour studies. He would have then created a final pencil draft with all of the details in place (except, perhaps for mechanical details such as textures of cloth. But even then, he would have worked these details out in his head at this point) He would then transfer this drawing onto the large canvas, up-scaling it in the process. Then, and only then would he begin to apply the paint, but still working from that final pencil draft he created earlier. Also, for the painting process itself he would have used something similar to the Flemish technique for applying the oil paints. With this technique he would have built the painting up in layers, letting the paint dry in-between layers before applying a new layer.

This is what iteration and prototyping means. No one said that you have to start implement the final application from the beginning. This means tons of thrown away code, and (in an ideal world) none of the prototype code will stay in the final code. Sometimes (very sometimes) after everything is fell into place, the whole thing is reprogrammed from zero (...).

The painters did not only make all the details in their mind, they actually implemented tons of the ideas and iterated through/on them (sketches and color studies) and they were not physically used in the final product.
 

In programming, sketches mean not only art sketches and game-play idea sketches, but sketches mean some playable stuff too. Be it a table game or actual coding.

You are stuck to the painter analogy too literally.