How polished for demo?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • How polished for demo?

      First off, awesome book guys. I've been coding c++ for 5 years and you guys both echoed a lot of my own thoughts on programming and taught me a lot as well.

      Does Teapot wars have enough polish as a game to show as a demo? Of course, I am not going to do that. I just want to know what level of completion I should aim for.

      For example, do I need things like volume sliders, the ability to save the game, exception handling, etc.?
    • RE: How polished for demo?

      That depends on what you want to do, but probably not. Teapot Wars is really just a tech demo to demonstrate the engine. That's not what you want. I'll probably spend anywhere from 2 - 10 minutes playing your game. I also won't be able to see your source code, so it won't matter much until the actual interview.

      In the end, what you want is something complete and relatively simple. A single level of a platformer, complete with UI, powerups, some kind of art (programmer art is fine but you should be loading assets), and a jumping mechanic that feels really good would be a fine example. Another example might be a top-down RPG similar to the old Final Fantasy or Dragon Quest games.

      The key is that the first 10 minutes of gameplay should feel good, which is really only achieved by peer review. Here's you do that:

      1) Find a friend or colleague who has never seen your game.
      2) Put them in front of the game on the main menu.
      3) Tell them you are look for brutally honest feedback.
      4) Tell them to start playing and to say everything they're thinking out loud.
      5) This ends the part of the playtest where you're allowed to speak. :)
      6) Watch them play the game and take notes. If they seem confused, write it down. If they get frustrated or can't get through something or don't understand some concept, write it down.
      7) If they ask you a direct question, it means something failed somewhere. Write it down and try to ask leading questions. For example, if they ask how to do something, ask them how they think it should be done.
      8) Once you're done, ask them for any final thoughts and thank them.

      You'll want to do at least five of these, preferably more. You'll get two different kinds of feedback, the first is technical. Some bug came up, or you had to run a cheat code to tweak something. Maybe they didn't realize they had to hit 'm' to go into the map view. You should fix these ASAP.

      The second kind of feedback is subjective. They didn't like some aspect of the story, or the boss was too hard, or they felt that an inventory system wasn't necessary. Implement any feedback you agree with and write up the stuff you don't agree with. In theater, we have a saying: If you get a note about your performance, ignore it. Once you get the same note multiple times from different sources, you'll want to pay attention to it. The say is true here. If someone says the inventory is getting in the way and you disagree, ignore it. If four of the five people in the playtest mentioned it (or even two out of five), you should probably cut it. As a game developer, you are completely blind to your own designs. You also never have the ability to play your own game for the first time, so you can't really judge that first impression.

      If it helps, here are two games I've written:
      bleachkitty.com/PersonalGames/FarmerBill/
      bleachkitty.com/PersonalGames/StephInDreamland/

      The first is called Farmer Bill's Almond Farm. I wrote it back in 1997 when I first started learning how to program and it's the very first real program I had ever written. It's a DOS game, so you'll need doxbox to play it. The input scheme is a bit wonky and most people don't understand it. It's based on the old Sierra adventure games, like the original Space Quest and Kings Quest. You hit an arrow key once and let it go to move the player in that direction. You hit it again to stop. This caused me to write the readme file, which you'll see in there. Because of all the feedback I got on the input system, my second game (which I sadly no longer have) used a more traditional zelda-style input system.

      The game itself is an adventure game set on an almond farm. You need to do chores and tasks and each level represents a single month out of the year. At the end of the year, you get your final score and the game ends. This game has a beginning, a middle, and an end. There's a difficulty ramp as well; the first few levels are very easy and get harder. By July, the game starts getting deadly.

      The second one is a bit more recent (I wrote it in late 2008). It's a platformer set inside the imagination of an artist. It's closer to what I'd expect for a modern game. Most of the iteration was spent getting the jump mechanic right as well as the various level features. If I were actually going to use this, I'd finish the boss fight at the end of the level. Other than that, I think it represents what I'd expect from an entry-level game programmer.

      Remember, we have to be able to ship your code. Make sure you present something that is as close to shipping quality as you can get.

      -Rez
    • Wow, that was a very quick and detailed reply! I'm definitely recommending this site and your book to my friends.

      Ideally I would be going for a mid-level rather than entry level position. In the end I don't want to take a big salary hit. How much would you raise the bar for something like a "Senior Software Engineer"?
    • Originally posted by DieselMaxPower
      Wow, that was a very quick and detailed reply! I'm definitely recommending this site and your book to my friends.

      Hahaha, thanks. :) I'm glad you're enjoying the book.


      Ideally I would be going for a mid-level rather than entry level position. In the end I don't want to take a big salary hit. How much would you raise the bar for something like a "Senior Software Engineer"?

      Okay, I'm going to be very direct because that's what I would want in your place.

      This is almost guaranteed not to happen. I would never even consider an engineer for a senior position without real industry experience. I *might* consider someone with several years of non-game experience for a mid-level position, but probably not. Most engineers start at the bottom and work their way up. Some companies even have that as their policy (Planet Moon, for instance, always hired at a junior level and promoted you to your level of ability). Furthermore, most engineers with a senior title have 10+ years of experience in making AAA games, unless you're making simple casual games, then it's more like 5 - 7 or more (the standards are a bit different). This is professional experience in the industry.

      The harsh reality is that there are MUCH fewer jobs than there are people applying for those jobs. We don't hire candidates without industry experience for mid or senior levels because we don't have to. If I posted a position for a mid-level gameplay engineer on The Sims 4 right now, I'd get over 100 resumes, half of which are probably worth a serious look.

      The hardest part about getting a job in the industry is getting your first job. It's a paradox: you have to have experience before anyone will hire you.

      For what it's worth, I took a 40% pay cut when I jumped over to the games industry. It was the best decision I've ever made. Nothing beats doing what you love every day and getting paid for it.

      -Rez