The Game Plan: Getting Started

Leave a comment Standard
file0001764062159

Your game design can run fairly smoothly or it can be a continuous cesspool of hardships and setbacks and pain points. In the next few series of posts I’m going to try and help walk you through the process of getting your game up and off the ground, from what you’re envisioning in your head to an actual working version. So, let’s get started.

1. Get It Out Of Your Head

It’s time you pull out a pencil, pen, or open your laptop to a writing program. First thing’s first, you have to get your game out of your head. Write it down and put it somewhere you can reference it later.

2. Writer’s Block

So if you’ve opened a text editor or you have a pen in your hand you’ve successfully completed step one. Now, what do you write? I like to start with the five W’s:

Whom?

  • Does your game appeal to a specific age range or interest group or gender or even ethnic background?
  • Will you have a large audience your game will appeal to or a small audience?
  • What are the benefits and downsides of the audience you’ve identified?

What?

  • What kind of game are you trying to make?
  • What programming language best suits this kind of game?
  • Does it fit into a specific genre of game or does it span multiple genres?
  • Does it embody a completely new genre?
  • Can you find other games that are similar to the game you are trying to make? If so, what do these games do well and where do fall short?
  • Are there lots of other games on the market similar to the type of game you’re trying to make?
  • What will your charge for your game?
  • What do other, similar games of this type charge?
  • What are the benefits and downsides of the type of game you’re trying to make?

Where?

  • Where does your game take place?
  • What kind of maps or features or environment are unique to your game?
  • What are the benefits and downsides of where your game takes place?

When?

  • When will you have time to work on this game?
  • When can you start this game?
  • When can you fund the development of this game?
  • What are the benefits and downsides of developing this game?

Why?

  • Why are you making this game?
  • Why is your game unique?
  • Why will your game stand out from the crowd?
  • Why will people choose to play your game over other similar games?
  • Why will people pay for your game?
  • What are the benefits and downsides of making this game?

3. Make A Design Document

Your design document is a refined version of everything you’ve written down in step 2. Go back and really analyze what your goals for the game are and if what you’ve written down makes sense in the larger picture. Sometimes a good idea you have for one area of the game will conflict or make another part of the game tedious, uninspired or downright frustrating. For a game design document I like to use the following format:

  1. Intro
    • What is the vision for your game and a short description of how the game is played
  2. Audience, Platform & Marketing Strategies
    • Who the game is for, what platforms you’re making it for and what sets your game apart that will make it marketable and different from others
  3. Core Gameplay & Mechanics
    • How the game is played including physics, rules and limitations
  4. Characters
    • What characters are in your game including what they look like, their names and backgrounds and personalities
  5. Story, Themes & Twists
    • If your game has an overarching story then you’ll outline your plot and how the game progresses with the story line
  6. World
    • Describe the world your game is set in, including maps and locations and their purpose or importance
  7. Assets
    • All the different images, music, animations, etc that you will need to have a fully functional game
  8. Technical Specs
    • What language you’re using, how games are loaded/saved, where games are stored, the number of servers you’ll need and anything else relating to the technical setup of your game
  9. Interface
    • What the game interface looks like and how the player will interact with it
  10. Outside References
    • Articles, links, design inspriations, or anything else that you’re using as a reference for the game you’re making
  11. Appendix
    • Code style guidelines, dictionary of terms, and anything else that is important for understanding your design document that may not necessarily relate to your game directly

Once you’ve fully fleshed out your game design by going into depth about the features, physics, economy, weapons, characters and how the game works it’s time to break it down. Start by creating lots of of small, easy tasks you can accomplish in order to see your core game mechanics to completion enough that you could play a simple version of your game without any extra bells and whistles. Set yourself up to do as little as you have to but as much as you need to in order to get a really simplified, yet completed, version of your game.

Why Making A Game Takes the Fun Out of It (and how to fix this)

Comments 4 Standard
angry-woman

