Any tips to go from "scripting" to "programming"?

Fair enough, I just think the whole process could be made incredibly more efficient if it was a lets say 50-50 split between classroom and work experience as an undergraduate, and especially if the classwork was immediately reinforced in a workplace setting. I'm all for difficult and lengthy training but IMO too much of it in the classroom is irrelevant, abstract, easy and quickly forgotten.

 

I had one professor who scribbled running writing onto a sheet of paper before class, whacked it under a projector and basically read from it during class. I actually slept there a few times, I'd just wait until a week or two before exam, memorise the stuff and nail it, and the material was never seen again.

I have to say there were quite a few good teachers, but unfortunately their efforts were undermined by total lack of learning reinforcement.

 

I am going to disagree with this(ish). BUT, I must qualify with the fact that I only have one point of view on this. Where I am now is the only place I have worked that brings interns directly into development and art roles. I am completely ignorant of how it works elsewhere, I assume ours is the exception, not the rule.

Intern season is starting up right now for us, many interviews every day. We take on about a dozen-ish mostly art and engineering, we had TAs last year, a couple of designers and producers. Most are undergraduates, and most from Stanford and some from CalArts. There were thousands of applicants, I only saw the last few rounds (hundreds). Given the scale of the pool, and lot of the time these internships are direct paths into the house of D. (pixar, lucasfilm, disney, marvel, ect), The ones that make the cut, seriously kick ass. Dunno if it was good schooling or the folks were just passionate. They know what they need to know and now it well and have often built several games. They are here to a) work on star wars stuff) and b) see how a studio workis IRL We keep about half if we have the slots, or help them get to our sisters like Lucasfilm, Pixar or Glendale. Again, am guess you are generally correct, and we are seein the exception either because of the sheer scale of the pool, or the schools are really good, and desirability of working here.

 

Yeah I'm in the habit of talking in generalizations without making it clear I don't mean that graduates know absolutely nothing, but rather have not made anywhere near the best use of 4-5 years of their lives, and still have to be taught a lot. Australia has had a few problems with the quality of its education at high school onward and there are big issues bridging the gap between a shortage of engineers in the industry, and a high number of recently graduated unemployed ones, as well as the ease of bringing in skilled migrants.

I imagine that Standford and CalArts would be high quality, for example in Australia the University of Sydney is very well regarded. I went to Griffith University which is around average from what I hear, and I was very disappointed with how useful it turned out to be for me.

Also, everyone wants to work with you guys so I imagine you've got the ability to really pick and choose.

 

If I'm being completely honest, when you talk about your work, I must admit feel inappropriate jealousy. About two years ago, I was working on the environmental effect that accopmanies Darth Vader's say saber attack. A small whirlwind of pinning dust, some flying debris and other visuals, an effect that lasts 15secs. Somehow I managed to place the whole effect package on itself as a sub-emitter at on birth. It replicated rabidly, seized the display and cooked the phone (4 or 4s). Bloated and bricked it. That, I believe is the most danger possibile at my job. Yours is cooler, just because of the amount it damage you can do. Uncomfortably hot is the upper limit for us in terms of damage.

 

There are some perks. Knowing that at some point I've messed with the food chain of pretty much every one on the planet is cool. And there are some small things that I'm the world expert on. Being the first in the world to make something ever is pretty heady.

Knowing I can blow things up just keeps me awake at night. I do take comfort that I'm pretty good at making things not blow up. I have a massive support system of other engineers and associated professionals that also helps to not blow things up. But it still can happen.

What I'm jealous of on your side is the freedom. Currently half my work is satisfying external regulators. To simply move a bolt I have to get it reviewed by another engineer. It's a common joke to ask someone if they got all the proper permits to turn on the light, or if they have a done a risk assessment before using the rest room.

But anyway, each profession has its ups and downs. And I can't really complain if I'm not going to do anything about it.

 

Do you mean you found a method to physically brick an (old?) iPhone? Because if so, that is something I'm sure is only a question of time till crazy people try to do that on purpose to unsuspecting users.

 

It doesn't have to be game dev specific. While game-dev specific programming and software design skills certainly exist, to a large degree the stuff you're asking about doesn't have to be game dev specific.

I wouldn't call it a cure, but generally taking an interest in your craft and, you know, reading about it seems to have got me and plenty of others a heck of a long way. I don't even actually read that much. I doubt I'd average more than an hour a week on it.

Yes, that's a silly thing to do. Thankfully reference manuals are but one of many kind of books (or learning resources in general) available to us.

 

Yeah this is a rule I follow. I take it onboard but not with high regard... it's like two levels below Wikipedia. I also know some people post without linking games they have made or been part of because of contractual/just don't want people to see. Also just because someone worked on something great doesn't mean they are any good...Lot's of people work on games and at some studios incompetence can go under the radar.

For example I take all VR stuff with a grain of salt especially if they have "VR expert" in their title They either have no idea because the industry is too young or they have no idea because they developed pre-rift and were part of "that" stuff.

