Now that graduation has come and gone, it’s time to step out into the real world. To all my loyal readers who have supported me through my intense year at VFS, thank you so much.
If you’re interested in continuing to follow my adventures in the gaming industry, please visit my website at dickersondesigns.com/blog.
It’s hard to put into words all the thoughts and emotions that come with graduation, especially one marking the end of such an intense year.
I went into the year not knowing what to expect and was blown away every step of the way. I learned more than I ever could’ve imagined and met passionate and creative people who continue to inspire me every day.
Moving forward into the real world is a scary step, but with the vast amount of knowledge and skills I’ve acquired at VFS and the extensive support network I now have in my corner, I’m confident I’ll be able to tackle the next big challenge.
By now, most of you know that my main interests in game design lie in serious games. That is, those games that reach into the real world and have the potential to effect change in players’ lives. And you also know that I crave opportunities to solve big problems in creative ways.
So, I’m excited to announce that my next big venture will be with a startup company here in Vancouver whose aim is to create games to encourage kids to be more physically active. With growing issues of childhood obesity, physical fitness has become a huge societal issue.
I’ve seen firsthand how much kids love games. Games transformed my classroom and turned even the most reluctant students into eager learners. Thus, I know that games have the potential to change people’s lives.
Like I said, it’s scary stepping out into the real world. I’m now accountable for designing real games, rather than just concepts for various assignments. But with all that I’ve learned at VFS, I’m definitely up for the challenge.
To all my teachers and mentors at VFS, there aren’t enough thank you’s in the world to express my gratitude. You’ve given me more than I could’ve asked for, and VFS is lucky to have such a strong crew molding the next generation of game designers. I won’t let you down!
P.S. If you’re interested in reading or rereading the graduation speech I presented, you can find it here. Enjoy!
From our first day at VFS, Industry Night was dangled like a carrot before us, that seemingly unreachable goal light years away. Yet after months of hard work, countless brainstorming sessions, and tons of great feedback, we’d produced a game. And a few hours ago, we presented it to the industry.
In many ways, Industry Night is the culmination of the VFS game design experience. After working closely with a small team for several months to produce a game, you’re invited to present your game to a group of people from the games industry, who then come and play your games.
Our Industry Night included action games, puzzle platformers, adventure games, and shooters. Our games incorporated creativity, solid design, and unique mechanics. And after working day in and day out with these guys over the past several months, I can say that I’m extremely proud of all the games we showed tonight.
If you’re interested, you can read more about the games and even try them out for yourself. Be forewarned, though, that some of them can be very addictive. Enjoy!
Bugs, bugs, bugs, bugs…
Our final project is due at the end of this week, which means it’s time for debugging. Looking back through old scripts I wrote in March and April reaffirms how much I’ve learned in the past several weeks.
Not only do I have a much better command of C# syntax, but my logic has improved noticeably, meaning I can manage multiple functions and instances simultaneously without too much of a headache. Less guessing, more purposeful planning.
As of today, we have 22 bugs on our bug list, 13 of which are ranked high priority. And that’s not including all the ones we haven’t yet found. So here’s to the last few late nights of crunching and debugging. May they go as smoothly and be as pain-free as possible.
There are less than 10 days left until our final game is due, which means it’s time for all the little details. With our mechanics and main gameplay elements ready to go, it’s now time to add little flourishes that will make our game experience all that much better and more fun.
Here are some of the things on my to-do list for the next week and a half:
– implement particle effects (explosions, movement trails, player notifications, etc.)
– polish animations
– create a new set of background pieces
– script some movement for midground pieces (airplanes, clouds, etc.)
– ensure that the scoring system works properly for successive plays
– debug character movement, environmental assets, and front end menus
It’s hard to believe that the deadline is so close. Time to kick things into high gear!
Remember these logic puzzles? You’re given a brief story and a few seemingly unhelpful hints (e.g., Wanda’s partner doesn’t like roses), and then you have to proceed through the hints, crossing off the non-solutions until you arrive at the solution.
Lately, I feel like I’ve been working through a logic puzzle, only in script. At first, implementing Chip’s animations seemed easy. We only had five animations: walk, jump, throw a ball, hang by his chin, and die. Sounds easy enough, right?
That’s what I thought too. Very quickly, I realized that these animations weren’t mutually exclusive. Chip might jump and throw at the same time, making for a very twitchy looking Chip.
Back at the animation boards, we knew we had to separate out Chip’s body parts in order to run simultaneous animations. But which body parts? And from which animations?
Here comes the logic puzzle. Regardless of what Chip’s doing (walking, jumping, etc.), if he throws a ball, the throw animation should play. So first and foremost, his arm needed to be a separate piece.
Next came the more nitty gritty. When Chip is jumping, even though he’s also moving forward, he’s no longer walking. Similarly, when chin hanging, even with forward inputs, Chip should not be walking. And above all, if Chip is dying, he shouldn’t be doing anything else.
After a few days piecing it all together, Chip has come alive and is now quite animated!
The more I get into game design, the more pleasantly surprised I am at how much psychology is involved. If you think about it, game designers shape experiences, so they must constantly dig into their toolbox of psychological principles.
If you’ve ever played a game and striven to attain any of its achievements (think Angry Birds), the game designers have hooked you in with psychology. Achievements, like visual feedback, audio, and various missions and challenges, play a huge part in the perceived fun and replayability of a game by motivating players.
To learn more, take a look at this article on how to design effective game achievements: The Cake Is Not a Lie: How to Design Effective Achievements
When deciding between using Unity or UDK as our game engine of choice, one of my main qualms was with the error messages Unity throws at you. Whereas UDK will let you jump in the game with multiple kismet errors, Unity spits out lists of errors, refusing to let you run the game before fixing them all.
There are entire forums out there dedicated to dealing with various programming error messages. And as a novice programmer, this scared the heck out of me. How was I supposed to know what was wrong without seeing what my code did?
However, after weeks of braving the sea of error messages, I’m happy to say that I find them quite helpful. Most of the time. In fact, I even have a few favorites:
1. Error CS8025: Parsing error
This is hands-down my favorite. Easiest to fix, yet one of the most annoying. This error usually refers to a misplaced curly brace. Spend a few seconds visually pairing up all the curly braces, and this error is soon out of your hair.
2. Error CS1525: Unexpected symbol ‘{‘
This one is another fun syntax error, usually thrown out as a result of not pairing all the parentheses in conditionals. In programming, most things need partners.
3. Error CS0029: Cannot implicitly convert type ‘int’ to ‘bool’
There are several variations on this error, which usually results from syntax error in the conditional. Most of the time, I get this error when I forget to include double equal signs in my conditionals (e.g., ‘if (iLevel = 1)’ rather than ‘if (iLevel ==1)’), so the statement tries to set values rather than compare them.
From here, the errors start to get more complicated, ranging from null reference exceptions to invalid argument errors. And those are just the ones Unity can detect. Often, the most difficult errors to fix are those that result from faulty logic. It does exactly what you told it to, but unfortunately, your directions were off.
So what have I learned from the countless error messages Unity has thrown my way? Even the best programmers make mistakes that lead to error messages. But figuring out how to successfully deal with those error messages is what separates the good from the great.
To say I’ve learned a lot about scripting over the past several weeks is an understatement. I’ve gone from struggling to create basic character movement to creating functions that can “think” on their own. But most of all, I’ve learned that programming is not just about working hard, but more importantly, about working smart.
One of my recent tasks has been to design and implement a level select map. After plotting the levels on the map, my first instinct was to script the individual events for each level.
So, for example, if level 3 was just completed, the spotlight for the next level would need to go on the level 4 marker. If Chip is on the raft between levels 3 and 4, he can go to the right for level 4, get back on the raft and go left for the bonus level, or get on the raft and go up to get back to level 3. But he would not be able to go past level 4.
As you can imagine, the list of conditionals and events needed for each spot quickly grew quite lengthy. The solution? Work smart.
I stepped back and analyzed the commonalities amongst the different stopping points on the map. Chip would need to stop at level markers, but also rafts and corners as well. But he would only be able to launch into a level while currently standing on a level marker.
As the patterns started to emerge, I was able to formulate functions and algorithms so the code would work for me, rather than the other way around. It didn’t come without tough moments and tricky spots, but in the end, the code is much cleaner and ready for additional functionality as needed.
So even though working smart may be riskier in the short run and you may spend more time feeling stumped, ultimately, the payoff can be well worth it.
Logos have long been one of my favorite parts of graphic design. A logo needs to be simple and straightforward while simultaneously communicating layers of meaning.
When designing a logo, I first think long and hard about what I want the image to communicate, filling the pages of my sketchbook with words and doodles. Color choice, typography, style, and spacing all play important roles and can drastically change the look and feel of a logo.
In designing the logo for our current game Blokhead, I wanted to create a bright and strong logo that would communicate the main mechanic of throwing and deflecting balls. I wanted the logo to communicate both action and fun.
The result is a logo comprised of primary colors and thick blocky letters that incorporate the L and O of Blokhead into an image of a bouncing ball. Simple, functional, memorable.
Play by Play 