I see it all the time, people coming into forums and online communities for games and game developers asking how to make a game or how to get their ultra cool idea that everyone will love and has never been done before off the ground and make it a tangible reality. Let’s get things straight, we love games because they’re fun and entertaining. It drives our creative vision and imagination and offers an escape from the mundane and the boring reality that is our lives. This passion, this drive to express ourselves and have fun is often what leads people to try their hand at making their own games. Many will start this journey but very few will finish it and even fewer will finish it with a successful and positive outcome (and let’s face it, money in your pockets). So why does this happen? Why do so many people start down this path of learning and creativity and adventure for fun that ends up leaving them broken, frustrated and depressed? The reality is that games are a lot of work and the very nature of making a game isn’t even a little bit fun. In many ways it’s the exact opposite of what we’re trying to achieve. So how does this happen and what can we do to fix it? Let’s break it down from the point of view of an Indie game developer whose a one man shop (or small shop) trying to make a game.

Lack of skills

You want to make a game but you’ve never programmed before, you don’t know anything about what’s required to make the type of game you want to create and even if you have those things covered you may not have all the skills you need to make it happen. Just because you can program doesn’t mean you can draw or compose artwork or market your finished product if you ever get that far. As an indie game developer you really have to be a jack of all trades. Think about trying to build a house if you’ve never built a house before. What happens if you only know how to frame the house but not how to do plumbing and electrical and tile work and all the other things that are required to finish the house? You end up with just the shell of a house that is lacking in so many ways you can hardly call it a house. This is one of the biggest problems I see with indie game devs — they lack the skills to accomplish what they’ve set out to do and they’re not prepared to outsource when they need to, which brings me to my next point.

Budget constraints

Making games is inherently expensive. Even if you create your own game framework and develop your own models/artwork, sounds and music you still have to — at a minimum — invest in a computer and dedicate hundreds of hours towards the development of your game. Those hours add up and while you’re developing your game you’re not earning a living that you need to support yourself and/or your family. Yes, that’s right, you still need to eat and buy necessities and support yourself and/or your family which is why even if you do have the funds outsource some of the work you lack the skills for you’re still fighting a losing battle towards my next point.

Time constraints and distractions

Supporting yourself and your family means that you’ll still need a full time job even as you chase the ethereal dream of creating your own game. Your time is precious and what little of it you have left after your regular day job has to be split between your other financial and personal commitments. Your kids need their parents and your house and car need to be maintained and you’ll struggle to find the proper work/life balance amidst all of the chaos that you juggle on a daily basis without adding the complexities of your game into the mix.

Technical problems, bugs, new frameworks and advances

So even if you can overcome all these odds so far you’ll still find yourself stuck hitting roadblocks as your game progresses. Technical problems you didn’t predict or forsee early on (and how could you, you’re still just learning yourself) end up being the bane of your game’s existence. Now you have to go back and re-write and re-factor and debug until you’re so frustrated you could pull all of your hair out and go bald. New frameworks and technological advances will make your second guess yourself or roll back to square one because you really do want to upgrade your SDK and add in the new dynamic system and better bump map texturing because who doesn’t want their game to be using the newest, latest and greatest technology available? No one wants to play a game that doesn’t have the same bells and whistles that their competition does because they took the the extra time/budget/testing cycle hits to go with the greater tech.

Slow progress and scope creep

Ultimately these things combined will drag your game down. What may have started off well and progressing quickly has suddenly slowed to a snail’s pace. Things suddenly feel like they’re never getting done or you have so many issues on your plate that it feels like there’s never an end in sight. Your game has hit a standstill and isn’t advancing like it was in the beginning and this is awfully discouraging and frustrating. The scope of your project has suddenly tripled and your todo list is a never-ending tally of bug fixes and re-factors and speed optimizations that need to be addressed for any chances of your game seeming like it’s something worth playing.

Early demo failures and monotonous repetition

