js13kgames and Voxel Shooter

I knew I had to take part in js13kgames - A competition to write Javascript games less than 13KB when zipped. I used HTML5 canvas for the last two of the last three game projects I worked on and was increasingly identifying myself as a HTML5 game programmer. However a visit back to India and the work on Mario Ball had left very little time for me to actually work on my 13KB game.

At 13KB I had decided to have some sort of procedural generation for the elements of the game. I also wanted to explore the Web Audio API for the sound. However I was having a very hard time trying to come up with a concrete idea for the game. My very first idea was a weird fighting game where the player's form and powers were determined by a random combination of 3 elements - Rectangles, Circles and Bezier curves. The player and enemies basically looked like modern art pictures. I wasn't sure whether I was going too weird with this one. Some of the denizens of this unfinished game:

Then this entry came out on js13kgames - 13th Knight. It was a fully textured 3D world in WebGL in under 13KB! And it had awesome looking trees!! I wanted to make a WebGL game now. I always wanted to learn WebGL but hadn't looked closely into it it before. I had started looking at three.js for 7dfps but never got the time to do anything beyond a sphere moving on plane. This time around three.js wasn't going to be an option because no external libraries were allowed and three.js would not fit into 13KB (I later learnt somebody else had managed to get a subset of three.js working in their 13KB game - Mindless).

So not exactly knowing what I'm going to build I started with the WebGL lessons at http://learningwebgl.com/blog/?page_id=1217 for the basic template for a WebGL program. I played around with it till I was able to draw a flat colored cube with directional lighting. There were 5 days till the competition ended and I had to come up with something quick. Then it struck me - I will just redraw the cubes a lot of times to create a Voxel engine! (Being completely ignorant of the issues before starting a project is sometimes a good thing). I was missing a good flying game these days and I thought I will do a flying game where you shoot enemies on the ground - Voxel Shooter!!

I generated the terrain using some random combination of sin curves. I copied a small subset of the glMatrix library for the matrix operations. And I happily went about drawing cubes over and over again - One drawElements call per cube. I could reach up to 50 x 20 array of cubes before the rendering became too slow. I tried removing faces from the cubes that are hidden behind other cubes - A small increase in the frame rate but nothing great. I tried some cheating like increasing the size of each cube so that I can get away with a smaller number of cubes. Nope - the map was still too small. I banged my head trying to figure out a frustum culling method but it just involved too much Math to be figured out in a small amount of time. Also the far plane was going to be too near and field of view was going to be too narrow if I can display only 1000 cubes. I just had to figure out a way to improve performance first.

Then I came across this - Google I/O 2011 : WebGL Techniques and Performance. I had basically made all the mistakes mentioned in the talk. First and foremost I was switching too much context for every vertex - Even the uniforms that were common to all vertices like lighting and camera and projection matrices. I got a substantial boost when I fixed this issue but still not going to allow the 256 x 256 map size I was aiming for. The next thing was to reduce the number of GL draw calls by combining many cubes into one giant mesh. This one I had some problem getting my head around because I hadn't understood the concept of attributes properly. Then I saw how I could augment the vertex data by putting its world position as an attribute and I could draw the entire terrain with a single drawArrays call - And BAM! Now everything was running smoothly at 19fps (yeah. Much better than 7 fps) for an entire map of 256 x 256.

Everything from here on was mostly polishing. I worked a lot on the camera - I was using the LookAt matrix but couldn't figure out how to roll and I wanted the camera to roll on turning. After scourging the internet found a simple method to just pre-multiply the LookAt matrix with a roll matrix.  I didn't like the way you could lose your bearing if you looked right up. So I added some clouds(All clouds drawn with a single GL draw call), filled the surrounding areas with water and added a wrap around if you strayed too far from the island. I added some cubes to represent the enemies (all drawn with a single call). I spent quite a bit of time overlaying a 2D canvas to represent the minimap so that you would knew where your enemies were. I tried adding bullets to shoot down the enemies with the basic physics handled right in the shader but that wouldn't work - I just had to give up on it. (Did you wonder why it was called Voxel Shooter but there is no shooting? :) I spent the whole night before the competition deadline at 7AM adding these things and then before I realized it was time to submit!

