Monthly Archives: October 2016

A Simple Side Scroller Design

This post is part of a series on beginning game creation with Monkey-X. You can find the previous article in the series here.
——————-

For your first game with Monkey-X (maybe your first game ever) we are going to create a simple side scrolling shooter.

Whenever I am getting ready to make a new game, I usually start with a simple 10 point check list called 10 things every game needs. I borrowed it from a fellow name Mark Rosewater who does some game design on a game called Magic: The Gathering for Wizards of the Coast, and we are going to use it here.

This is not the only way to design games nor is it super thorough, but I have found it useful to go through this exercise when I am getting ready to make a new game.

1: A Game should have a Goal

Your game should have pretty much 1 major goal. This is often the way the player wins the game. Like Checkmate in Chess, or getting the enemy flag to your base in some Capture The Flag.

For our side scroller, the goal will be to beat the Big Bad Boss.

Simple goal, to the point.

2: A Game should have some Rules

Whether it is a classic board game like Chess or an FPS like CS:GO, games need rules so the player knows what they can and cannot do to achieve the goal.

In Chess the rules layout which pieces can go where. In computer games, the rules are usually built into the code of the game and manage things like keeping track of the score and keeping players from doing things they should not be able to.

For our game we will have simple rules.

The player can move up and down, back and forth but cannot leave the screen.
When the player or an enemy gets hit by a bullet, they lose armor.
When the player or an enemy’s armor gets to 0 (or below), they are destroyed.
If the player destroys the Big Bad Boss, they win the game.

This is a simplified set of rules, but you get the idea.

3: Players should be able to Interact

If you do not have a way to interact with your opponent, you might as well be playing by yourself.

This is usually more relevant in a multiplayer game, but we will pretend the computer is a player in this game.

Our interaction mechanic is shooting and being able to destroy enemies.

4: Players who are behind should be able to Catch Up

There are few things worse than playing a game, falling behind and never having a chance to get back in it. Might as well give up at that point.

A lot of sports games have this built in. When a team scores in Football or Basketball, the other team gets the ball and a chance to score.

In video games this is often accomplished with powerups or extra lives that you can get.

We will build in both powerups and extra life mechanics into our game.

5: A game needs some Inertia to make sure it ends

Games that never end make players get tired of them very quickly. The ideal length is just a little less than what the player wants to play.

Regardless, you need something that pushes your game to end. Lots of games do this with a time limit. When the time runs out, the game is over.

We will sort of do this, but manage it by having our player move forward in the side scroller at a constant speed, and when they reach the boss, they have will beat him or lose.

6: Games need some element of Surprise

If you always know what is going to happen next in a game, it quickly becomes boring. Adding a little unpredictability or hidden information can make a game more fun.

For our side scroller, we will randomize the enemies and some of their movements to keep the player guessing.

7: Players need to be able to use Strategy to be able to get better at the game

If the game is completely random and no player skill is involved, players will see it as unfair and that there really is no point to play.

You need to have some element that the players can control and master to help them win.

For our side scroller it will be using their ability to dodge enemies and get kills. Maybe not the highest form of strategy, but not left up to chance.

8: A game should be Fun

You will notice that this is not number 1 in the list. Often the fun will come out of the other elements that make up your game and fun is hard to predict.

Often you find a fun mechanic and build your game around that. Sometimes you borrow from ideas you already know are fun like side scrolling shooters.

If you want to learn more on the subject of fun, I would suggest reading things like 8kindsoffun.com and theoryoffun.com.

9: Games should have some Flavor

Flavor here is meant to mean the setting or world, often referred to as the theme, that the game takes place in. Is your flavor a galaxy far, far away or maybe in the Caribbean on a pirate ship in the 1700’s?

For our shooter, the player will be captain of a submarine fighting through undersea machines and beasts.

10: A game should have a Hook

Last but not least, people need a reason to play your game. We call this a Hook.

You may have a great game, but if you can’t convince people to play it then it won’t matter.

Our hook will simply be, “Save the planet from the alien invasion”

Design Done

Going through some sort of process like this every time you make a game will be really helpful.

You don’t have to go through these 10 steps and even if you do, your game does not need all 10. I have simply found this a helpful exercise for designing games and would recommend it to you as well.

Now to the hard part. Making the game.

Tutorial Part 3
Tutorial Part 5

How to Get SVG Images to Cooperate

Recently I was converting a mocked up webpage to an actual webpage and was using the <svg> element to handle some image resources. If you don’t know what SVG is, it stands for Scalable Vector Graphics. Its all in the name.

This element has not been common in most sites I have come across but is pretty powerful for handling the scaling of images and maintaining their resolution.