If you’ve made it far enough to put together early demos and alpha access then pat yourself on the back — most people will never make it this far and you’ve just become a member of an elite club that deserves a badge of honor. The only problem is your demo gets horrible reviews, you realize your controls are too hard to use and this puts you into a crazy monotonous cycle of playing a particular part of your game over and over again as you attempt to fine tune it and make it more playable and more fun.

Never good enough

Unfortunately the truth is that your game will never be good enough. Someone will always find something to complain about even if you see some great feedback and helpful critiques that, if implemented, could really take your game to the next level and set you apart from your competition. Your controls will never be 100% perfect, your menu system may be too hard to read or too complex to navigate and you’ll never quash all the bugs that have been reported partly because you can’t re-create them all because your game is being run and tested under hundreds of different environments and hardware and operating systems that you didn’t have access to (and probably never will) as you were developing. If you’ve made it here this might just be the time for you to throw in the towel and say goodbye to all the blood, sweat and tears you succumbed to in order to make it this far.

Overcoming It All

If this has discouraged you against making your own game — good. Making a game isn’t easy and it’s not something for everyone so don’t waste your time early on if you’re not prepared to go through everything I’ve already mentioned and be able to walk away without anything to show for it. However that doesn’t mean you shouldn’t make a game or that it’s impossible to do it either. Where there is a will there’s a way and let me show you how.

  • Map out your game design, features, characters and how the game works. Now create lots of small, easy tasks you can accomplish in order to see your core game mechanics to completion enough that you could play a simple version of your game without any extra bells and whistles. Set yourself up to do as little as you have to but as much as you need to in order to get a completed version of your game.
  • If you lack the skill to do something you have two options. The first is that you resign yourself to taking the time to learn this new skill and the next is that you can outsource the skill to someone who’s already achieved it. You don’t have to be an expert programmer to make a game, just an adequate one. If you’re going to invest time into learning a new skill don’t dwell on it for too long, learn enough that you feel confident you can accomplish the task at hand and then move on. Investing too much time in learning a skill will start you down a path that walks further and further away from working on your game.
  • Sit down and map out all of the expenses you foresee as being necessary to complete your game. Now triple it. If you can’t afford to spend this amount of money into your game then you need to go back to your concept and re-work it until you get a budget that you can work with. If you’re really determined you can look for some outside investors but don’t count on this — ever. Most investors want to see a fully working demo before they’ll even consider opening their pocketbooks and investors will demand more than 50% of whatever profits you make from your game when it’s done.
  • Your time is precious when you have so little of it to devote to your game. Start by mapping out a timeline of your game features/assets and how long you think it will take you to accomplish them. Now double that. Now compare that to how much free time you really have to devote to your game. Will this game take you more than a year to complete? Do you have the dedication to spend more than a year working on a single project? If the answer is no then you need to go back to the drawing board until you’ve come up with a reasonable timeline that you can work with. Keep your game as small as you possibly can by focusing on the core mechanics and leaving out any fluff that you could add at a later date. Now stick to your timeline. If you budget 2 weeks to work on a character and by the end of the second week the character isn’t done don’t dwell on it — either move on to the next item in your list. Don’t adjust your timeline and don’t spend more time that you budgeted on this part of it. Sure, your ultimate goal is to have a working character with great animation but if you can’t ever get a game working with a broken character then who cares if your character’s animation is jerky or unrealistic? Think about the big picture because you can always circle back later.
  • Invest in a good debugger and testing tools. Do whatever you can to automate this process as much as possible because it will give you more time to work on trivial issues when you can quickly address and fix the larger ones. If you run into a bug that makes your game do something funky but it doesn’t prevent the gameplay from continuing table it and work on something else. Try not to get caught up in the more minute issues and focus more on the big picture. You can always circle back and fix bugs later but if you spend all your time bug quashing you’ll end up with a pretty interface or character or scene that doesn’t let interact and play with it. Pick a version of a framework and stick with it, don’t upgrade it unless you absolutely have to. The more you upgrade and update to the latest and greatest the more issues you’ll run into and the more refactoring and scope creep you’ll run into. It’s okay to build a game that isn’t using the latest and greatest version of your frameworks or 3rd party integrations. This will also give you a chance to work with and around the quirks in the version of the framework/software you chose to use instead of having to re-work around these every time you upgrade and re-factor.
  • Get the core mechanics working version of your game finished as early as possible no matter what it looks like or how bad it is. A crappy, ugly, glitching yet working version of your game is better than a pretty, perfectionist, bug free version of your game that isn’t at all playable. Don’t wait until the last minute or the week before it opens to get feedback on what you’re doing. Feedback is a great way to find issues you hadn’t considered and it will give you an idea of what other people think about your game. After all, no one wants to play a game they don’t think is fun. Don’t ignore constructive criticism even if it’s not what you want to hear. That doesn’t mean you have to change or add anything anyone has ever asked you for — it means that you need to take those things into consideration going forward. See past the reviews that focus on your aesthetics — at least initially — because you can always change and fix those later, core mechanics and gameplay are much harder to tackle once you’ve invested lots of time and energy into them.
  • Your game will NEVER be perfect. You will always be tweaking, adding, adjusting and fine tuning it. Instead of wasting your time doing this early on and ending up with something that isn’t a viable product devote that time to your game after you have something you can put out there. Don’t be a perfectionist, no matter how many bugs you quash and features you add or tweak there will always be another bug or problem coming down the pipeline. Try to prioritize the most important ones and tackle those first. Ultimately you want to get something up and working no matter how good or bad it is and then build upon it from there. Rome wasn’t built in a day so don’t expect your game to be. Get a working version up first and foremost and then add on to it and enhance it over time, your customer base won’t hate you for that, rather the opposite — they’ll appreciate your continued efforts to improve upon what you’ve done so far.