I was very dejected that I didn't complete the game and I was too near to the deadline. You just flew around doing pretty much nothing. You couldn't even crash into anything. Staying awake for the whole night was a complete waste of my time. And then out of sheer desperation I thought I will just add a simple check for crashing into the terrain and that would be the game - Avoid crashing into anything. I was testing it and I kept going through the enemies. I thought I should add collision detection with the enemies as well. I added that and then I realized instead of treating crashing into enemies as a failure, that could be the whole point of the game!! I quickly added a score for picking up the red cube (no longer the enemy!) and increase the speed of the game every time you finished a batch of them. I submitted this new version and was smugly happy with my own crisis handling. Next time I should just give myself more time to avoid such things.

The next day playing through the other entries of the js13kgames and I liked many of them. It was interesting to see the methods they used to keep the size down. The most amazing thing I learnt about was jsfxr - A simple sound effects generator without having to store audio in huge audio files. I am definitely going to use this more in my upcoming projects and in the future versions of Voxel Shooter.

Some people seemed to like Voxel Shooter and it was really cool that indiegames.com picked it - http://indiegames.com/2012/09/browser_game_pick_voxel_shoote.html. Even Cheezbruger picked it for their Lunch leisure  - http://t.co/xO9drzmZ! Some were amazed it was done within 13KB but I should mention that my game was very simple - it just does the same thing a lot of times and I didn't spend any time trying to reduce the size.

The initial reaction from people has given me encouragement to keep working on the game and I think I will make it into a full fledged game in the future. Lots of ideas flying in my mind now - Sounds, bigger worlds, flying enemies, improved shading, shadows, water, lava, gamepad support, multiplayer, levels, missions... But now I will automatically think of one more thing - How small can I keep the code and assets?

And to end it all here is a video from my awesome friend Brian who scored 148 in Voxel Shooter! Can you beat that?!!

Mario Ball with Keita Takahashi and Kaho Abe!

Something very unexpected happened. The Babycastles folks were running a Summit at the Museum of Modern Art and Design(MAD) - It was centered around bringing Keita Takahashi's ideas to reality along with other things like game (not just videogames but also about things like games in physical spaces) related talks and indie music bands.

They wanted some help with the programming for one of their projects. For some inexplicable reason they thought of asking me and I jumped at the opportunity. I had always wanted to explore physical games/ alternate interfaces and wanted to do things similar to what Kaho Abe does. And now they told me I was actually going to work with her! Not to mention an opportunity to work with Keita Takahashi!!

I had an initial meeting with Keita and Kaho. The project, Mario Ball, was to build the original Mario brothers - but instead of using a normal controller the ideas was to control it using a wooden maze representing the level and Mario actually controlled by a ball. I think Keita's original drawing explains this the best.

Kaho had decided that we are going to use a magnetic ball for Mario and an array of  magnetic reed switches underneath the controller surface to detect where the ball is an move the on screen Mario accordingly (It was decided not to use computer vision because that was already being used for another game). This is where I was going to help them - Actually build the game that processes the controller input to move Mario around in the game. It was also decided to build the controller as a big box so that it would require two people to work with each other to actually control Mario! We also decided that we would make Mario go up side down when the ball is actually moved up and it stays up there - something like a change in direction of gravity. I was concerned with the resolution of the magnetic reeds and asked Kaho to also add an accelerometer so that we can try and interpolate Mario's position when the ball was actually between two magnetic sensors and we had to guess which direction Mario was actually moving. Throughout the meeting I was mostly just thinking - Yay!! I am talking with Keita!!

Kaho was going to build this insane setup with 90 magnetic reed switches connected to an Arduino through a set of multiplexers. The program running on the Arduino would detect the active magnetic switch and write that value to the serial port along with the 3 axis acceleration information from the accelerometer. So now we were ready to start building the controller and the game. The kicker - We had 6 days to build this whole thing!! (And not even 6 whole days. I had to go to my day job on all the days and work in the evenings. Kaho was handling the hardware for 2 other games)

