Skip navigation

Monthly Archives: June 2009

I’ve been getting back into my game engine again.  Shawn Kendall, one of the owners of ZG, has been kind enough to provide me with some tips and pointers for engine design.  Shawn is an incredibly learned man in this subject and used to teach game engine design at Full Sail U here in Florida.  Naturally, this has been an amazing opportunity which I plan to continue to leverage as much as possible.  In any case, the basics of the engine are pretty much planned out by now and I will probably be uploading the images of that sometime soon.  It’s been a lot of work and slow going, but it will be pretty awesome to have an engine of my own to dork around with and gain experience from.

On to the title of this post: the people at the ZG office **LOVE** Magic: The Gathering.  They play pretty much every Friday night, sparsely during the week, and sometimes even during breaks.  They are constantly talking about the new sets that are coming out, the recent deck they built to best so-and-so, and how broken certain cards are.  Me?  I like Magic, but I probably won’t ever get to the level of devotion that these guys have.

However, I have found that MTG is a very solid, well built, and fascinating game.  Since my time this summer has been almost exclusively *coding* games, I figure flexing my design and balancing skills is just as important.  I think Magic is a great place to start with that, so I have come up with a few card concepts that I would love to have feedback about.  I will hopefully be churning out more card concepts over the summer, but we’ll start with these:

Spiteful Visions:  2 Black                                      – Common

Sorcery

Target player discards 2 cards and draws a card.

Conspire

“Forgetting is as much of a blessing as a curse.” -Iithes

Slash and Burn:  3 Red, 2 Colorless                   – Uncommon

Sorcery

Destroy target green permanent or target basic land unless it’s controller pays 3 Life.

“Take a life to save a life?  Sounds like a fair trade.”

Thriving Sapsire:  5 Green                                    – Rare

Creature – Saproling Ancient

3/3

Put a -1/-1 counter on Thriving Sapsire: put two 1/1 Saproling tokens onto the battlefield.

When Thriving Sapsire is placed in a graveyard, put two 1/1 Saproling token onto the battlefield.

Creatures of the forest never die, they simply get smaller.

Inspired Flight:  2 Blue, 2 White                        – Common

Enchantment

Enchant Creature

Enchanted Creature gains +2/+3 and has flying.  Place a -1/-1 counter on enchanted creature.  When enchanted creature is put into a graveyard it’s controller gains Life equal to the number of -1/-1 counters on enchanted creature.

“The best things in life might just kill you.” -Tarr’agun

Advertisements

Today was a great day. You know, despite it being Monday, my project being rejected for minor issues, and my continued lack of personal computer time. I learned a LOT today, and that’s what’s important. The most signifcant thing I learned today is that my coding instincts have been more or less right on the money. I was introduced to the Factory design paradigm, the Strategy paradigm, and the Flyweight pattern. All of these can be found on the net if you are interested. Seriously, go read them, I’ll be here when you get back.

The point of introducing these concepts is to mention that I have been blindly applying these ideas in the practices without knowing about them until today, which fills me with confidence about my own methods. Now, before this ego boost gets out of control, some other things cropped up that helped to keep me in my place. For instance, the new level system.

Our manager gathered everyone into the large room and began handing out forms. He proceeded to explain the new peer evaluation system which centers around classes and rankings. That’s right we have classes and levels in our game studio. The example Mr. Oltyan used was Software Engineer III. In order to get a raise and increased benefits, one would have to demonstrate proficiency in certain skills to advance to the next level. Multi-classing is also allowed, allowing engineers to become artists and vice-versa. How fing COOL is that?! I’m infinitely curious to see how it works out.

This puts Sage and I at Production Intern III and Programming Intern III respectively. We have been informed that leveling as an intern requires signifcantly more experience than normal, so if we come back next year, it’s possible to become Intern IV, but it will be difficult to achieve that this year. Funny enough, I’m OK with it.

I had one of those moments today were I stopped in the middle of a line of code and said to myself “Holy crap. I’m in the games industry. I’m getting paid to make games. I had only dreamed of doing this a few years ago. I’m moving up, doing what I love, and having a blast.” A surreal and amazing moment indeed.

Had to present the delivery I made last week to the rest of the office today.  While I strongly support the deliverable, our presentation left a lot to be desired.  However, I feel that passing on the key points of the presentation are a good idea.

