Sunday, 29 May 2011

Programming songs

Every once in a while I get listening to a song when I start doing a new kind of programming and I just start associating the two together.  For example, when I was taking C++ and I started getting into it, Ke$ha's Tik Tok had just came out and was playing all the time on the radio.  Now I associate the two and every time Tik Tok comes on, I feel like programming some C++ and every time I do some C++ I HAVE to go to youtube and put that song on. 

I know... the song isn't even that good.

This time around, I've started listening to a much better song, and I think I'll be able to live with having to put this on every time I do some server side java programming.  It's got this big sexy hook I think you guys are going to dig.

Wednesday, 25 May 2011

More books

So I've been planning some more stuff out for how the game is going to work, but I'm going to have to have a better idea of what to use on the server side.  I've been talking about it with some of my computer science friends and while some of the students see no problem with using PHP for the server programming, one of the guys (who actually works with a lot of server programming) recommended specifically not using PHP to handle anything at all because it's completely unthreaded.

He recommended something like Java with EJB3 or something more like that.  I've only taken enterprise server programming courses in .NET (which seems pretty similar with the whole "not caring about what the client is" deal and the whole "on an application server" thing), but I don't want to have to spend money getting that from Microsoft if I actually start making money.  1 student license probably won't cut it.

So, I went and picked up a couple of books on some JEE stuff, a book called EJB3 in Action and JAVA Concurrency in Practice.  That last one is just for a bit of fun.

Looks like a got quite a bit of learning ahead of me!

As a side note, I think I may have found an artist for the game. I still have to send him a message about what kind of stuff I need done up (probably after my midterm tomorrow), but I've seen some of his work and it's good.

Saturday, 21 May 2011

iPhone 5 release

So it looks like Apple got their stuff together for this next release and it's not going to be a staggered release for AT&T and Verizon like it was for the iPhone 4.  It's a shame, more Android phones could have been sold if they had.  Guess I'd better get started working on programming for the iPhone as well in order to do a simultaneous release too!

Thursday, 19 May 2011


There's so many more devices that I need to plan for than I had originally anticipated.  I didn't know so many Android phones / tablets had come out in the last year.

Testing to make sure stuff comes up on all of them is going to be a pain.  Hopefully tablets stick to 7 and 10 inch models.

I guess I'm going to have to include some sort of money-back if we can't get it to run on your Android device type of guarantee.  With how painfully slow the new virtual device manager / emulator is, I'm probably going to have to test, at most, to see if something actually shows up on the test screen.

I wonder how other app makers do it. 

Some questions about this for you all though:

How would you all feel if you bought a game for your phone and had to send an email to the creator to get something small fixed? 

Would you bother doing it? 

Would you prefer to just be able to get your money back?

Saturday, 14 May 2011

Windows Phone to take over? I'll get over it

So yea, just a quick note, this is another reason to make the game platform independent:;pop

No matter who wins, I still win!  I'm thinking I should do a simultaneous release though... Beta with Android at least.

Friday, 13 May 2011

Blogger went down... looks like they still have our posts