Why Using Google Adsense Really Does Make $ense

Leave a comment Standard
google_ads

I started using Google Adsense on my games in 2004, three years after they opened. Boy do I wish I’d started three years earlier. If you’re not using Google Adsense on your games and websites you should be. It’s a crazy easy way to make passive income which means more money you have to spend on future development and game assets (your pocket too). Part of what makes Google Adsense work so well is that it uses cookies to target what people are interested in seeing. That means they’re more likely to click on an ad which generates you income. Oh yes, Google Adsense is PPC or Pay Per Click which means every time someone clicks on an ad it will credit your account with money. As soon as your account reaches over $100 (or it’s the end of the fiscal year) you will get a check for everything in your account. It might take a few years to really bring in the dough but keep at it and the rewards will be worth the wait.

15 Things Schools Won’t Teach You About Programming

Comments 4 Standard
15 things you won't learn about programming in school

Don’t get me wrong, going to school to learn how to program is great but there are some things that schools seem to miss the mark on and these drive me nuts.

  1. Copying – well yes, cheating is bad and you should do your own work in school but it’s also not reasonable to expect someone to go it alone on a project in a job setting. Your manager won’t ask you to live in a bubble of seclusion when they want you to complete a difficult task in a short amount of time. In fact they’ll encourage you to use outside resources and other programmers to get the job done. This is one of my worst pet-peeves about schools. Sure you need to know how to program but in the real world you aren’t required to go it alone without any kind of external resources at your disposal or the collaborative programming with other co-workers.
  2. Scope Creep – so in school your projects have a nicely defined list of features and requirements your professor wants you to implement. However the real world isn’t so nice and cut and paste — even if you have well developed requirements. The fact of the matter is you often won’t know what requirements you need to fulfill until you stub out some kind of prototype and show it to your clients and get their feedback. In addition you’ll typically find things that you didn’t think about which make you scratch your head and go back to the drawing board a time or two.
  3. Text Book Solutions – if you’ve ever done an assignment from a textbook with an answer key in the back you know exactly what I’m talking about. There’s always that one solution that’s deemed the “correct” answer. In reality there often isn’t a single solution to a problem and what may work as a solution in one environment is a complete and utter failure in another as the scale or complexity or speed of the results actually hinder the user experience.
  4. Making The Grade – everyone knows you’re supposed to get straight A’s in order to get a good job after school. Wrong! I’ve never known an employer to ask for a GPA or how many times I failed a class. The truth is your grades don’t matter, it’s your knowledge and experience that count. So what if you have straight A’s in every class you ever took if you’ve never had any practical experience building your own program or working on a large, complex project. No one cares what your grades are, they want to know you can get the work done well and in a timely fashion with minimal bugs.
  5. Re-Inventing The Wheel – yes it’s important that you understand how and why something works but schools are notorious for having their students re-invent the wheel. Let’s write five different types of searches that most languages have built in functionality for, or let’s write a function that swaps two values so you can use it in later projects. Please, don’t re-invent the wheel. If it’s already done for you then why are you wasting your time? Understand how it works and then take that knowledge and build something useful, don’t just regurgitate what’s already been done over and over again.
  6. Debugging – this is one of the most useful skills you can have and yet schools are sadly lacking in teaching students how to intelligently debug errors and use helpful debugging tools. In addition most schools stress actual programming when even the software life-cycle emphasizes maintenance and  bug fixing as a majority of the time spent on piece of software. Why are schools leaving this out of their curriculum when most new programmers are tasked with bug fixes in order to learn how a large piece of software works?
  7. Documentation – there is a sad lack of acknowledgement for documentation in programming. Some schools will skim over it briefly but for the most part it’s a passing reference in a class. I’m amazed at how many new programmers I interact with who have thousands and thousands of lines of code without a single comment. Now some of you may argue that documentation isn’t needed however if you’ve ever returned to work on a project you set down years ago you know those hours you spent trying to figure out why you did something that you didn’t document could have been better spent with the 5 minutes documenting it in the first place.
  8. Deadlines – in school you’re given long deadlines to get something done. Deadlines aren’t as set and fixed in a job setting. One day your boss may walk up to you and say “I need this in an hour.” If you’re always used to long, drawn out deadlines then you get that deer in the headlights look in your eyes. Of course this works both ways, and I’ve worked on projects that have no deadlines either. The point to take away from this is deadlines are flexible and rigid, achievable and impossible to meet and not a fixed point in time and space.
  9. Multitasking – in school you only work on a single project at a time until that project is done. A job setting is far from that. You may start a project one day, have it scrapped the next day and then returned to you six months later. In addition it’s common to be working on multiple projects at a time as you wait for other requirements or client feedback to trickle in. Asking students to work on one project at a time is detrimental to them learning how to multitask and adjust as the situation warrants.
  10. Pass or Fail – schools have a pretty black and white approach to how a program is supposed to work in order for you to get a passing grade. What they forget is often times a project just needs to be “good enough” due to deadlines or budgets or resource constraints. Something that is good enough to meet the requirements doesn’t mean you failed, it means you have room for improvement and re-factoring.
  11. Refactoring – I would love to see a school tell a student to take the first project they completed at the beginning of the year and re-write it with what they know now. Re-factoring is a major aspect of a programmer’s job and yet few students are asked to look at their past work, reflect on how it could be improved, and then set to the task of improving it. This is something most programmers are faced with on a yearly basis as they complete new iterations and features of their software.
  12. Coding Together – since schools are so intent on grading you as an individual the students miss out on the ability to code collaboratively. There is rarely a time when a complete piece of large software will have been written by a single person. Being able to read and understand other people’s programming and to match your style to theirs is a huge asset and ability that shouldn’t be overlooked.
  13. Best Coding Practices – so you learn the programming fundamentals but you’re hardly taught when you should use one rather than the other and where, how or why you make that decision.
  14. Code Style Guidelines – one of the biggest indications of a good programmer is their coding style. Code that is easy to read, indented properly, and consistently written is essential for improving maintainability of a piece of software. Most new programmers run their lines of code in big long strings with inconsistent spacing and style guidelines. Would you rather read 1,200 lines of code condensed onto 5 lines that makes you scroll infinitely in your editor to read them or properly indented and spaced code in a logical and easy to read manner? I know which one I’d choose.
  15. Experience – there is no substitute for real experience. No school can give you anything more than an introduction to programming no matter if you spend a year or four years learning and expanding your knowledge. There’s a wonderful article by Peter Norivg that I like to give anyone whose interested in making programming a profession. You can’t take ten years of experience and condense it into a quick fix or four year series of courses. Experience will always be your best teacher.

