Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Week/Session 2

Sign in to follow this  


Yesterday was the second session of the Game Development I class. As mentioned, last week's assignment was to create a review for the game Chicken Attack. I didn't particularly care for the game, as you might determine from my review. We spent the first hour or so of class reading each others reviews and grading them. In this case I felt a teeny bit sorry for being in the class since peer grading was on something of a curve. We broke up into groups of six or so, and whoever had the best review got five pointes, whoever had the worst got three and everyone else got four. It was pretty much unanimous that mine was the best in the group. On the other hand, I didn't feel too bad about it since the rest of the reviews in my group didn't show much depth or critical thinking.

Essentially everyone wrote something of a check list style review with rating individual elements without really going into what made them good or bad. Some were essentially just "good graphics, bad sound, boring gameplay" with enough words to pad it out to one page. I think part of the problem is that most reviews you see online or in magazines are geared towards the audience of the game buyer. This is totally reasonable, and I'm not saying otherwise. However, as potential game developers, the ability to analyze elements of what are basic factors and see how they contribute to actual game play is important. For example, graphics were analyzed simply in the terms of eye-candy. Again, reasonable for a consumer level review, but not so reasonable from a review made by and for game developers. Analyzing graphics should occur on a deeper level, such as whether the game uses basic color differentiation, or whether the animation of static elements adds or detracts from feature recognition. Not only is this thought pattern important from the standpoint of game development, but it's also easier to make a page/word requirement when you're actually saying something rather than just trying to cleverly restate the same thing four times in the same paragraph.

I don't expect this kind of thought process from beginning game developers. However, I had hoped that there had been other serious hobbiests in the class, and it doesn't seem to be the case. And admittedly, I am a bit over trained. I think about these things all the time when playing games. (Except for first person 3D games, in which case I'm mostly thinking about not being sick. Which probably makes things worse.)

The individual group discussion and grading was followed by a whole class amalgamation of key points in the reviews of the groups. This would have seemed more productive to me if the teacher spent more time emphasizing the critical thinking parts of game analysis. On the other hand, I somewhat spiked the flow of things by going second and plastering some of my more in depth complaints on the white board.

The next part of class was a basic discussion of the various elements of a game. The discussion was a little over simplified for me, but considering the implementation system we're using is Game Maker, it seemed reasonable enough. Well, except for the aggregation of all events under a single event handler mechanism. This is how Game Maker operates, but having spent too much time working on low-level game application details, the lumping together of things such as collision events with user input events got under my skin. Also the discussion of the game loop was also not precise enough to my liking. The game loop was the basic three step "process input events, update internal state, render" game loop. However, the professor referred to processing input events as if that part of things was waiting on user input rather than processing queued input events. This isn't how most games work, nor how Game Maker works. The only real time you see that is in basic command line games made without actual input libraries.

Finally, we spent some time on learning how to deal with Game Maker. We basically went through the "hit the ball" tutorial that comes with Game Maker. From there we were given a short time to come up with variants on the basic program and seeing what the groups could produce. My group went with a variation of something that I was fooling around with while everyone was working on the tutorial material. The gm6 file for that is here. Again, my copy of Game Maker in class is non-registered, so anyone should be able to play with this one. What it should do is start with a whole mess of blue balls. When two balls collide with each other, they change color from blue to red and back. Clicking on the red balls gives you one point. Clicking on a blue ball gives you a negative point. When a ball leaves the field by the hole in the left, you lose ten points. There wasn't enough time to put a victory condition in, so I suppose the goal is to get as many points as possible before all the balls leave the room.

The assignment for next week is to play the 1945 example game with Game Maker and to think about how to implement it (in Game Maker).

In other, completely unrelated news, this is post 10,000 for me.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!