I think my experience with working with multi-tiered systems in my day job (At this small startup) helped here. We decided what the format of the controller output is going to be like so that we can initially work separately and in parallel and then put the controller and the game together when they were ready. I decided to build the game with a ball and magnetic switches that are actually simulated (Similar to mocks/stubs that we use to test in isolation without external dependency) so that I could iron out some of the issues I would face even before the actual controller was ready. In hindsight this got me to 50% of the actual solution - but that was good enough given the time crunch. The things I totally got wrong in my simulation were the area which each magnetic switch covered and the maximum speed the ball would actually be able to roll in the real world.

So I went back and started to actually build the game. I didn't spend much time thinking about it but I decided to use Processing because of its inbuilt ability to use the serial port to interface with the controller. This was a good and a bad idea but at the end of the day was probably the right decision. The good part was that it all worked out and even though I developed the whole thing on the Mac it perfectly ran on the Windows machine where we finally put it - including the serial port part. The bad things included Processing not really having an easy way to rotate and blend images at the same time (Really? I expected better) and some bugs when part of the rendered image going offscreen. The IDE itself was horrible at times and I had to actually delete one file at a time to find syntax errors. At the end of the day the positives probably overrode the negatives. But the next time around I would think a bit harder before using Processing for a game.

I spent the first few days to actually get the assets of the original Mario brothers(Thanks Syed!) in and trying to mimic the looks of the original game as much as possible. I built the game in a way which is probably not recommended - I tried to get the graphics of the game done well before the actual logic/gameplay of the game. But I  found that doing this motivated me much more than just dummy boxes and circles. Looking back I think this also helped out because I would have never been able to put in the effort to get the graphics right in the crazy days that were going to follow. I also spent the initial time building the framework in Processing to read in the world layout and character animation from Tiled TMX files. This also helped me out later when Keita wanted me to add extra characters into the game and I was able to do it with relative ease. As usual I wrote custom collision detection code instead of trying to figure out how to use Box2d with Processing. In my defense I didn't have time to ramp up on anything more complicated than the simple graphics APIs and this was the first time I was using Processing.

We met halfway through the week - Both the hardware and software were lagging behind where they should have been at that point. Keita was amazing as always - He had built the frame for the controller and created an actual Mario Ball by pasting colored strips to create a Mario on the magnetic ball (Thanks Lauren for the photo!).

That night me and Kaho just worked through the whole night trying to finish as much as possible. We made really good progress but we still weren't ready to put things together. The whole time I wasn't stressing myself out and tried to stay as calm as possible. I also told myself that Babycastles always manages to pull off these things - So I had nothing to worry! (It was half true at the end :). So here is the picture of the amazing circuitry that Kaho put together that night. I think she called it a unicorn barf or something like that.

The next day we had to shift to the MAD and this is where things started going wrong. We weren't allowed to stay late the day before we had to set the whole thing up! So on the opening day(Friday) we just had a few hours to get the whole thing ready. Kaho was also getting very busy dividing her time between all the projects she had to get working. This was a very tense day and unfortunately we weren't able to get Mario Ball ready that night.

On Saturday we finally got the game and the controller talking with each other. It was a magical moment. I never thought we would ever get to this stage given the craziness that was the whole project :) It had few kinks including a bug in the Arduino code which made it print lots of useless values in between the actual useful ones. A few hours later and few critical bug fixes later we had something close to playable - There were some issues with Mario appearing to teleport when the ball moved too quickly - but the game was definitely playable. And so by Saturday afternoon Mario Ball was ready to go! We spent some time getting the actual hardware for it setup and the game was finally ready to be put up.

I haven't talked much about Keita and probably mention here just a bit. He is a person of few but precise words and I would like to keep this section the same way. He is an amazing combination of a nice guy and a person who pushes you to the limit. He wasn't there to just have fun - But actually do something great. Good enough was not good enough - perfection was the only end point. In the end I didn't do everything that he asked for - but the game definitely ended up much better than if we had just aimed for something good enough. The couple of things I took out of this whole experience was to aim high and always keep improving.