Got a few minutes? Check out the best tools to test your websites responsiveness.

Use Play Testing To Reduce Your Game Development Costs

Leave a comment Standard
Play Testing

What Is Play Testing?

This is a technique where you build a working version of your game and play it before you ever release the game to market. So you may be asking yourself, how does this reduce my game development costs if I need a working version of the game before I can play test it? The answer is simple: create your working game in an inexpensive medium. So what if your marketable game is going to have cutting edge graphics or high poly 3D models or even stunning visual effects that require months of complex mathematics and physics and matrices — with play testing you can see how well your core gameplay and mechanics work (or fail) without any of those expensive bells or whistles and in a lot less time.

How Do I Play Test?

I generally break this down into six steps.

1. Define your core game components, mechanics and boundaries

Start by sitting down and thinking about the core components of your game. How does your game work? How could someone play a physical manifestation of your game?

2. Write the game rules

Now that you know all of the components of the game you’ll need to write up a set of rules. Your play testers will use these so they know how they should play your game. If you can’t identify any rules for your game then you’ve found your first problem — you don’t actually have a game yet and it’s time to go back to the drawing board.

3. Gather your materials

Not all games need materials but you probably will even if it’s as simple as a few pencils and some blank sheets of paper. It’s time to visit a local arts and crafts store and buy whatever you think is necessary for someone to play a simplified version of your game — be creative to keep your costs low (ie use paper balls instead of nerf balls). You will need enough materials for at least one person to play your game. If your game is multiplayer you may need to invest a bit more so you can let multiple people play together.