EDIT: I know how ironic this post is

 

Clearly that title belongs to angrypenguin.

 

@Not_Sure what kind of college was it? If it wasn't a university (non-biased, based on experience here) I'm not surprised. Two year schools are not the place to learn how to program a computer.

I had almost the same experience with the teacher who taught my last programming class at a two year school. I hated this instructor, because she was awful and evil, but that aside, I had never programmed in Java before but it is so similar to C++ and I knew a fair bit of that I was helping other students in the class at her level.

I judge people by their character, and little else.

Even universities are not the place to learn to code. Many of the classes are geared toward learning concepts and improving areas of expertise which may come in handy in the software development field, but not crucial to coding. Sure there's a programming course or two, and those usually weed out the one's not suited to be Computer Scientist but they aren't in place to develop a passion or even much skill with it.

I noticed that some of the people in my class, and judging by stuff I've read about University graduate's in CS, a lot of them graduated with the core concepts of CS, but not much in the way of coding skills.

I know its a contradiction, and hard to believe, but a university (four years) cannot teach just programming during that entire time.

 

Is programming really that hard?

Maybe I've just lost sight of things, being that I've been doing it for like 20 years, but if anything - I feel like the biggest problem with most code is that people usually deeply over complicate the problems they need to solve.

I was looking over my code base earlier today. I honestly think just about anyone could jump on board and understand what I'm doing in a few days or figure out where stuff is and how it generally works. A lot of the results are pretty sophisticated I think, but the code itself is written about as straight forward as I could possibly manage.

Maybe it's just been too long since I worked with other people, and I forgot how much trouble people can have with code. But like how to write easy to maintain code in 5 easy rules:

- Don't over engineer stuff
- Have a clear understanding of your goals
- Be consistent enough in where you put stuff that you can find it later
- Consolidate all of the logic for a given piece of functionality when possible
- Don't use an overly formal structure without a good reason to (no you don't need a formal state machine for that).

That's about it...follow those steps. Avoid 3rd party APIs that force you to introduce unnecessary abstractions or violate any of the above rules.

I'm pretty sure that 90% of the bad code in the world is people trying to "write good code" and using approaches or abstractions where they don't belong and don't bring value (which is most of the time).

But maybe I've lost sight of stuff and I'm taking decades of experience for granted. It's possible.

 

I definitely agree that you can go overboard applying fancy approaches. My rule of thumb is to ask myself which approach is easiest given the expected course of the project, and use that. Sometimes that means a lot of architectural work, sometimes it means a quick bit of "caveman code" and a few public variables.

The *only* reason to increase complexity of something now is to *decrease* complexity that will otherwise arise later.

As per one of my favourite quotes:

 

One of the main things you can try is forgo all the time savers and do it the old way. Create your own game framework.!

When you start working with OS based UI's / file systems / direct X or GL / feature sets yourself. It will expand all round knowledge vastly. Modern engines are here to save you time, although it makes assumptions that you already know the fundamentals / intermediate basis of a wider scope.

Most will skip this step and you can to a certain extent get away with it, until you want to do something slightly out the box and / or complex. Then you'll be fighting not only against the engine but your own knowledge gaps..

On top of that, never restrict yourself to one engine. There's so many ways to skin games development and some of the best coding examples I've learnt is from middleware or AAA engines. It's a goldmine of information and shows ways to tackle things you'd never even thought of.

YT Bennybox, he has LWJGL examples of bulding your own framework / engine and it's very good.!

You'd be suprised after doing all that how simple things seem.

@frosted

I think you're bang on the money. Code needs to do three things, work efficiently, be readable and not break your game.

There are plenty of potential ways to consolidate code, so it stops you from having to write as much. That comes with experience, keep learning and you'll find quicker ways to do the same thing, apart from that it doesn't really matter.

 

...Because you didn't start out as a programmer. You started out with ez-mode enabled. A while back, I remember I was very adamant about telling people, "Learn C first!" And I got a lot of backlash.

Right now your understanding of what is happening when you write code is a completely arbitrary abstraction built upon several layers of abstraction. So, it makes it difficult for you to understand what your data is, where it is, what form it is in when it is in storage, how it is accessed, etc. All you have been taught so far is "If you do A then B happens", albeit on a much grander scale.

This creates one problem in particular... your are unable to think outside of that box, because that box is the only thing keeping your programs together. Take one step outside that box and attempt to serialize a data structure, and you have to choose between a binary and an xml formatter... and you're screwed because it will take hours of research and experimentation to even get it to work. Unless you copy and paste a code example and it works, but then... good luck modifying it. You just keep making your box bigger, but you're still trapped in a limited box.

Now, take the safety mechanisms off, remove the box, put yourself in the "unsafe" world of accessing files and addressing things stored in memory, start getting cozy with bits and bytes and begin to understand the machine you are programming, and you will have an advantage because guess what... every concept in computer science is built upon the fundamental concepts of computer operation. All the way up.

