Categories
advocacy education games design programming

What programming language should aspiring game developers learn in their free time?

I was asked this recently in private mail by someone heading off to University / College. For people choosing between a Computer Science/Software Engineering course vs. a Game Design / Game Development course, I’d said:

If you love games, you’ll do both anyway; one you’ll learn in lectures, the other you’ll self-teach. Which will you find easier to self-teach (given no-one is prodding you), and which will you need the extra benefit of having a formal course/teaching/teachers? (usually: people find it easier to self-teach “designing and making my own game experiments”. Usually, people find formal Computer Science / Maths is ‘hard’, and they need the help of a formal course)

Gross generalization: Most game-developers in the indie community are programmers; most of them are programmer-centric when looking at the world. I’m a programmer, but I’ve done approx 40% of my career in project-management and studio management (and even a tiny bit of publishing) over the years.

There’s one interesting point I want to clarify a little: By “indie community” I mean “focussing on the places filled with people who actually ship games”. Most game designers who want to make their own stuff have to learn programming, even if they’re 100% non-programmers, since it’s the only way to get “your” vision launched. Even the ones that started-off as pure artists often end up being highly technical (whether they admit that to themselves or not).

So … this is not a popular view, but I think it’s more accurate than most: by the time you finish a 3-4 year course starting “today” … C++ won’t be the game-dev language people care about. Already, for entry-level jobs most studios are more interested in “how good are you at Unity? How good’s your C#?”. That trend will only continue/increase.

Categories
iphone programming

iOS Open GL ES 2: Multiple objects at once

Recap:

  1. Part 1 – Overview of GLKit
  2. Part 2 – Drawcalls, and how OpenGL code is architected
  3. Part 3 – Vertices, Shaders and Geometry
  4. Part 4 – (additions to Part 3); preparing for Textures

…but looking back, I’m really unhappy with Part 4. Xcode5 invalidates almost 30% of it, and the remainder wasn’t practical – it was code-cleanup.

So, I’m going to try again, and do it better this time. This replaces my previous Part 4 – call it “4b”.

Drawing multiple 2D / 3D objects

A natural way to “draw things” is to maintain a list of what you want to draw, and then – when the OS / windowing library / whatever is ready to draw, you iterate over your “things” something like:

Categories
iphone programming

OpenGL ES 2 for iOS: glDebugging and cleaning-up our VBOs, VAOs, and Draw calls


UPDATE: This post sucks; it has some useful bits about setting up a breakpoint in the Xcode debugger – but apart from that: I recommend skipping it and going straight to Part 4b instead, which explains things much better.

This is Part 4, and explains how to debug in OpenGL, as well as improving some of the reusable code we’ve been using (Part 1 has an index of all the parts, Part 3 covered Geometry).

Last time, I said we’d go straight to Textures – but I realised we need a quick TIME OUT! to cover some code-cleanup, and explain in detail some bits I glossed-over previously. This post will be a short one, I promise – but it’s the kind of stuff you’ll probably want to bookmark and come back to later, whenever you get stuck on other parts of your OpenGL code.

Cleanup: VAOs, VBOs, and Draw calls

In the previous part, I deliberately avoided going into detail on VAO (Vertex Array Objects) vs. VBO (Vertex Buffer Objects) – it’s a confusing topic, and (as I demonstrated) you only need 5 lines of code in total to use them correctly! Most of the tutorials I’ve read on GL ES 2 were simply … wrong … when it came to using VAO/VBO. Fortunately, I had enough experience of Desktop GL to skip around that – and I get the impression a lot of GL programmers do the same.

Let’s get this clear, and correct…

Categories
iphone programming

Why is a Fragment Shader named a Fragment Shader?

I’m writing some KISS tutorials on using OpenGL ES 2.0 in iOS/mobile, because I was frustrated that most of the tutorials on GL ES used incorrect or outdated approaches.

(I’m using the OpenGL ES 2.0 Programming Guide as my baseline, along with my own experiences of game-programming, and checking it all against Khronos Group / OpenGL.org’s docs as I go)

I use this stuff in iOS apps, but … I’m a relative novice with shader-pipelines. So I’ve been leaning on the guys at The Chaos Engine for proofreading and to help me avoid spreading misinformation. Most stuff people broadly agree on, but there’s been some interesting debate over a seemingly trivial question:

Why does OpenGL use the term “Fragment Shaders” to describe the shaders-that-generate-pixels? (where other API’s call the same thing “Pixel Shaders”, a much easier to understand/remember name)

Categories
iphone programming

iOS Open GL ES 2: Vertices, Shaders and Geometry

(this is Part 3; Part 1 has an index of all the posts)

We finished Part 2 with the most basic drawing of all: we filled the screen with a background colour (pink/magenta), but no 3D objects.