However, it is a little tricky and I could not find documentation that clearly explained how to work with them effectively so I will attempt to do that here.

The Image Tag

This is specifically about the <image> element inside of the <svg> element.

There are several tutorials on how to use svg to draw what you want in your webpage but none sufficiently explained how to handle an svg image that was already created.

Adding the image to the page is easy enough, just put it in an image element inside an svg element.

Sizing On The Page

Since the <image> element is contained within the <svg> element, to determine how large the area it will display in on the page, you set the width and height attributes of the <svg>:


<svg xmlns="http://www.w3.org/2000/svg" width="150" height="150">
</svg>

Using the Viewbox

<svg> has an attribute called the viewbox. This is like a little window that you can set for which part of the image you want to see.

It gets set to a string of 4 numbers separated by spaces, like “0 0 300 150” or something like that.


<svg xmlns="http://www.w3.org/2000/svg" width="150" height="150" viewbox="0 0 300 150">
</svg>

The first number is the x offset of the viewbox which controls where we start viewing the image from the left hand side.

The second number is the y offset of the viewbox which controls where we start viewing the image from the top.

Both of these can be negative, which moves the viewbox off the image.

The third number is the width of the viewbox. If your image is 300px wide and your viewbox width is only 100, then you will only see about 1/3 of the image horizontally when you display it.

The fourth number is the height of the viewbox. It behaves just like the width. If your image is 300px high, and your viewbox height is 150, you will only see about 1/2 of the image vertically.

I would recommend that you play around with these values on JSFiddle to get a solid understanding of what is happening. On this particular fiddle I put the Mozilla Developer Network example of an svg image.

Image Element Width and Height

The width and height attributes of the image element are where you start seeing why svg’s are useful. You can scale the image pretty much as large as you want or as small as you want while still maintaining resolution.


<svg xmlns="http://www.w3.org/2000/svg" width="150" height="150" viewbox="0 0 300 150">
  <image xlink:href="some_svg_image.svg" width="25" height="25" />
</svg>

This is great for logos and icons, especially when viewing on mobile devices compared to desktops. It allows you to reduce the number of viewable assets you have to make.

Note About Browser Compatibility

One of the reasons that I even did this post was because of the various behaviors across browsers. Initially I was not messing around with viewboxes and the various x and y attributes, but when I started testing my work in different browsers, I found that if some of these values are not set, certain browsers render the images differently.

If you want consistent display across browsers you should make sure to set all of these attributes correctly.

Additional Resources

Although not exactly what I was looking for, the following still have many useful details about working with SVG images in html.

Basic Game Structure

This post is part of a series on beginning game creation with Monkey-X. You can find the previous article in the series here.

A Basic Game Loop

Most games follow a similar pattern of running through the game logic, drawing updated information to the display, then repeating until the game is over.

The special functions that we discussed in the last section handle this loop in Monkey-X, OnUpdate and OnRender. You can control how often they are called by setting the SetUpdateRate. Using SetUpdateRate(30) would update and draw your game 30 times per second. And SetUpdateRate(60) would update and draw your game 60 times per second or be 60 fps (frames per second).

** Note: the SetUpdateRate function does not guarantee that it will be able to run that fast. It all depends on the machine the game is running on, how complicated your game logic is, and how many things your are trying to draw to the screen each time.

Game States

For most games, what is run during the update section of the loop and what is displayed is controlled by state.

When the game is in the MENU state, we draw the menu and watch for player input for which state to move to next. When the game is in the PLAY state, we draw the player’s character and the map, and whatever else and listen for input to move the player around, check for collisions or perform other game actions.

This is what we will use to manage what goes on each time Monkey-X calls OnUpdate and OnRender.

So let’s get you started making your first game.

Tutorial Part 2
Tutorial Part 4

September 2016 End of Month Goal Review

The weather is changing, the goals are not.

Goals

