game development

  • Stars Reach visual upgrades

    Hours Categories Game talk, Gamemaking
    Comments 2 Comments

    For months now, we have been working on a big overhaul to the visuals in Stars Reach. This has involved redoing most of the shaders in the entire game, and going back and retouching every asset. We started by redoing all the plant life and flora, and we have hundreds of those assets that had to be redone.

    Further, they all need to grow, change in response to seasons, be able to catch fire and burn, freeze, shed leaves and die, and so on. We don’t pre-design our biomes; we derive them on the fly from the simulation based on the environmental conditions. The right plants grow in the right places based on the temperature and the humidity and the soil types. (Yes, we even have a dozen soil types).

    Read More “Stars Reach visual upgrades”

  • On getting criticism

    Hours Categories Game talk
    Comments 54 Comments

    Lately I have been working on multiple new games. And whenever you are working on games, of course, you get people to try them, and a lot of them don’t like what they see.

    I’ve gotten a lot of criticism over the years, and I haven’t always taken it the right way. These days, criticism comes from all directions, and work is often shared before it’s really done. It can be hard to know what to listen to and when to stick to your guns.

    Ultima Online is a Hall of Fame game. It averaged 6/10 in reviews. Star Wars Galaxies got a famously mixed reception, and closed down a while back; I still get fan mail.

    So here’s my takeaways from all those years of being told that my work sucks:

    Everyone who dislikes your work is right.

    Read More “On getting criticism”

  • Fun vs features

    Hours Categories Game talk
    Comments 12 Comments

    You have a system. Let’s say it’s a system where you can throw darts. And you have to open your bar in one week.

    Throwing darts might have a bad interface. The dartboard might be too small or too big or poorly lit. Darts may be a perfectly nice idea, but the implementation of it needs tuning.

    At this point, you have a feature, but not fun. It’s gonna take you four days to make it fun.

    Read More “Fun vs features”

  • 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”

  • More on making games cheaply

    Hours Categories Game talk
    Comments 4 Comments

    I only offered 6 points, but 3 of them are ones that people are wanting to argue about! 🙂 I suppose that is a pretty good hit rate…

    A few folks took exception to my comment that “code doesn’t rot, our ability to read it does.”

    The first objection is that most code is born rotten, that it is rare to find code written to the standards that allow it to be easily maintained. I can’t really argue with that, though of course there are plenty of practices that ameliorate this: code reviews, code standards, etc. I’d answer with “that’s just code where our ability to read it perished as it was being typed.”

    The second objection is basically that platforms shift out from under code. This is absolutely true — but is also a sign that you’re not actively maintaining your codebase. Times of truly catastrophic platform shifts where everything you did is invalidated should be relatively rare these days, honestly.

    Read More “More on making games cheaply”