Even though we were almost a day late I was very happy to have Mario Ball running for more than half of the summit. I think most people had lots of fun playing the game. There were some who said it was too experimental - but I thought that was part of what we were trying to do. Kaho had done an amazing job with the hardware - It worked without anything breaking for most of the summit (It briefly broke down on Sunday evening - but it was just someone had yanked on the controller so hard that the USB cable connected to the Arduino had come off. The crazy wiring just kept working the whole while).

So here it is - A picture of couple of people playing Mario Ball in the jungle themed arcade section of the Summit (The jungle theme was an amazing achievement of its own. Somebody needs to write about that). This should give an idea of the size of the controller and how it would take two people to use it. There are so many details in the controller I can't capture here. Keita added the fur like exterior and window handles(which reminded Keita of his Grandmother's house?) on the side so that you can easily hold and play.

Here is a video of people playing it at the Summit. I am sort of happy that I was able to capture the experience of the two players actually co-ordinating with each other to play the game.

I have no good words to end this post. Maybe that this is just the beginning. We will keep improving. You will see a better Mario Ball in the future!!

Go away, norman at Babaycastles!

The nice people at Babycastles called us to setup "Go away, norman" as part of their closing party on Friday along with the winning games from the Parsons game jam. It was a pleasant surprise and I was totally kicked to show the game at Babycastles! (If you don't know what Babycastles parties are about here is an article from someone who can explain it much better - http://www.diedagain.com/a-laymans-take-on-babycastles)

We got one of the cabinets to setup our game and we hooked up my laptop to the monitor and one of the gamepad controller they had to my Mac. Made some last minute fixes to the code so that the game is centered on the screen and we were ready to go. Everything was looking ok when someone found a bug - if the mouse went off the screen on the right the game was essentially on a never ending loop and it could be easily reproduced. I had to go behind the cabinet and fix it in 'vi' to add  the extra check in the javascript. There is a charm with working with these physical things and hacked up code. Makes you feel more like Steve Jobs and Wozniack hacking on their first computer.

The party was a blast! There were performances by Ava Luna followed by the legendary Wu Tang clan. It was such a great feeling to see people walk up to our game and play it. The best part was when people actually got excited as they were almost caught by norman. We have some ways to go before it becomes a proper game - but it was nice to see people enjoy for what it is currently.

Thank You Babycastles.

go away, norman

Back from the dead. After two exciting years find myself in a different job and New York. A new start. Hopefully will not ignore my game creation itch this time.

It got rebooted thanks to the amazing folks at Babycastles and Parson school of design, who organized a game jam about a week ago.

Teamed up with the amazing geejay who handled everything from art to sound to level design as I floundered to finish the game code in 48 hours. I knew writing code from scratch in a game jam was bad idea - but I didn't have time to prepare on anything else. So just Javascript and HTML5 canvas it was. Spent a stupid amount of time on the collision detection. If I did it again I would probably just figure out some engine with basic collision detection before the game jam.

The theme of the game jam was any tweet from @Horse_ebooks and we picked "Solution to Cat behavior problems" and "It will catch up with you". So here it is our game - "go away, norman"

You can play it here.

We are continuing to work on it - Expect a more official release soon...

Game Project update

Been long since I updated this blog with any details. Work on my next game has been spotty over all, but it has picked up in the last few weeks. Hopefully I can maintain the momentum. I have been playing around with new ideas and been learning quite a bit in the process. I have also solidified broad ideas for the game. For now I can tell you it's going to be a narrative game with story telling - Something other casual games have shunned but has been my interests - And probably leaves an opening for something to be explored.

Here is an updated screenshot from the work in progress (With clues on its internal name). Good to see it has come some ways from the last one but clearly I could use artists. For the next next game maybe...

My next project

Been busy working on my next project. Just wanted to update with this post to see what people think about it.

Can anyone guess what the game is going to be about?

Please Save the Great Flea Circus!

After two weeks in development I am happy to announce the release of my first game - "The Great Flea Circus". You can play it in a few nice places that host Silverlight games.

http://gamejolt.com/online/games/action/the-great-flea-circus/592/
http://www.mashooo.com/SilverlightGames/The_Great_Flea_Circus.aspx

http://www.SilverlightClub.com/apps/PlayApp.aspx?AppId=114
http://silverarcade.com/games/vikerman/the-great-flea-circus/

What's with the name "The Great Flea Circus"? Well, the game is a clone of Circus Atari and hence the circus part. The flea part came because the characters I initially drew looked like fleas. Hence I made the theme a Flea circus instead of a regular circus!

The main purpose of this game was to test the feasibility of using Silverlight for game development - And I have concluded it is not only feasible it is absolutely the most productive way to develop a game given my .NET background.

Also after my previous post I have decided to switch to using Microsoft Expression Blend for the game development. Particularly I have been using the Behaviors feature in Silverlight to separate game logic(code) and game design(in Blend). For example in the Blend design window I just attach the behavior Paddle to the paddle in the designer and Jumper to the two jumpers.

An interesting thing happened where behaviors were really useful - When I showed the game to my wife (A great play tester and critic !) she asked me why there is ball in the middle of the screen which doesn't interact with the Jumpers. So I added the Bounce behavior(which the two black blocks on the sides have) to the ball and viola!, the Jumpers now bounce off the ball in the middle. It turned out to be a nice twist to the gameplay and so I left it in. Also check out the cheesy animation I put on the Ferris wheel in the background through Blend.

More on Silverlight, Blend and Behaviors in a later post. Now go and "Please Save the Great Flea Circus!! "

Why get into Indie game development? (or Why Not)

This is not the first question I asked myself when I thought of making games and I suspect it's the same with so many of you thinking of getting into it.

But I think it's an important question to ask early. Again I haven't done anything at this point and so I am not trying to give advice or answer any questions. Just putting down my thoughts here.

For me the "Why Not?" question is the easier one to list. It follows logic more. "Why?" is probably more emotional (This is turning out to be a recurring issue in my life - "Do I want to go back to India?"). And by putting them down it should be perfectly clear to anyone why you should *not* get into independent game development.

Why Not?
1. I already have a good paying job which takes a lot of my energy
2. The game market is saturated with too many games - high budget and independent
3. Because of 2) the money you can make in games is low and way less than what I currently make in my job
4. The chance of failure is lot more than success