4. Get lots of people to play your game

This is pretty much self explanatory but it’s also a really deep topic. Other than to say the more people who you can get to play the better, I’ll come back to it later.

5. Analyze your results

You can take a lot away from a play testing session. Did your player(s) struggle understanding the rules or sticking to the rules because they weren’t clearly defined or they didn’t make sense. Did your players pick up the general mechanics and components of the game quickly? Even if you have a negative response to both of these areas don’t panic! This is a good indication that your rules need improvement and that other materials or aids might be required (ie tutorials) before your players can really understand what you’re asking them to do.

6. Finding the fun

Ultimately your play testing session boils down to did your player(s) enjoy themselves? Was it so long and complex that they quickly lost interest or was it so fast paced that they finished almost as soon as they started? Where they laughing and becoming immersed in the experience or growing frustrated and angry? Did they feel sufficiently challenged? Some people find asking their play testers questions about their experience helpful and often times will ask for them to fill out a feedback sheet or a survey when they’re done. Personally I prefer just watching people play. Watching someone play your game will give you a huge amount of feedback and target areas in need of improvement all without breaking the bank. Remember that it’s okay to go back to square one and start again if your play testers don’t have a positive response to your game. The best part about negative feedback is that it just saved you from spending lots of time, energy, resources and money on a game no one thinks is fun.

Who Should Be Play Testing Your Game?

Okay so I kind of glazed over step four because I wanted to devote a whole section to it. I always start play testing with my target audience. Your target audience should be the age range and gender you believe your game will most appeal to. For instance, if I was intending to make a game for young children I would keep in mind their computer skills, the types of devices they are most likely to play on, their hand-eye coordination, their cognitive abilities in understanding themes, stereotypes and story development. Each of these would be adjusted based upon what I expect young children would find fun and amusing — loud silly noises, larger buttons, brighter colors, less text to read and rules introduced slowly and over time to build complexity.