And guess who built the language you're writing in? Who wrote those libraries that do things you don't know what the hell they even do? Computer science majors.

Just take all of the frustration you're feeling and think about how it feels.

Then go fire up a C++ compiler console application and follow along with a series of tutorials like "Learn C++ the hard way", those are very detailed and he tries to kick your ass into learning.

It all starts with a strong grasp of the fundamentals.

After that, then you are going to graduate to learning about Software Engineering. That's the key, buddy. Remember those two words. Software Engineering.

Programming is a fun little hobby, you can come up with some real brain busters and when you are working with enormous data sets or on computers with limited resources, having a brilliant programming mind is essential. I'm sure UT employs lots of fantastic programmers.

But you and me? We aren't just interested in programming. We need only moderate programming skills. What we're really interested in when it comes to games is making lots and lots of small sub-programs work together to make a machine that is constructed entirely out of data operate... in other words, we are trying to use our programming skills to build something of real value, here.

I would just change my thread title to "How can I learn to engineer software?"

Then you're on the right path.

Prepare to read books by a lot of people way smarter than you who are very open about their interests in medieval fantasy and Star Trek. But just a small amount of learning about software engineering will expand your mind and improve your code base so immensely that you won't even believe it.

Anyway, if you have any questions, you can PM me. I had the exact same problem you are having before. Then, in my game, I wrote a code that uploads scores to a PHP file and then that PHP file accesses a MySQL database and creates a new entry and another script that retrieves the scores in order and shoots it back to the game, which can then display the high score table... I could have never done that if I didn't start all over with my learning.

 

My tip on how to learn to design software:

Focus on writing good documentation. Don't code anything until you have your docs highly polished. When you can write great docs and make great charts you will be doing well.

 

I've never subscribed to learning before I have a purpose for it. Instead I learn on the job, I have a job that needs a solution (give myself one ie a game) and therefore get off my fat arse and solve it.

It's really that simple. For example you're stranded on a desert island and there are trees, fish etc. You can clearly see stuff, and you can understand there's probably stuff you can't see. Start surviving.

 

I'm the opposite. I love learning for its own sake. I find learning a new skill or knowing a new thing to be valuable in its own right.

Looking back on my own history I tend to find different programming areas often feed off of each other. Programming games helps with programming excel macros in my day job. Programming Access databases brings some random insight when programming a PLC to control a chemical pump. Programming HMI feeds back into building decent UI for my games. These are just a few examples. But learning and experimenting with different paradigms is valuable.

 

Also same.

I do it because I love it. The industry, the inovation, the community, the creative expression. I love it all!

 

That makes perfect sense. If you think about it there are actually quite a few common traits that carry over from game programming to non-game programming. At a basic level we're really just dealing with data, storing it, editing it, creating it. Obviously in games we tend to do more with that data in different ways, but so many elements carry back and forth that there's no reason being fluent on one side wouldn't be beneficial to the other.

 

just so you know this phase shall pass



https://www.vikingcodeschool.com/posts/why-learning-to-code-is-so-damn-hard

the job ready is just what seems to be good state of being so you can ignore that, but I just recently got through desert of despair and it feels great

 

I think one problem I have is that I'll throw together a script and tweak it until it's fun. Then I get side tracked playing around under the guise of "tweaking".

I must have put in a hundred hours "play testing" Bravely Bear.

 

Getting around this problem is one of the important step on the way to becoming a programmer.

When you can silence your inner perfectionist, and that inner "guy that gets fascinated with complex problems", AND manage to concentrate on getting things done to the point where they're good enough for the situation at hand... then you'll improve.

 

This is a good way to look at it. Programming is about solving problems. The fundamental programming skills are mostly around defining problems and figuring out solutions to those problems. Coding is really secondary to this, its a toolbox of skills and techniques to draw from. But the point should generally be the problem, rather then code for its own sake.

 

honestly, I don't think it's a bad thing, some things do indeed require alot of tweaking to feel just right, specially if it's something critical like movement.
If you notice though, that you are tweaking to avoid some new "scary" task that you want to get into, THEN I would suggest that you do something about it everything that looks big and scary, is just looking that way because you don't know exactly what you need to do and usually also because you have a too big and too abstract of a task. Which needs to be split into eatable chunks (am I close with that assumption?XD)

 

I don't like this picture as it suggests that you'll know when your job ready and that just isn't the case. Most people have no idea when they are good enough to get a job until they get one and say "I guess I'm good enough".

 

yeah I don't really agree with it either it also feels kinda artificially added to that graph, while what you just said is more fitting

 

That's true, but there's only so much useful tweaking you can do without proper play testing, and by "proper" I mean "based on observation of people who are not already familiar with the game".

 

Try writing a simple game from scratch like Naughts & Crosses (Tic-Tac-Toe). I would suggest someone "good" at programming would be able to make such a game in a day or less. An experienced programmer should be able to make such a game in under an hour.