Friction for Smooth Movement

One of my self challenges for 2015 is to create 1 game a month starting in February. So I decided to start with a classic type of arcade game, a scrolling shooter.

The first implementation of the game only moved when the player was using input to control the ship. As soon as the player let off the key or stopped touching the screen, the ship would stop. This did not feel natural at all. In order to give the game a smooth and more natural feel, I decided to introduce a friction factor so that the player is slowed down a little until coming to a complete stop. Like this

If velocity in x direction >= friction
velocity is reduced by friction amount
If velocity in x direction < friction velocity is 0 Same for the y direction. You may need to play around with what the friction value is to determine what feels natural. Also, the frame rate that you choose for your game will affect what this value is. Note: you may need to account for both positive and negative velocities, depending on how you implement movement in your game.

Monkey-X and Connecting to Your Server

While traveling to visit family this past weekend I was attempting to set up a simple high score server for Prism Ship. I decided to use Sinatra for the backend because it would allow me to make a very simple and quick server using only a couple of lines since I don’t need an interface of any kind. Little did I know this simple task would turn out to take several hours.

This was partly caused by my lack of familiarity with Monkey-X and partly allergies.

Backstory

I was staying with some relatives and the females all went shopping and what not. My brother-in-law had made plans to spend the afternoon gaming at a friends house (Dark Souls II anyone?) so I tagged along figuring I would just program while they played. Better than sitting in an empty apartment for 5 hours right?

I had been to this friends house before but forgot about the pets. Normally I don’t have any problems with dogs or cats and didn’t the last time I was there (which was probably because we spent a majority of the time outside on that visit). However, this visit caused very annoying allergy type symptoms to be present for 4.5/5 hours.

Now, the server was simple enough to set up. Just a few lines of Ruby using Sinatra to test.

require 'sinatra'

get '/' do body "High Score List" end

It’s really that simple.

First Problem – Different Domains

I noticed that despite following the instructions in the documentation for the brl.httprequest module in Monkey-X, I was not getting expected output. So I opened the dev tools in the browser and saw this:
Access-Control-Allow-Origin: access denied
After a brief investigation, it seemed to be related to CORS (Cross Origin Resource Sharing). It was caused by trying to run the game on the localhost and accessing the Sinatra server running on Heroku. This is fixed with a little addition to the Ruby code:
require 'sinatra'

get '/' do response.headers['Access-Control-Allow-Origin'] = "*" body "High Score List" end

This is not very secure, but it fits our purposes for the time being.

Second Problem – Not Carefully Reading Documentation

A nose that is running because of excessive cat and dog dander will keep you from thinking straight and reading carefully. I missed an important line in the HttpRequest documentation that says – “Your application must continously call UpdateAsyncEvents at regular intervals (for example, once per OnUpdate) while an http request operation is in progress for it to complete.”

My little program was sending just fine, I could see the server send back a nice HTTP:200 code, but the game would not fire the OnHttpComplete method.

The very next time I sat down to work on this problem, it took less than 5 minutes of googling and reading to find the cause. I put the UpdateAsyncEvents line in and everything just started working.

Moral of the story

Read documentation carefully and try not to program somewhere that will cause you to have a runny nose (or other types of distractions).

Mini Ludum Dare 56 and First Game

So I had heard about Ludum Dare game jams before, but never participated in one. It just so happened that they were running a very loosely ruled 48 hour mini jam this past weekend and I submitted a game for it (and its actually kinda fun).

You can play it on itch.io

Prism Ship – Game 1/11

One of the hardest parts was I was trying to make the controls touch friendly, so it could be played on a smart phone or tablet (screen size/ scaling still needs to be made mobile friendly). The touch controls are a little more limited than the keyboard consequently. The keyboard allows movement in all 4 directions using WASD or the arrow keys while touch only allows left and right movement by touching to one side. I actually find it easier to drag my finger along under the “ship” to move it (which is why there is space under it).

Originally I was just drawing boxes to the screen, but forcing the browser to draw every update is a little slow and resource taxing so I made some simple graphics (that are essentially the same boxes) using a wonderfully useful and simple site called make8bitart. The interface is intuitive and very easy to use. Saving is as simple as dragging the image to your desktop from the browser. Highly recommend.

Lots of improvements to be made but not bad for my first game. Next week I will begin working on a simple high score server for it.

X Marks the Language