Now your target age range and genders should all be play testers — but so should other groups. Don’t limit yourself to only your target audience or your may miss gaining valuable insight to how people play and interpret your game. Although you may be designing a game for young children you may find that your target audience has missed it’s mark when the young children have only negative responses to your play testing sessions while a different group of play testers find your game the perfect mix of fun and challenging entertainment.

There’s also a matter of size to consider. Even if your game is single player, what happens when you ask two people to play it together? This may (or may not) change your game dynamics for the better or lead you in a completely different direction that ends up becoming something much more successful that what you had to start with. In that same vein, push the limits. What happens if you triple the number of players who are playing at a time? This is especially important for multiplayer games where your play testers end up being on a small segment of the number of players who will ultimately be playing your game. You might suddenly find your calculations for resource management fall short when your player base grows exponentially or that the influx of players completely changes the pace and feel of the game — for good or for bad.

So, What Are The Advantages of Play Testing?

  • Testing early makes it easier to discover and fix problems
  • Increasing and decreasing the number of players at a time can help you find new and interesting perspectives and aspects of your game you had not yet considered improving or expounding upon — and they may be the best features of your game
  • You can work in a controlled environment and see how your games is affected by a specific number of players influences game factors such as economy, resource depletion, or competition.
  • Watching people play will help you areas of the game players find confusing or not challenging enough
  • You can find your true target audience, not what you think or feel your target audience should be
  • Players can give you valuable feedback before the game is put out to market
  • Reduced costs of game development, you won’t have to go back and fix features of the game players don’t like when the game is out to market — you’ve already identified those areas through play testing
  • This gives you the ability to go back to square one at any point in time, and then bring your changes back to your play testing groups until you get it right

Summary

Game development is expensive so do yourself a favor and make sure you’re spending your money on a game that’s going to help you reap the rewards of all your hard work. Play testing is easy and much cheaper than spending your money on a game that’s only going to flop when it hits the market.

Flash AS3 Tutorial: Callbacks or passing multiple parameters to event listeners

Comments 4 Standard

So one of the things I’ve found in developing my MMO is that there are numerous times when I need to pass back more information than just the event data when I’m using event listeners. One scenario that I run into a lot is when I want to use the same event handler on multiple objects or movie clips but some variations in event target changes how the event handler should respond making it  impossible to use a single event handler on multiple objects.

Callback Functions

So just like in Javascript you can create a callback function in AS3 which will put additional variables into scope for the event handler. This is an example of how you can pass width, height and color parameters  to an event handler using a callback function:

//the objects you want to use an event listeners on
var myObject1:Object = new MyObjectType();
var myObject2:Object = new MyObjectType();

var myColor:uint = 0xFF0000; //red
var myHeight:int = 100;
var myWidth:int = 100;

//it doesn't matter what type of event you put on this but your callback's event handler must
//take the same event parameter type. So for instance if you send MouseEvent.CLICK then your
//event handler nested inside your callback must use a MouseEvent parameter
myObject1.addEventListener(MouseEvent.CLICK, onObjectClickedHandler(myColor, myHeight, myWidth));
myObject2.addEventListener(MouseEvent.CLICK, onObjectClickedHandler(myColor, myHeight, myWidth));

//this is the callback function that takes multiple parameters and puts our
//parameters into scope for the event handler function
function onObjectClickedHandler(color:uint, height:int, width:int):Function { 

  //now let's change the color for some fun
  //the next time you click on an object with this event listener it will change to blue
  myColor = 0x0000FF; //blue

  //this is the nested event handler. Color, height and width variables are now in scope
  return function(e:MouseEvent):void {
     e.target.width = width;
     e.target.height = height;
     var myNewColor = new ColorTransform();
     myNewColor.color = color;
     e.target.transform.colorTransform = myNewColor;
   }
}