What went right: we tore up the user stories.  We hit pretty much every milestone with room to spare and didn’t really have to scramble to get our sprints finished on time.  Despite all of the interruptions that cropped up during development, we still delivered on time with some bits of fluff and padding to spare.

What went wrong: I consistently doubted the abilities and habits of the engineer who had worked on the project before me.  This meant that I frequently had to ask him stupid questions that were resolved with a single line of code, taking away valuable time from him.  Also, other projects kept getting in the way of our sprint.  Although we were able to still deliver with these interruptions, the other projects certainly didn’t help our development cycle and tended to distract our team.

Lessons learned: use the tools at hand to their greatest extent before bugging other people.  Use Command-F, use the debugger, use the internet.  Exhaust your resources before you call in other people to help mitigate your issues.

I found this informative article.  It’s really not that ground-breaking, but it’s a good read for any designer/developer or anyone who is interested in strengthening their story telling habits: A Simple View of Game Story

I’ve been putting off a new post for quite a while now since I feel that readers don’t care about how cool things have been around here.  Let me just say that ZG is pretty damned amazing.  The people are awesome, the work is engaging, and I couldn’t ask for a better introduction to the games industry.

As far as things I’ve learned though:

I learned about the “user story” planning model.  I had never heard of this before ZG, but it is apparently sweeping through the industry as the revolutionary new way to manage projects.  How this works is content is presented as a need from the user’s perspective.  Then tasks are assigned to the stories to separate the user story into a functional piece of the product.  For example, a user story might be: As a player, I want to be able to jump. This means that whatever is needed to make the final result of a jumping player is encompassed by this story: physics engine, character animations, noises, decals, whatever as long as the final results of the story is that the user perceives jumping.  After the stories are all compiled, the team then participates in “planning poker”.  A deck of cards with groups of Ace, 2, 3, 5, 8, Jack, Queen, and King are split up so that all members have one of each card.  A user story is selected and everyone places a card on the table estimating the difficulty of that story.  Ace is trivial, 2 is a day, 3 is slightly more than a day, a three is two to three days, etc., where Queen is a 25, meaning the task is large and hard to predict it’s time needs and King means 50 – a task that is daunting and will require many many man-hours to complete.  This technique seemed a little strange at first, but it has turned out be very powerful.  It really helps to figure out what concessions you need to make in order to deliver the expected results and packages each story into a single entity, generally independent of other parts of the project.

Next on the list of edumacatification is “Scrum Team Management”.  This is a part of the agile development philosophy, attempting to keep teams and projects lightweight and flexible.  The idea is that scrum meetings are held every day at the same time and last no longer than 15 minutes.  Period.  In these meetings everyone on the team explains what they did yesterday, what they plan to do today, and if they are waiting on anything (a blocker, as it’s called).  This puts everyone on the same page and encourages communication.  It seems to have worked pretty well so far.

Along with the Scrum methodology is the Sprint ideal.  Sprints are short periods of development where a specific set of user stories are focused on.  If a user story is not part of a sprint, it is ignored (unless there is a direct dependance, wherein both the blocking story and the depending story will most likely be involved in the same sprint).  These sprints are usually 2-4 weeks in length, but some longer and some go shorter.  For example, I have been working in 1 week sprints.  This is mostly because my project is smaller and we have very few people working on the project at this time, allowing for rapid development and easy communication.

My last piece of wisdom to pass down is simple, but profound.  I have been informed that it is NEVER a good idea to make more work for the people above you.  Take the time to do it right the first time.  Research, test, model, plan, do whatever you need to do.  Because if you do something stupid and someone who costs the company more money has to clean up after you, everyone is going to be angry and you will look dense and inconsiderate.  This doesn’t mean you shouldn’t ask for help.  This means that you should exhaust every resource you can before you go whining to more expensive people.

Things have been going really well down here.  Florida blows, but that’s really only because I’m used to dry, cooler weather.  Be sure to keep in touch and stay tuned in.  I should have more nuggets of wisdom some time down the line.

How A Game Gets Made

I found this article on Gamasutra’s news page and it’s a pretty good article.  After reading through I was blown away at what it takes.  I knew it was a pretty epic undertaking but it’s amazing to see that so many people from such disparate fields come together to get it done.  It’s actually amazing to think that a lot of companies are able to do this in two years.  Funny how I used to think that a two year dev schedule was really long, it seems now like two years in the absolute fastest that a quality game can be developed.