Earlier this month, I attended a local game jam called Cool Jams, Inc., which was inspired by (and not necessarily affiliated with) Polygon’s CoolGames, Inc. podcast. The premise of the podcast is to take terrible game ideas from Twitter and flesh them out into a playable game design. The jam’s premise was for people to take random ideas from the show and actually build them, while often adding their own spin to them. The event was hosted at Seattle’s own Indies Workshop, with an itch.io page for submissions.
I was really looking forward to this jam, mostly because I knew a lot of people who’d be there and I was looking forward to hanging out with everyone. I’ve participated in tons of game jams before, so I was excited by this jam’s change of pace. In that spirit, I decided ahead of time that I wouldn’t use Unity for this project. I was originally thinking of using Flash and ActionScript 3.0 just for nostalgia’s sake. But then my friend Blake O’Hare jokingly suggested that I use his Crayon programming language, and I thought, “sure, why not?”
Crayon is literally a programming language that Blake made. It’s not a library. It’s not a translated language. Crayon projects run on their own VM which can be exported to a variety of platforms including Web (JS & HTML5), C#, Java, Python (PyGame), and Android (still experimental). I’ve seen Blake make some pretty cool games using Crayon, and the idea of trying it out sounded pretty fun.
If you search online for “how to make a racing game,” you get a bunch of tutorials teaching you one very specific (and very hardcore) way of implementing vehicle/driving mechanics. These tutorials are great if you’re making a realistic driving simulator or racing sim, but chances are they won’t even get you started in the right direction for implementing something that actually fits the constraints of your particular game project.
This article will introduce you to different approaches for implementing racing mechanics, while discussing how these implementation strategies may either complement or clash with your game’s core design. Continue reading
I recently wrote a new article that was published today on Model View Culture. This was my first exposure to the world of professional writing, which means that I had to pitch my piece to them, have multiple drafts reviewed by their editor, and get paid for my work.
Read the Full Article on Model View Culture
Over the past eight months or so, I’ve become a huge fan of this publication, and I’m super honored to have my work published by them. I love how their essays look at the tech industry from an angle that you don’t really see on typical industry publications. They often discuss the industry’s culture and social problems while promoting interesting and diverse voices, opinions, and projects.
They are an independent publication with zero ad revenue, which means they only make money when you buy things from them. In particular, I love their printed quarterly subscriptions, which are also available digitally. There’s something really fun about getting a little journal in the mail that’s filled with super fascinating thoughts from awesome people who are actively working to improve the tech industry. After reading my piece, feel free to look around their site, follow them on social media, and if you end up liking them as much as I do, please consider supporting their work.
To be honest, I always cringe a little when I hear someone say that they “taught themselves” how to do something. While the phrase has become a shorthand for saying “I learned this outside of the traditional classroom setting,” I can’t but help be bothered by the sense of arrogance that comes with the fact that it also seems like a shorthand for “I learned this without a teacher.”
There is always a teacher involved. Whether you learned that skill by reading books, following online tutorials, watching instructional videos, or reading articles online, someone had to create that content for you to consume.
One of the most amazing things about working in tech is that people tend to spend a lot of time either learning from others or helping others understand complicated skills. Anyone can become a “teacher” just by writing a single article or by giving a talk at a conference, and this promotes a really cool continuous-learning culture within the community.
But it worries me just how little attention we sometimes give to the teachers who create the content that we have become so dependent on for our professional development. Software engineers tend to take the availability and quality of this educational content for granted. Many people in this field describe themselves as “self-taught” rather than attributing their expertise to the individuals who they learned from.
This is a problem, not necessarily because it’s rude or self-centered behavior, but because we’re creating misleading expectations among students and upcoming engineers. We often trivialize how easy it is to learn new technologies by saying “oh yeah just do a Google search!” We act as if just any Google result is good enough to learn from, as if the quality of the educational content has no effect on one’s ability to master the material. We give off the impression that mastery is entirely dependent on our own intelligence, and so when students struggle, rather than questioning the quality of the content that they’re trying to learn from, they instead question their own intelligence and start contemplating whether they should just give up.
There are plenty of good resources out there that teach the technical skills that are necessary for becoming a good programmer, but I’ve seen only a few that give you the more personal lessons that you often only learn through experience or trial and error. In this article, I’m going to share with you some of my own habits and skills that I’ve gained over the years to help me do better work.
This article is based on a post I made over a year ago on the UA CS Facebook Group in response to someone’s question about how you can become a faster programmer. Instead of posting about tools and keyboard shortcuts, most of my tips are about how to get yourself to think faster, along with a few tips for avoiding time-consuming mistakes.