So, as pretty much all of you know (I got pretty much no traffic while blogger was down, so I assume most of my views are coming from my followers or followers of followers who find my blog from other peoples' blogs) blogger went down last night and seemingly deleted our posts.

While it doesn't have anything directly related to this project, it is interesting that they both still have the posts, AND those posts are still coming up in my feed.  I would have thought that the servers would just be backed up every so often and that's why we lost some posts, but now I'm curious about where the information comes from for the feeds.  I would have thought that they would be linked together with the actual posts (maybe drawing from only a couple of the fields from the same database table) but it looks like they have a completely separate database for it.

Or maybe they're using some sort of indexing method with blog post names / first sentences.

I find it interesting to think about.

Anyway, because I can still see those posts in my feed, I imagine that one long post I had about networking and multiplayer games should be back up soon.

Wednesday, 11 May 2011

Networking Techie Stuff

So I've been thinking about what's going to make this game special, and so far I've come up with pretty much the only thing being the multiplayer environment.  Many games can be played with 2 players, but it takes some special networking considerations to make sure that a 3+ player game works properly.

First, let's talk about what's actually happening when you play a multiplayer game like Call of Duty: Black Ops or something.  First, the little messages that pop up saying stuff like "connecting to servers" or something like that are one indication of how the game is running.  If you were playing Domination mode with 24 players, it would be hell to program an architecture in which each XBox connects to every other XBox and opens two connections (one for me to tell you what I'm doing, one for you to tell me what you're doing - it would be pretty bad if only one person could actually perform an action at a time) and have the machines maintain a consistent state for what the game looks like.  Trying to create a p2p game like that would result in so many synchronisation problems that the game wouldn't run well, be prone to cheating everywhere and would be a complete fail.

And so they took a server architecture route.  You only need to tell the server what you're doing, and the server tells you everything else that's going on with all of the other players.  2 connections instead of 48.  The server also acts as the master and so all synchronising that needs to be done, the server does.  It's just a better model for this type of network.

If you're confused about what I mean by "synchronisation" consider what actually happens between your controller and the game.  I'm sure you've seen your latency at some point at something like "42ms".  That's the delay for commands you issue to get to the server and back (a round-trip latency). 

Consider what happens if you're actually playing a game.  You move your character forward by pressing up on the left control stick.  Guess what?  Your character doesn't actually start moving forward until about 21ms later.  You strafe right using the right control stick.  Again, you don't actually start doing that until about 21ms later.  You stop moving? Doesn't happen for another 21ms. 

I'm sure you've been in laggy games before and you've experienced moments where you go "how could that guy even have seen me from there?" or "I totally stabbed that guy but he killed me first? This is bull".  The reason is that what you see on your screen doesn't always match up perfectly with what the server thinks is happening, but the server gets the last say.  If your lag is up at almost 1 second say, that's half a seconds worth of extra walking forward that you don't personally see on your screen, but the server thinks you're doing it.  Half a second is a pretty long time, especially if you're doing something like creeping up on some guys who you know are around a corner.  To them, it looks like you're a noob who walked out around a corner and didn't see them because that's what the server said you did.

So the question becomes, what actually needs to be sent between a server and a client, and what needs to be sent from the client to the server?  Most of the time, they just send changes.  This is to minimise the amount of information being sent.  For example, instead of having to tell the server everything about the state of every button and dongle on your controller, when you walk forward in COD, you just send the server a message to say, "I'm now pressing forward".  When you stop you say, "I'm now not pressing forward".  Think about what happens when you lag very badly in a game of COD.  If you're walking forward and you see the connection interrupted overlay, when you reconnect, you're 30 feet farther forward than what you last saw.  That's because you never sent the message "I'm now not pressing forward" and so the server just assumes you're still pressing forward.  Only changes are sent.

The server only sends you changes about where your enemies are, what new specials are in play etc.  It doesn't tell you how to render anything or where anything is - just the changes.  That's all that's important to the game.  Your own xbox does the rendering of what it receives after interpreting what was sent.  In fact, the servers probably have no idea what they're actually looking at - it's just sets of numbers and letters that it knows how to send route through different ports to all the players playing.

Now, I do know that it's a bit more complicated than that, but that's generally what's going on when you play a multiplayer game.  With 2 player games you really don't need to worry about most of that stuff because there's only 2 people - one of those clients can act as the temporary host and the chances of de-synchronisation is much lower.  The number of calculations needed is much lower. 

This is how I need to create my game - with servers to connect to and information only being sent between server and client about what changes are being made.  The really cool thing about this kind of design though, is that I can actually make the game transmit all of its information in plain text - that way you can have the game playable not only multiplayer, but it could be played between different cell phone operating systems.  The only thing a phone needs to consider is rendering, input and transmission of what changes there are to input.  With text, that means the server shouldn't care what kind of phone is being transmitted to and as long as the phone can interpret text, the program should be able to understand what the server is telling it to render.

Friday, 6 May 2011

Big Headed Candies

In my last post I asked for suggestions about what I should replace bombs with, and Eric Peterman suggested using water balloons.  I love this idea, and I've decided that the battle is going to be between big headed anthropomorphic candies with slowly expanding, and eventually popping, water balloons to melt eachothers' sugar based ingredients into nothing.

Thanks Eric!  You can check out his poker blog at:

Tuesday, 3 May 2011

Art style

In order to update you guys, I'll go into a bit of detail about the only thing I've decided this early on in the game's development - the art style.

I've been looking through a lot of art blogs for combinations of colours or styles that I really like, but it all comes down to a really bright, colourful and cartoony game.  With such small screens it becomes incredibly important to be able to easily distinguish what's on the screen, and the best way to do that will be to have things flashing with big bold colours.

Not to mention the bomberman franchise was really awesome until they decided to take a more serious twist (see Bomberman: Act Zero).  Even their newer games are pretty cool after they switched back to the classic cartoony style.

That leaves us with a few other questions:
  • What will the characters look like?
  • What will replace "bombs"?
  • What locations will the battles take place in?
  • Will the game be 3D?
I was thinking of having big headded characters because... well mostly because characters with big heads should make it easier to see which tile your character is taking up, because it looks cartoony and because you should be able to see your character's colour (the thing that identifies you best) clearly.

I was thinking that  a head shape similar to Katamari's might be useful - basically something similar to that.

For bombs, I have no idea what should replace them.  Willing to hear suggestions! Something large and that changes over time to show that it's "in play".

For locations, I'm thinking places that kids go for fun to keep up with the lively, happy theme.  Places like carnivals and movie theatres, though I was also thinking of taking some scenery that is reminiscent of some more popular videogames (maybe a map with a large ring in the centre for halo fans).

The game will not be in 3D.  There's no reason to change camera angles, it's harder on the phone and if you take a 3D isometric view, it would probably be a disadvantage the players who start on the far side of the board.

Sunday, 1 May 2011

Non-programming considerations

Alrighty then, update time.  So while I've been reading my books, I've been going through some stuff that I'm going to have to consider over the next while, to set up a list of things I'll be talking about in future posts.

1. Hardware considerations.  With all of the available screen sizes, input types and processing power available for android, it becomes more difficult to decide what should go where in an android app.  This may mean separating out views and controls from the game logic to allow more hardware.

2. Network concerns.  Depending on how much actual information needs to be passed around and the timing of how things would be passed, it may be necessary to host a server to store game information.  This is also in interesting problem when you consider the hardware that android is available on because people with more powerful android phones shouldn't have an advantage over weaker phones.

3. Art style.  I'm thinking of using a very bright and cartoony style for the graphics, but I'm open to suggestions.

4. Name.  Probably goes with the art style, but can't be named "bomberman" for sure.

5. Updates.  How should we design the game such that it will be able to apply updates easily and effectively?

All these coming up in detail in future posts!