So, I accidentally discovered an awesome little language for game programming. There I was, browsing Hacker News and clicked a link to read some blog post. The post was well written and interesting so I noted the url to come back for more later.

A week later, wanting something to read, I started going through a couple older posts on the previously noted blog and came across this article on community and vibrancy. In it the author referred to an amazing community around a language that most “real” programmers look down on and the amazing productivity that people seem to be getting out of it. I checked out the language, which in turn led me to a spinoff language/framework that had been created.

X Marks the Monkey

The language in question is Monkey-X. It is for game programming and has a lot of similarities to Basic. What is cool about it is that it is designed to write the games once and publish them on multiple platforms, including Xbox, Mac, Playstation, Android, IOS, Windows, and the Web.

Two of the things that really got me excited about it though is that for publishing to desktop and web, it is completely free (as in no dinero required) and it is available to run on Linux. Not that your average gamer plays on a Linux box, but I sometimes do (Battle of Wesnoth anyone?).

Get Started

If you want to try it out you can download it here, although you will need to create an account on their website.

In addition, there is a fantastic series on getting started with the language and even making a simple game on youtube. The links can be found in the Monkey-X forum. Or you can go directly to the youtube channel.

Programming Action in 2015

Not sure why but the new year always seems to be a good time to make plans. 2014 was the year of study. I spent a lot of time reading books and blogs, listening to podcasts, and watching talks on a variety of topics that had a common theme of becoming a person of action instead of a person of wishful thinking.

Therefore, beginning of a new year, it’s time to put this blog to work.

Lots of goals for 2015. Will I accomplish all of them, probably not. Will I hope they happen and do nothing to maker it so? Not this year. This year shall be different.
An action plan will be created to help in the accomplishment of the goals.

PROGRAMMING GOALS:
1. Write 1 blog post every week (52 total)
2. Write 1 game per month (11 total, using the first month to get prepared)

BUSINESS GOALS:
3. Get and complete 6 freelance programming/consulting gigs.

I have other goals for the year, like learning to play guitar, but this blog will be focused on the these three goals.

Looking forward to making them happen.

Shallow Copy Got Me

How to properly initialize a 2D array in Ruby

I am working on a small game and that game happens to have a two dimensional map. In trying to be minimalistic, the implementation of the map is just a 2d array. For some reason, I decided it was a good idea to learn a new programming language and 2 new frameworks to make this game.
When creating an array in Ruby, one can prefill it easily like so

myarray = Array(10, 0)

So without reading any documentation I thought “well I think I know what I’m doing” and proceeded to write

myarray = Array.new(10, Array.new(10, 0))

The problem here is that it makes an array of 10 references to the same array. The right way to do it is to use a block following a call to Array with only 1 argument. This is conveniently listed fairly early on in the Ruby Array documentation.

myarray = Array.new(10) { Array.new(10, 0) }

Its just one of those things that happens when you are learning a new language.

The State of Web Printing

Cross Browser Printing is Annoying

My current task at my current place of employment is to get a certain web page to print to a single piece of paper without heavily modifying a pre-existing print stylesheet and getting it to work on both Firefox and IE. Not all the browsers have to be the same, they really just need to print to 1 page.

The first problem that we come across is that margins and padding are way different in each browser. After a quick web search, the culprit appears to be the use of px and pt. When printing apparently the em element is a better choice as it is more consistent unit of measurement and px and pt are arbitrarily handled by printers and browsers alike.

The second problem the @page CSS directive and page margins. It seems that each browser wants to handle things differently, which is not new and not entirely wrong according to the W3C which as an article about that here. But that does not help our problem which is to disregard how the browsers want to display things and make sure that things come out the way we want.

For once, IE is behaving the most sensible for our purposes. It takes the @page margins and sets the printed page margins to what we want. Firefox, however, makes things difficult by taking the @page margins and adding them to the browsers default printer settings. Why, I have no idea, but we have to deal with it.

The goal is to keep the whole website on 1 stylesheet and also not to have any browser specific hacks or browser sniffing. Unfortunately, if we want similar behavior between the 2 browsers in this case, the best way that I have come across so far is to add a directive to our print CSS that is Firefox specific. The @-moz-document directive is used so that we can set the @page variable inside it to trim the margins back for just Firefox. Other browsers will ignore this directive as it really doesn’t tell them to do anything.