programming

  • SWG’s Dynamic World

    Hours Categories Game talk, Gamemaking
    Comments 44 Comments

    This post is dedicated to the memory of John Roy, lead environment artist on Star Wars Galaxies. Help out his family here.

    SWG postmortem series:

    1. Temporary Enemy Flagging in SWG
    2. A Jedi Saga
    3. SWG’s Dynamic World
    4. Designing a Living Society, part one
    5. Designing a Living Society Part Two
    6. Did it fail?

     

    Corellia0023Let’s do some math. Let’s say that you need to have a pretty big world: sixteen kilometers on a side, and made out of tiles.

    A tile needs to know what texture it is. That’s one byte. Not much, right? You only get 256 tiles on a planet, though, which isn’t a lot.

    But wait, we can add some variety there, by putting in some colors. We’re in 3d, right, so we can tint the tiles slightly and get variation. It’s normally three bytes to apply a color, but let’s instead just say that each planet has a fixed list of colors, and you can have 256 of them, and that way each tile can look up into a list of colors and we only need one byte.

    Oh, and it’s a 3d game heightfield, so we need to know what the elevation of the tile is! We’ll just say that there are only 256 levels of height, and that way we can keep it at a nice conservative three bytes per tile.

    Corellia0004That’s good, because we need a lot of tiles. They’re one meter on a side. So that means that for a planet we need 16,384 just to make one edge. We need 16,384×16,384 to lay down the whole world.

    That’s 268,435,456 bytes for this world. Of course, we need ten planets, not one. So, that’s more like 2,684,354,560 bytes. Nobody uses bytes, so that’s 2,621,440k. 2,048mb. 2.56 gigabytes, uncompressed.

    That’s… not going to fit on a CD. I mean, that doesn’t include any art yet.

    DVD drives weren’t yet widespread in 2003. In fact, taking up 2.5 gigs of space just for maps was unheard of.

    Endor0040

    The solution to that problem didn’t just let us ship Star Wars Galaxies, it also unlocked everything from player housing to crafting to giant Imperial vs Rebel battles.

    bullet

    Patent disclaimer

    Before you read any farther, you should know that Sony Online actually patented some of the technology that I am going to describe. If you are someone who should not be reading technology patents, you should stop now.

    Read More “SWG’s Dynamic World”

  • Monkey-X

    Hours Categories Gamemaking
    Comments 10 Comments

    Monkey-X is my current favorite language for doing game prototypes and even full projects. It isn’t at all widely known, and has more than a few rough edges, but I still find it congenial and thought I’d share so that more people will give it a try.

    When I went looking for something to code in, I had the following criteria:

    • Get stuff on screen in under an hour. Ideally, under ten minutes.
    • Output to as many platforms as possible.
      • Web, because that is useful for accessibility, Facebook, demos, and more.
      • Desktop, because that’s where midcore and core gamers still live.
      • Mobile, because the whole world is moving to touch.
    • Avoid porting. Porting is tedious and expensive. Yes, you get the advantage of maximizing use of the hardware, but the fact is that there’s a lot of headroom on hardware these days.
    • A community large enough to supply libraries for things I don’t want to write myself. I am no great shakes as a coder, you see.
    • Syntax that doesn’t make my eyes cross (looking at you, Objective C).
    • Garbage collection. Why? Because I always mess it up, and then it gets in the way of being productive.

    Monkey-X met these criteria, though the community is still pretty small.

    Read More “Monkey-X”

  • Programming languages for aspiring designers

    Hours Categories Game talk
    Comments 25 Comments

    I answered a whole lot of questions on Quora in the last few days, and thought I would share some of them here on the blog over the next little while, since I have been pretty quiet.

    The question on this occasion was, what programming languages should an aspiring game designer learn? And the answers tended to be around things like “C++.” But I suggest a different approach to the problem.

    Learning new things is hard. Programming calls for a new mindset, if you have never done it before.

    Therefore, you should learn whichever one you will stick with. And that means, the one that is easiest for you to learn first. The one that will give you positive feedback quickly.

    Don’t jump to C++ because you are “supposed to,” even if you are aiming at working in AAA console. Don’t jump to C# because it’s the current hotness or what Unity uses. Pick the one that you feel like you personally can make progress in.

    Any good programmer will learn many languages over the course of their career. Heck, I am not a good programmer, and I have worked with BASIC, C, C++, Python, Lua, modern BASICs like Blitz (three members of that family so far), three homegrown scripting lnaguages, JavaScript, PHP, and Java.

    Pick one that is easy and cheap to get started in. It doesn’t need to be powerful, because you don’t know how to use that power yet. Instead, what you want is something that will let you get a picture on screen very quickly. When you are starting out, positive feedback is the hardest thing to come by, because you suck. So you want a language that will make iteration fast and your failures obvious, and your success gratifying to you.

    Don’t worry, you may graduate to a language with greater complexity and power. (You may not… designers don’t need to be great programmers. They need to be able to try ideas out).

    So high level languages will work best for a beginner. I would try out things like

    • Gamemaker
    • Flash
    • One of the versions of Lua with a simple graphics library. I used to use one for PSP homebrew development that had a simple API like “screen:draw(“picture,jpg”). That is the level of complexity you want.
    • Same goes for one of the versions of python with a graphics libray.
    • One of the many BASIC variants aimed at indie game developers: BlitzMax, DarkBasic, whatever. I am currently using Monkey, a cross-platform language by the maker of Blitz.
    • If you have an iPad, a neat Lua variant is Codea — you can code right on the iPad! I’ve used it for a couple of prototypes. There are similar apps for Python, and other languages.

    Remember, your first game is going to be on the order of Hangman, Pong, guess the number, not Uncharted. You want a “toy” language, as the pros will derisively call these., because you want to play around.

    A lot of your game development heroes started out with MS BASIC.

  • Some times you should write new code

    Hours Categories Game talk

    A fair amount of folks have taken the last few posts (on making games more cheaply and on rigid programming philosophies) to a bit of an extreme further than I intended. So in the spirit of contradicting myself, here are some good reasons to write new code.

    When you have something new to learn.

    I still remember how proud I was when I independently invented the bubble sort in response to a problem. Then how baffled I was when I tried to figure out how quicksort works.

    Writing your own version of a known solution is a fantastic learning tool.  Trying to learn how to write jazz progressions? Grab a jazz song, change the key, and start modestly tweaking the chords (an 11th into an augmented, or whatever). Then build your own melody on top of it. Trying to learn how to draw? Start copying people who know how. Trying to figure out how a given game genre works? Try cloning or reverse-engineering a game in that genre. It’s a classic method of learning and there is no shame in it. If you have any creative spark, you’ll quickly move past this sort of journeyman work and start adding your own elements to it. (This is one of my caveats to Dan Cook’s post on game cloning).

    Read More “Some times you should write new code”

  • My biggest coding takeaway

    Hours Categories Game talk
    Comments 11 Comments

    Rigid programming philosophies are the devil.

    Look, I am upfront about the fact that I am not an amazing programmer. I am not even a really competent one. I hack. I didn’t go through a CS degree, I don’t actually know a lot of the lingo, etc.

    On the other hand, I have in fact been credited as a programmer on published games. I have programmed in quite a lot of languages, I prototype my own stuff regularly, and my name is on several technical patents. I seem to have a knack for seeing architectural solutions to problems, and for inventing technical solutions. (I generally prefer to partner with a genius coder for the actual implementation thereof — and have been lucky enough to work with many of them!).

    So take everything I am about to say with the appropriate grain of salt.

    Read More “My biggest coding takeaway”