New Coding Paradigms

So I’ve recently been thinking that the whole idea of editing text files filled with code is outmoded. When I’m thinking about code, I certainly don’t think of it as a set of classes and functions laid out in a particular order. I think of it as a cloud of entities with properties and interactions flowing between them. Shouldn’t our experience of writing code reflect this?

We need to start rethinking our code-editing tools. A lot. Here is a simple example:
XML heatmaps

What else could we do? How about the ability to arbitrarily break off chunks of code and view them in parallel, even nesting this behavior to break long blocks of code into a string of chunks:
Nesting chunks

What if we let the flow of the documentation decide how a reader is introduced to the code base, instead of letting the flow of compiler-friendly source files decide it? Chunks of code are embedded within wiki-style documentation, and while you can follow the code back to its source, reading the documentation will eventually introduce you to the whole codebase in a human-friendly fashion.

The same code could even appear in multiple places (obviously updated when the source changes), and you could see all the places in the documentation where a particular chunk of code appears. This could bridge the gap between documentation and code; documentation will never grow stale, as updating code necessitates interaction with it. Similarly, updating documentation is the same process as writing code. When a standard changes or an SLA (service level agreement) is modified, the code changes too.

But why restrict ourselves to semi-linear, text-based documentation a la wikis? We tend to find UML diagrams extremely helpful for visualizing complex systems in code. What if we could build powerful, adaptable tools to translate between raw code, text-based documentation, and visual diagrams? Strictly binding them together might restrict you in the lowest levels of coding (much like, for example, using a high-level language restricts your ability to control memory allocation), but it opens up the new ability to make changes to a diagram and have most of the code rearrange and resolve itself before you. Then you step in to give a guiding hand, and adjust the text documentation, and voila! Best of all, this is more than a diagram-to-code tool; the diagram is a living thing. In fact, the diagrams, the documentation, and the codebase are synonymous. A change in one is a change in the others.

We’re getting to the point where it is much more useful to be able to dance across a codebase quickly than to be able to tweak and tune the minutiae of your code. Some allowances must be made for processing-intensive applications. Perhaps this system wouldn’t even be useful in those cases. But when you find yourself favoring adaptability and iteration speed over efficiency during development, and when you find yourself being hampered by the need to go between files, scroll through large swathes of code, or referring back and forth between code and documentation, maybe it’s time to rethink your coding paradigms.

Advertisements

Trapped between Eye Candy and Motivation

There’s this really big problem when it comes to working on games (or really any sort of project that lies at the intersection of engineering and design). It has nothing to do with programming or design or testing or art or sound or anything else like that.

The problem is staying motivated. This is especially bad when you are working alone, but it can even happen in groups of 2 or 3 people. Beyond that, you can always find motivation in the stuff that other people are doing, because it comes from outside of your personal drive and creativity. But in small groups or solo projects, the game becomes your baby, and then you get tired of your baby.

Sometimes this happens when you work so long on one subset of features that they sort of blur together and become the totality of the project to you. You quickly get tired of this smaller sub-problem (especially tweaking and tweaking and tweaking), then get tired of the game without realizing there is other interesting work to be done.

Or maybe you realize that there is a lot of stuff to do on the project, but you’ve been working on it so long without much visible or marked improvement that you begin to despair. Maybe the project will never flower, you think. Maybe your efforts will never be used to the full extent they were designed for.

Wherever this loss of motivation comes from, there is one piece of advice I heard that really helps me. It boils down to this: if you keep wishing your game was awesome, make it awesome. Add in that feature you keep thinking about, but keep putting off because there is more important framework-laying to do. Or take some time off and mess around with that one technical gimmick (shader, hardware stuff, multi-threading, proc-gen, or what have you). When you feel yourself losing motivation, give yourself permission to go off and get it back. Don’t soldier on, because your project will inevitably end up on the dump heap with all the other projects you abandoned.

The only problem is, everyone (including myself) always says that adding eye-candy and little trinkets to your project prematurely is a Bad Idea. If you make your game cool by adding eye-candy, the wisdom goes, then your game is no longer cool because of the gameplay (you know, the point of a game). Arguments about whether gameplay is important not-withstanding, if adding a few bits of visual indulgence saves your game from succumbing to ennui, then by all means, add the cool things!

From Light

I haven’t posted in a while, in part because I’ve been busy with a lot of things. Maybe I’ll make posts about some of those other things at one point, but right now I just want to talk about From Light.