Write 3 Blog Posts Per Week and Publish 2 – Again I only got out 5 posts. This is the third month in a row at this rate. The writing goal was 12 and the publishing goals was 8. It is obvious to me I have not been keeping to my schedule. Time to draw it up again and stick to it.
1 Game Designed, Created, and Released Per Quarter – Drone Tournament (Game #2 of 2016) programming is nearing the glorious day of launch. These last few weeks the server and client sync bugs were worked out and some serious refactoring work has been done. I might even finish it before the end of the year. No work was done on Game #3.
1 Book Read Every 2 Months on Game Design – Read several more chapters in the book on creating games with PhaserJS. Learned about some new technologies I had not heard about and some resources that will be valuable in making games in any language. Will be adding these to the resource page soon. Also had some good ideas about using a Monkey-X physics engine just from reading this book. Well worth the investment.
1 Article Read Or 1 Video Watched About Game Design/Creation Per Week – I found a series on game balance that has some long, supremely valuable articles on the basics of designing games. Some really excellent material and would highly recommend the read.
Get 100 People Reading Evolving Developer Per Month – Progress = 100%. Wow. Went from 0 readers last month to just over 100 people getting their eyes on the blog this month. How you ask? Well I did something absolutely crazy. I shared a couple posts. The first one I shared on Hacker News and in a programming Facebook group I am a part of. This alone got just over 100 unique viewers. The second was not quite as popular and I only shared it through Hacker News but still showed a small spike in traffic. So getting 100 viewers was slightly easier than I thought. Now we have to figure out how to get them to come every week.

What Went Right

Finally made progress on the viewership goal. In fact hit it for September. And it was all accomplished from taking a single simple action. Why didn’t I do this before? Also the game is working. Core game mechanics are finished and refactoring has begun. Slow steady progress marching forward. Additionally, getting great ideas from the book I am reading and the articles that I have found.

What Is Not Perfect Yet

Writing volume is still lower than intended. This is partially to do with assigning more of my time pie to getting Drone Tournament finished. Also, did let the amount and number of articles I read / videos watch of game design drop a bit. Main issue is the writing volume though.

Corrective Measures

It all comes down to routine. Must not let the routine get so easily interrupted. The writing must go on, both in code and in articles. Additionally, I am revisiting my article writing schedule and planning out which articles need to be written on which days.

First time to hit 100 viewers in a month, not much but it is progress.

Don’t Leave a Festering Pile

One of the most memorable statements from Clean Code was the author describing some of his own example code as a “festering pile.” And he doesn’t just use the term once, he uses it multiple times.

The most important statement however comes after he goes through how he cleans up his code and he is going over key points at the end of the chapter.

It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally.
– Uncle Bob in Clean Code

Get It Working, Then Clean It Up

Don’t get me wrong, you should get your code working. If it does not work, it is completely useless.

But that is not where you stop.

When you stop here, it becomes difficult to add features to your program and makes it more likely that you will introduce errors later.

As a professional programmer and creator, cleaning up your code after you get it working is a must.

What’s That Smell?

As I am working on my current game, I started noticing that some of my own code was becoming a bit of its own smelly, festering pile.

Classes were getting a little clunky, functions where getting a little too long, and it was taking longer to make small changes.

Since I am trying to write the same logic in 2 different languages (Monkey-X for the client and Ruby for the server), having clean code was even more important to be able to replicate the logic in a second language.

And with the code getting a little cluttered, there started being some hard to figure out bugs where the client would show one thing, but the server would do another.

I finally got the code behaving the same and it took longer than it should have.

Programming Febreeze

Now it is time to get rid of some of these smells. The way to do that in programming is refactoring.

This is basically what Clean Code was all about. Changing your code to be more clear and designing the classes and methods to be easier to change (think DRY and SRP) have your code smelling like fresh linen.

That is what I am working on now with Drone Tournament. My original goal this year was to finish a game every 3 months, but I don’t want a half baked game. So I am taking the time to refactor the code and clean it up because I am a professional.

Be a Pro, Clean Your Code

Ruby Mod Operator Does Not Behave As Expected

I am writing the multiplayer server for my current game in Ruby using Sinatra. Since it is turn based and not particularly performance heavy, this is not a problem. One of the cardinal rules of making a multiplayer game is don’t trust the client.

This means I needed to write the game logic for the game on the server.

Modulo

Part of the game logic involves taking an angle and a position and calculating a new position and angle based of a units performance stats. In order to simplify the math, I wanted to keep all the angles positive.

So if the angle is negative, I Mod it by 360 and then add 360.

If the angle is positive, I just Mod it by 360.

But then I change it either adding a units turn rate to it or subtracting the turn rate from it.

The client (written in Monkey-X) was working 100% as expected. But the server was giving me some weird results.

Negative Numbers Behave Differently

I have always understood Mod, often the % operator in language, to return the remainder from a division operation. And that is what it is supposed to do. In Monkey-X that is exactly what it does (incidentally it is the word ‘Mod’ in Monkey-X). And in Ruby, all of my positive angles where behaving as expected.

But for negative numbers in Ruby, something like:

-21 % 5

is not going to return -1, it returns 4 (go ahead and try it in irb).

How Do You Get The Remainder?

Funny enough, in Ruby you need to use the .remainder function on a numeric type to get a consistent result. So:


num = -21
result = num.remainder(5)

and result will equal -1 as expected.

TL:DR

In Ruby if you want the remainder of a number, use the .remainder method instead of the % operator, especially if you are going to hit negative numbers.