Game Journal 1.2: Games You Hate To Play

Leave a comment Standard

Exercise 1.2

In my previous post I analyzed how I play, how someone else plays and then compared and contrasted the two. For this exercise you’re supposed to find a game you hate to play. Describe what you don’t like about it, why you don’t like it, and how you feel it could be improved.

The Thin Line Between

So I used to be a fan of Farmville when it first came out. It was something I hadn’t seen before and harvesting my strawberries gave me a good excuse to jump onto facebook and check out what was going on. However that quickly became a love/hate relationship. I absolutely can’t stand Farmville now and here’s all the reasons why.

  1. God that song. It repeats over and over again to no fricking end and it’s so upbeat that it reminds me of a poor attempt at a fake smile.
  2. Plant, Grow, Harvest, Repeat. Hmm I’m starting to see a repetition pattern going on here. Other than a different image and a different amount of gold from harvesting one crop over another this game is extremely repetitive.
  3. Time spent versus actual reward. So I wait 8 hours for a watermelon to get to harvest and then I only get 200 some coins for it? I find it takes way too long to advance through the game and the rewards don’t feel worth the time I spent waiting for them.
  4. There’s no point to the things you can buy. Buying a goat doesn’t mean you have fewer weeds and building a barn doesn’t enhance how quickly you can collect coins from your animals — if you can collect coins from it at all. What’s the point of letting people buy something that doesn’t effect anything else? Why would I want to buy something that doesn’t do anything?
  5. Damn you request messages. Would you send me a special green chicken or visit my farm to speed up the time it takes me to harvest a crop? Sure — if I didn’t have 15,000 requests all demanding the same thing. Famville you do a great job at sending me more spam in one day than all my email addresses combined.
  6. Specials that aren’t so special. So… how does a green chicken do anything more than your typical white one? Oh wait, it doesn’t. Why would I pay $5 for a green one that doesn’t do anything when I can get a white one that doesn’t do anything for free.
  7. Bad company reputation. I know this isn’t a mechanic from the game itself but it’s one of the reasons I don’t like it so I’m going to add it anyways. When your company motto is along the lines of “don’t make it, just take someone’s good idea and drown them out with a larger advertising budget, resources and staff” you get a big fat F in my grade book.

Suggested Improvements

Okay so the easiest thing is to go down the list.

  1. Please change your song, or at least add a variety of music to the game so I don’t have to listen to the same thing over and over again. Maybe a sound off button would be a good choice too? I shouldn’t have to turn off my speakers just to have an enjoyable experience with your game.
  2. Yes I know the game is about farming but a bit of variation never did anyone harm. Maybe you could harvest certain plants for their seeds rather than coins, or sell them to friends. What about adding dead/wilted plants into a compost pile to make fertilizer, or even using crops to create or trade for another useful object in the game. Emphasis on the useful.
  3. If I spend 8 hours waiting for something I sure as heck want something more than a lousy 200 coins. How about a rare seed, or fertilizer or even a random event (for good or bad, anything to break up the monotony) that occurs as a result of being crazy enough to keep coming back to your game.
  4. If I’m going to buy a goat please make it meaningful. Perhaps cows could decrease your growing time or increase the rate at which you accumulate fertilizer — something other than taking up space you could be using to harvest crops.
  5. Limit the number of request messages a person can get in a day. Or at least stop sending me requests until I’ve answered (aka declined) the requests I already have. Maybe add an option to opt out of requests completely so I don’t have to be constantly bombarded with them.
  6. Make your special items special. I don’t care if the green chicken doesn’t do anything more than run around and infect the other animal’s with it’s zombie virus. Heck, zombie animals could be crazy awesome.
  7. I would really love to see what Zynga’s game designers can actually do — besides taking someone else’s hard work, re-vamping the graphics, and calling it a brand new game.

Heh, after writing this I somehow feel as if I’ve just gone 10 rounds with Zynga in a boxing ring. And the winner is….!