Logo for the game.

From Light is a game that I have had the pleasure and honor to help develop. It was originally created as a class project by two other students, but when it showed promise they decided to develop it further. Our team has now grown to 10 people, all (save one) students at USC.

The game is a 2D puzzle platformer based on long-exposure photography (holy hell have I said that line a lot). Basically, you can etch out light trails onto film using the stars in the sky, then jump on those trails to navigate the levels.

I mention that I’ve said the above line a lot because the game got accepted into the PAX 10 for PAX 2015, and I went up to Seattle last weekend with 3 other teammates to show the game off at the four-day gaming convention. This, you may have gathered, is completely and mindbogglingly awesome. I get to work on a game that is recognized and validated by real-world people! And truly, the reception of PAX was way more than I ever would have expected. People frickin’ loved the game!

 PAX 10 Logo  Photo of us at the booth.

And at PAX one of the things I heard again and again was that taking a game to completion, to the point where it could be shipped and sold as an actual game (y’know, for money), is an invaluable experience. Not only do you get a sellable game and a fantastic line on your resume, you also get all the experience involved in taking a game from 80% to 100%, and all the non-development business stuff involved in getting your game out to consumers. Needless to say, this convinced me that we should take From Light to completion. Before, I had been hesitant because as students it was unlikely we could put in the time to finish it fully. However, I am now willing to work harder than I have ever worked before to finish this game.

I’ll continue to post either here or on Gamasutra about development (both technical and non-technical posts), so make sure to look out for that.

In the meantime, if it strikes your fancy please “like” the game on Facebook, or follow us on Twitter, or just download the game from our website.

Execution vs Conception

I love having ideas. Ideas are fun, manipulable, infinitely complex or simple. They don’t take any work to think about, expand in breadth and depth. It doesn’t take effort to plan execution. Much like calculus, the manipulation of abstract possibilities is fun and easy. Once it gets to the actual computation and execution, though, the process becomes less fun.

This is why I experiment with so many engines and SDKs, and why I draw and write much more than I model and map. It is enough to know that I have the skills to do (or figure out how to do) what I want to do. If carrying through and actual doing the boring grunt work isn’t fun, why should I do it? That said, having a final product is the most satisfying thing in the world. When an external motivator hits the project, like money or responsibility or grades, I am motivated to work through the grunt work. Then I get to stand on the other side and beam at my beautiful realization of an idea.

Carrying this through to its logical extreme, I feel like the best way to force myself to produce a final product in the real world is to throw myself headfirst into the deep waters. If I make game creation my livelihood (and preferably a few other persons’s too), a final product will emerge in due time. If I keep it as my hobby, my ideas will never get off the ground floor — at most I will get some proof of concepts, or a half-completed level.

Into the Unknown: UDK Part 1

I tried this before, but ended up quitting. I believe now that my exit was premature. I refer of course to my adventure into the Unreal Development Kit, a free version of the Unreal Engine that allows developers to create their own games in the Unreal Engine.

My reason for embarking on the adventure was to recreate the gameplay from Halo: Combat Evolved on an updated platform. The bonus is two-fold. For the longest time, I have had a Halo custom campaign in the works, but have never really gotten the Halo Editing Kit tools to work for me. Secondly, I have always felt the need to learn how to use a 3D game development tool. After exploring Unity slightly and having dabbled in CryEngine 2 (and somewhat 3), I decided it would be good to experience the Unreal Engine.

Posting updates on this blog serves two purposes: One, it keeps me from giving up again. Second, it helps me quantify my successes and organize my thoughts. Hopefully I can post an update on this project every two or three weeks, with either video or pictures to show off new milestones.

Without further ado, I want to outline some of my goals for the upcoming project:

  1. Learn how to create:
    • particle effects
    • weapons
    • vehicles
    • characters
    • AI behavior
    • scenery
    • level geometry
  2. Learn what else I need to learn

Javascript

Honestly I’m not sure who thought it was good idea to make this language. I’ll admit its better than PHP, and I understand that some people actually enjoy using it. For instance, there is a web server written completely in JavaScript (hence my comparison to PHP). This boggles my mind.

My main issue with it is that there are no high level features built inherently into the language. For instance, there isn’t even an agreed upon method for importing other JavaScript files. Inheritance? Going to do some pretty messy hacks in order to get something that acts like an inheriting class structure. How about maps (aka dictionaries)? Objects and maps are the same thing. Arrays are basically just hash-maps for non-negative integers.

