Honestly, I am no where near where I thought I would be with game 1 at this point in the year. But that is why these kinds of post are important and why I scheduled them into my writing schedule.

Time seems to be flying by so fast these days, it is already over half way through February. I do not have a play testable version of my game yet. I have not yet made an MVP.

Part of the exercise with this first game is building and releasing an Android app. With that in mind I am trying to build it using MeteorJS (which cross compiles to Android) and at the same time using Meteor’s integration with AngularJS.

What Is Done

I have been working on a Meteor-Angular tutorial and have gotten through a good bit of it and learned a lot. Usually with things like this, I take a tutorial and kind of massage it into the app that I actually want to make. So right now I have a basic tutorial app that just needs some massaging.

I also have the basic set of choices and end goals for the game set down. I actually had to stop myself working on that so that I could begin making the minimum version of the game in order to test whether or not it will be fun.

What Needs to Be Done by End of March

Basically, I need to write a choice engine in Meteor-Angular and then fill in the story and the choices. Once that is done, building the actual Android app is as simple as running:
meteor add-platform android
and
meteor run android

I also need to setup a Digital Ocean server to host the game. Although technically it could be hosted for free at meteor.com, it would be really slow and take some time to load up.

Additionally, I need to play test the crap out of it to make sure it works and has at least some element of fun to it.

What Is Not Perfect Yet

I think I am making the mistake I made end of last year by switching languages/frameworks a little and trying to learn one and stick to a schedule. This remains to be seen.

Also I was planning on doing some sketches to bring some visualization into the game, but these might not get done in the interest of keeping a schedule. They might be added later. Or I might see about learning to utilize a service like Fiverr.

Time to Write Code

I have been focused on game design, writing, and psychology improvement lately but now it is time to take some action. It is time to make this game.

Get out there and make what you designed.

This time the math was not as complicated, but still not the sort of thing the average person has to use on a daily basis.

For Infinite Zip, my current game project, I needed to figure out if the player is on the zip line or not. Currently, the game randomly generates a bunch of points and ties them together with lines.

I am working on putting “holes” in the line to give the player something they have to jump over but for now we are only concerned with keeping the player on the basic line.

What We Know

So we have a few bits of information that we know from the start.

We know where the player is.

From that we can figure out which two points on the randomly generated line that the player is between. This gives us a start and end points.

We also know the players velocity.

Using these few pieces of information, we can calculate if they are or are not currently above the zip line.

How to Calculate What We Need

What we are dealing with here is two right triangles with the same ratios but different lengths. This makes everything pretty easy and turns it into a simple algebra problem.

What we need to know is what point of the line we are comparing to the player’s height. To calculate this we simply multiply the distance from the player to one of the end points by the difference in height of the end points, then divide by the width between the two end points.

It looks something like:

Y1 / X1 = Y2 / X2

Where we know Y1, X1, and X2. So we find Y2 by changing the equation to be:

(X2 * Y1) / X1 = Y2

and that gives us the height of our line at our player’s current X position. So if the player’s Y is greater than the calculated Y, they are below the zip line and should probably be falling.

Wrap Up

Games, especially any type of games with action or real time, often involve physics and that means math.

Sometimes the math is pretty straight forward.

Until next week, keep getting better.

After a week of absolutely no productivity to speak of, I have finally been able to sit down and work on game #3 some more. Very excited about this game as I am learning a lot about different aspects of game programming.

Today, I had a simple goal of adding boundaries to the world. Before the player could just go off in one direction to their hearts content (or until their position was a number too big for the processor I suppose).

Maybe I hadn’t looked at the code in a bit too long, or maybe allergies are affecting my work. Regardless, the first solution I implemented seemed to do absolutely nothing. So I did the only debugging thing that I know to do when nothing else is working.

When in Doubt, Print Debugging Information

My first solution was to turn the players velocity around if their position crossed the boundaries.

This actually did have an effect. When you took your finger off the screen (or lifted it off the mouse button), the character would stop (may add this as default behavior).

The problem was, as long as you kept your finger down the game would just let you go and go still. So I printed the velocity and position to the screen to see what was happening.

Feedback Is Important

The moral of the story is that feedback and information beats guessing every time. It will help you make faster, better corrections.

With the feedback to the screen, I could see what was happening as I made code changes. It helped reason through what the next move should be.

Since changing the velocity was not working, I decided to just set the players position to the edge and their velocity in the X or Y direction to zero (depending on the edge they hit).

This had the wonderful affect of making the camera move without the player when you hit a boundary.

Fortunately, swapping the order the player and camera were updated solved the problem.

Until next time, keep making awesome things.

Yeah, game 2 out on the web!

I have had a complete blast making this game! It was one of the most challenging and rewarding things I have ever done. You can check it out here.

Repel Boarders

This game is a huge detour from the first one. While Prism Ship was a Galaga-esq shooter, Repel Boarders is a turn based tactics game. A video game collecting friend tells me its very much like Advanced Wars.

Challenges

Doing a turn based game presented a lot of challenges. First, most tutorials for game engines are trying to show off things like movement, animation, and how great their frame rate is. I actually have yet to stumble across a good turn based tutorial. In other words, it felt like blazing a new trail. If you know any good tutorials on turn based games, I will be all ears. There is a lot more I could learn about them.

Challenge 1 – Input

One of the problems I had initially was the input. I left the frame rate high, thinking I would try to animate the unit movement or attacks. This caused a lot of accidental double clicking.

The solution was two-fold, both time based. First and obvious was drop the frame rate. The screen does not need to be updated 60 times a second if you aren’t doing any animation. Second and similar was to check when the player last clicked or touch the screen and limit how fast to accept inputs.

Challenge 2 – Scope Creep

A second problem I had was wanting to do to much. I had to keep reminding myself that this was supposed to me an MVP of a game. Regardless, some cool extras snuck in.

These were mostly based on annoyances when testing. An information tab, health bars, and deselecting a previously selected unit were all things that probably could have been left out for the game to work, but they sure are nice to have.

Challenge 3 – AI or Network Multiplayer

Another problem, one that I am currently working on, is having an Artificial Intelligence to play against.

The initial concept of course was for it to be pure multiplayer and the combat system was initially just set up for a “hotseat” mode where you and your opponent are at the same computer. Unfortunately, this requires you to have someone else present who wants to play the game if you don’t want to play yourself.

Ideally, I would like to implement network multiplayer (with matchmaking of course), but that is not likely given the time constraint I put on myself. Its time to start on game 3 after all if I want to hit the 11 in 11 goal.

Oddly enough, writing an AI for the game appeared to be easier than writing a multiplayer server and interface. And it seems to be. A simple, random “AI” was actually only a couple hours of work. The AI currently knows nothing about the game state. It takes a list of units, moves, weapons, or attacks and picks one. That’s it. Nothing “intelligent” going on there. But for now its good enough. Maybe I will get to come back to this game and polish it like it deserves.

Lessons Learned

1. Timers are your friend when dealing with turn based games.
2. Watch the scope of your game. Build nice to haves only after the core mechanics are done.
3. Even multiplayer games need a way to be played when everyone else is asleep or doing something else.

I am currently working on breaking down the first couple games into some tutorials. Be looking for them next week.