Why?
1. Because I really want to make games (if not, just stop right here)
2. I am my own boss. I decide and control the outcome(at least I feel I do)
3. Satisfaction with work is high. Work is no longer a bad word (is that good for my personal life though?)
4. Applying creative ideas at levels unprecedented in my current job

At this point my friends might tell me - "You should join a start up". Some of them are in one and they seem to get 3), 4) and some of 2).

But I guess it all finally boils down to 1) - Why do you want to make games? This is where things cannot be put down on paper. At this point I am probably comparing myself to an artist who likes the art. But then there is this extra thorn in my subconcious - I am not even sure I am good at the art.

I am not sure of any of these things and it is this uncertainity which leads me to treat it like an adventure. And I could just stop it all one day and go back to my cozy life - Forget I even went on an adventure. Which is where I hope this writing will help me - Not to put down some memories but to remind myself that there is no turning back now...

Why this blog

I am setting up this blog so that I can chronicle and share out my experiences in trying to become an independent game developer.

Right here is step 1.

The other purpose of this blog is to share out information on specific technologies/ideas that I have been playing with in creating my games - Aggregation of information I found on the web or things about which I haven't found enough information on the web where I would like to fill the gaps in.

Also my hope is that this blog would be a place where I would announce progress and completion of my games and the lessons I learnt on the way.

And finally the name of my blog "indie-indian" - Is to probably just identify myself with the sub-minority group that I am in - The Indian independent game developer. Maybe there will be some posts on this, trying to reach out and connect with others in this group. Maybe if I become successful I can get more people into this group...