I suppose it’s about interesting exercise in thinking. Treating every structure (including classes and functions) as variables had its upsides. Ultimately, though, you have to use it whether you like it or not. There’s no substitute for the client-side functionality it provides. CSS can only go so far. When you start looking at something like AJAX, it makes you cry simultaneously at the pain of working with it and in joy for all the opportunity it provides.

The reason I have been thinking about and working with JavaScript (although only dabbling, of course) is that I’ve been taking another course at Udacity. This one is on game development in HTML5. Before this course, I really had no idea what HTML5 was. I had heard it mentioned, but then it all blew over. HTML5 is, to the best of my understanding, a standard that introduces some new HTML elements and JavaScript standards that lets developers manipulate pages in more creative ways.

For closing thoughts, I’ll leave you with this hilarious “talk”:

StackOverflow

<3 StackOverflow

This is my homage to that wondrous site. Well, it usually helps. To quote Shamus Young from his dev blog.

Right off the bat, I can see something is wrong here. These docs on GLSL are an absolute mess. The wiki is even worse. If you ever Google something and find forum posts listed above the official documentation in the search order, you know you are sailing right into the inky black void near the edge of the map, a place that would be labeled “here be dragons” if not for the fact that the link to the map itself is a 404.

Searching for example programs isn’t very helpful either. There are two kinds of example programs:

Ultra-simple test programs: Here is how to create a flat-shaded, un-textured, colorless, unlit polygon. These little three-line programs can’t teach you anything because they don’t DO anything.
Super-complex programs for a very specific purpose: Here is how to do toon shading on a bump-mapped, multi-textured, reflective surface with a specular map and fresnel shading. These programs are just pages of un-commented equations and are too advanced and specific to be used to learn how to do anything.

Which leaves us with forums. Here is how things work on programming forums:

ALLEN: Hi, I’m new to driving and I need to move my car back around 5 meters. How can I move the car backwards?

(2 days later.)

ALLEN: Hello? This is still a problem. I’m sure someone knows how to do this.

BOB: I can’t believe you didn’t figure this out yourself. Just take your foot off the gas and let the car roll backwards down the hill. Tap the bake when you get to where you want to be. Boom. Done.

ALLEN: But I’m not on a hill. I’m in my driveway and it’s completely flat.

CARL: Dude, I don’t know what you’re trying to accomplish, but you should never be driving backwards. It’s dangerous and will confuse the other drivers. See the big window in FRONT of you? That’s your first clue. Don’t drive backwards.

ALLEN: I’m not trying to drive backwards. I just need to move back a little bit so I can get out of my driveway and start driving forwards.

CARL: So just drive in circle until you’re pointed the right way.

ALLEN: I don’t have enough room to turn around like that. I only need to move back a few meters. I don’t understand why this has to be so hard.

CARL: Sounds like your “driveway” isn’t compatible with cars. It’s probably made for bikes. Call a contractor and have them convert some of your yard into driveway to be standards-compliant with the turning radius of a car. Either way, you’re doing something wrong.

DAVE: I see your problem. You can adjust your car to move backwards by using the shifter. It’s a stick located right between the passenger and driver seats. Apply the clutch and move the stick to the “R” position.

ALLEN: But.. I don’t have a clutch. And there isn’t a stick between the seats.

CARL: Sounds like you’re trying to drive in Europe or something.

ALLEN: Ah. Nevermind. I figured it out.

“Hold on, Matt,” you say. Or maybe “Hold on random Internet guy,” if you feel so inclined. “You haven’t actually written anything yet in this post!” True. You know what? I have a bunch of half-written blog posts, and they all SUCK. So this is the best you are going to get for now. Also:

Punctuation shouldn’t go inside quotes. That is STUPID.

He could say “Stop!,” or “Eat cold steel!,” or “If you move, the planet will explode.;” instead he chooses to scream incoherently and spazz out on the floor. Wait, maybe that wasn’t a choice. The other guy is holding a taser.

That sentence looks retarded. It should be:

He could say “Stop!”, or “Eat cold steel!”, or “If you move, the planet will explode.”; instead…

Doesn’t that just look so much better? Obvious solution: start an Internet petition to change English.

%d bloggers like this: