Tuesday, December 31, 2013

Reflection on 2013 and Happy New Year

It has been quiet on this blog for awhile but for good reason. I have been crazy busy working on projects and on RaptorGL. This is a quick summary of 2013.

In December of 2012 on twitter Christer aka @MCFunkyPants and I got into talking about how he pulled off making 12 games in 12 months. I told him I am fully committed to make it happen in 2013 and if he would keep me accountable to make sure I do it.... fast-forward and #1GAM happened. I'm very grateful for Christer to spearhead it because I could've never done what he did. It has been the single most influential event in my gamedev endeavor. I am going to continue in 2014 and I highly encourage everyone to do so as well. That's right, I don't want to stop. I've enjoyed writing different yet somewhat similar games with simple game mechanics. One thing I will do differently next year is to challenge my self to do more physics, tilemap and 3D games.

Over the summer I hired RaptorGL first employee :) She worked part time on social media, documentation and helping me stay on track. It was a blast and I was sad to see her go to college in September.  Image on the right is the proof of how hard we worked :)

It was a very productive 3months in the development of this awesome cross platform game library RaptorGL. She took care of the stuff I didn't want to deal with which gave me free time that I could pour more work into actual coding.
One big news is that I have developed an Editor for RaptorGL. This allowed me to fine tune the workflow and I am actually using it to develop RaptorGL it self AND the Editor it self. Which is kind of spooky and cool at the same time.
I believe this will be the killer feature by allowing devs to start making games with one download and build it one a click of the button! No more how to configure my directory, run shell scripts, which editor to choose. It's the 21st century after all, just download the editor and you have everything you need. An other big addition to RaptorGL is 3D with WebGL. It is not fully completed yet but I am very very close.

I have been blessed with awesome and amazing contract work which allowed me to focus not just work but also on family and friends! I am sure many of us can attest that the biggest drawback of working technology is that there is always something new to try, an other project to start. This takes away time from friends and family and time to relax and recharge. So after me and my wife both growing up tent camping we took our boys to the mountains and the lake and went camping. It was the best thing ever!!! There is just nothing more relaxing than spending a day at the beach of this gorgeous lake
then sitting at the campfire at night and staring at the stars. Food at camping is so so good and different. This year there were a ton of bees everywhere I got stung about 5 times over the summer, thank goodness I'm not allergic to bee stings.  Looking at my commit history it is super easy to spot the weekends when we were out. It made me so much more productive and my days were happier in general. I highly recommend all of you to try to get out or get least get away from your computer and social media at least once a month for a couple of days. You won't regret it! We had so much fun and grow so much closer that decided we need to extend the time we can stay outdoors and away from tech.
Since tent camping is limited to about 3months and even then you are at the mercy of a thunderstorm we went with the second best thing.... We bought a tent camper :) Look at how cute and fun it looks! It's off the ground so even if it rains it will be fine and also provides shelter from bugs especially from bees as we are trying to eat. Whats really great about it is how small it collapses and it's also very light so pulling it behind my wife's small suv is a piece of cake. Great purchase and something that we already used a lot even though we bought it close to the end of the season. I can only imagine how much we will use it next year. Now we can go to camping from early spring to late fall thanks to the heater in it.

It has been a very rewarding year for me/us not just professionally but personally. I am not planning on doing anything different next year! My only plan is to stick with what I got going on this year and continue doing in 2014 I even wrote code to accomplish it lol.

Happy New Year! 
Here I am hoping that all your gamedev and personal plans will come true in 2014.  


Friday, August 9, 2013

#7DFPS Started!! I'm back for the second time

Well the second #7DFPS is starting today... SO EXCITED!!! I got a lot of ideas to implement and add to my game I wrote for the first one last year. You can read about it here and watch a gameplay video as well.

First order of business is to convert the code from JS to C# and fix that bug in the grenade generator.
Planning to add enemies and obstacles to get around like trees and bunkers. I will keep it simple but I have to admit that I have been waiting for the opportunity to work on it and make it into a finished game.

Many people asked if I will use RaptorGL for it. Answer is as you guessed is no. Reason is simply that RaptorGL 3D is still in a very early stages and I want to finish this game instead of working on core lib.
This will give me a base game to convert it to RaptorGL. Thats on its own excites me a lot since I will have a working game to convert and see how RaptorGL 3D measures up and what shortcomings it have so I can fix it.

If you haven't join #7DFPS Go Do It Now!! It's a fantastic gamejam with a ton of talented and helpful devs. Make sure you follow them on twitter @7DFPS and follow the hashtag #7DFPS.

As always don't forget that the game you are writing could be one of your OneGameAMonth game for August :))

Enjoy your week working on your game and make sure you come and say hi on twitter @LZAntal


Watch the fantastic keynote and get inspired!

Thursday, May 2, 2013

All the #LD26 Games on One Mosaic

All the #LD26 games on one mosaic for your desktop wallpaper. Nothing looks better than seeing all these awesome games in one image. There are also 2 interactive webpages with hover over for name and larger thumbnail and you can click on it to go and play it. The large page is HUGE! so be patient as it loads.

Credit where credit due: I used @ExciteMike scripts to generate them with slight modification to make it work with #LD26. Thanks Mike for being awesome and sharing your code!!!

Webpage for interactive browsing:
Wallpapers in various sizes:
Have fun looking for your game. It took me about 8minutes to find mine. Which BTW if you haven't played yet go give it a try Stick Man Run ;)
Ludum Dare is AWESOME! and i'm glad to be a part of it.

If you made a game for #LD26 why don't you head over to OneGameAMonth and submit it there and earn XP :) It is a fantastic game challenge you can read more about it in this post.

Monday, April 22, 2013

My main character and game play for LD48 game if it's theme potato

Introducing Steakernator, Revenge of the potato

Why do they always say "Steak" and potato?! Why would the steak be any more important than the potato?! Mr. Potato has had enough! Armed with his Bacon bit pistol, Onion grenades and Sour cream blaster he is on a mission to prove that Potato is superior. But he has his work cut out for him, he has to battle a hoard of T-Bones and the Zombie-like Bloody Rare steaks.

Friday, January 25, 2013

Building a Game Library: steps, design decisions, sacrifices. Part 2

This is the second and final part of the series. If you missed the first part you should read it here.

Here I continue to define the phases I went through while re-writing my game library RaptorGL and the tools I added to ease the development and deploy/build your RaptorGL game.

Phase 5: Give some TLC to Sprite. Sprite was pretty dumb in previous implementation. It required the dev to add pretty much any feature to it besides drawing and moving. I realized that this not a very nice thing so Sprite can now rotate itself based on anchor points between 0-1, the default being 0.5 which is the center. It can also scale now too using the same anchor points used for rotating. I may separate them in future versions. Also the new Sprite.moveBy() and Sprite.moveTo() does not create a new object every time.  Instead it stores the values in a private variable of the Sprite object.

Phase 6: Throw away label and write new one. Label was well, not my proudest piece of code lol. So when it came to a re-write I just deleted the module all together, being very careful not even seeing a line of code in there. So the new label is a totally new implementation which I'm very happy with right now. I decided to stay away from inheritance hell, so I did not inherit from Sprite even though they share many common features. This turned out to be an awesome decision. Label has scale, rotate, align left, right, center, and of course it can move.

Phase 7: Simplify assets loading. Now each class handles the loading of the proper assets and notifies the object when the loading is done. This includes Textures, SpriteSheets, Sounds, and soon custom Fonts. When RaptorGL boots up it asks all these classes to start loading their resources. After they are done RaptorGL removes the loading screen and calls the game's main function.

Phase 8: Write a simple module loading system. This one was very fun to work on. Implementation is super simple and it also allows the RaptorGL build tool to combine all your modules into one JS file and even compress it for you. The way I got around adding all those extra functions, and with it all the extra function calls, was to introduce the includes.js file into the project. This file gets run before your main.js file and imports all the modules that are defined in there. Syntax is very simple: you write rgl.include('gam-module.js'); That's all, now your module files are not polluted with all the require and import statements and it also enforces you to think about your code layout. I'm planning on adding module folder support as well.

Phase 9: Development Server. I noticed right away the it can be a pain to run the game using the "file:///" url in the browser, especially when using webworkers. Also I want to test on my iPad and iPhone so I needed a lan IP for that. It helps debugging to see which resources are getting requested etc.. So I opened up my Python editor and with only about 70 lines of code (which includes comments) I got an awesome small dev server. It can accept 3 arguments for IP, Port, Directory.  Now one can fire it up from the command line and test your game from anywhere on your network.
I even found another cool use of the server. Since you can define any directory to be the root directory you can start the server with your home directory and others can read and download files from your computer. Pretty snazzy ;)

Phase 10: Build tools. Now if you've done any development you know that there is a difference between your dev and build versions. Since RaptorGL implements the module import in such a straight forward way it was a natural choice to provide a build tool to get rid of those rgl.include(); calls and just combine the files into the main.js file in the same order as the includes. So just like with the Server I opened up my Python editor and with 174 lines of code I wrote an awesome build tool. I say Awesome because it not just combines your JS files, it also creates a build directory in your project and copies all other assets and RaptorGL itself. But wait! There is "One More Thing..." :)
RaptorGL build tool also can compress your main game file using the Google Closure Compiler
It supports all three compressions: Whitespace, Simple, and Advance. It creates a new file with the .min extension so your packaged JS file will not be overwritten.

Phase 11: Sacrifice platform. This one was Hard.  I realized that many parts of the library were being updated, adjusted, and expanded just to support Mobile Browsers... But Why?! RaptorGL already has hosts for desktops, why not just create hosts for iOS, Android, and Windows 8 Phone as well? Since I'm much more familiar with iOS I decided to tackle it first. It only took me about 2 hours to get a host up and running. RaptorGL was running an average 50FPS with over 800 sprites. Thats perfect! I can live with that, since I know there is a lot of room for optimization. So I dropped the Mobile Browser support... for now. But since I already have the orientation support with dynamic viewport/scene/layer resize and full touch support including multi touch you can bet that "It Will Be Back" :) 

Conclusion: Well, there you have it. Looking at all that, now you can see writing a game library is not a walk in the park, but it's so worth it! Very challenging and rewarding at the same time.
Stay tuned to read all about the native hosts for RaptorGL, which even includes the same dev tools you are used to in Safari and Chrome.

If you have any questions leave a comment or ping me on twitter @LZAntal

Thursday, January 24, 2013

Building a Game Library: steps, design decisions, sacrifices. Part 1

Re-writing RaptorGL was a real eye opening experience. Even though everything went great at the beginning, somewhere in the back of my mind I knew it was too good to be true. Boy was I right.
But thats the end of the post so lets start at the beginning.

After playing around with WebGL back in late 2012 and reading this awesome book I knew that if I could use WebGL as a drawing backend to RaptorGL it would be a huge performance boost. I actually have been following one of the author's blog about WebGL @Tojiro. His demos are amazing. It's inspiring to see how far we can push the current state of WebGL. So I went ahead and wrote a very simple "click to destroy" style game which btw will be my January game for OneGameAMonth :))
Once it was working I realized that I needed a mouse position converter from World coordinates to Window coordinates. It was much simpler than I thought so now I could properly detect where the mouse was down.

Next came the Layer class... it was a total failure. But a good one! It showed me that the current implementation of RaptorGL using the Canvas didn't have a nice concise API that I could follow. Also, if the user's browser does not support WebGL I need to fall back to canvas.

There came the idea of a re-write with a properly defined internal API so I can hook WebGL in when it's available, and have the engine auto switch the TouchMgr and Layer classes to use the proper implementation... be it Canvas or WebGL.

But before I can run I need to learn to walk. 
It was time to seriously commit to RaptorGL and bring it up from "Pet Project" to "Project". This also meant that I had to downgrade my current obsession with MOAI and my TrexGL library to "Pet Project" but it is a sacrifice well worth making as you'll find out in an other post. Hint: RaptorGL now has it's very own native host so it runs as a standalone game without a browser for Win, Mac, Linux :))

With all that in place I embarked on the journey to re-write the Canvas implementation of RaptorGL, keeping in mind the implementation has to be able to work with WebGL... my main goal.

I structured the re-write into phases. So far there are 11, described below. I'm sure there will be more as I continue to use it for my games and share it with beta testers.

Phase 1: Remove 3rd party library dependency. Write everything in pure javascript. This was the best decision ever. Removing jQuery alone brought the size down by almost 100KB. Then came the really overused and over-recommended RequireJS library. Running my simple prototype was a breath of fresh air. Now I had full power and control over every aspect of the code. Love it!

Phase 2: Clean up the classes, class implementation. I used @Jeresig implementation of JavaScript inheritance. This design helps keep the overhead low and at the same time allows proper inheritance while still keeping the code simple. What I like most about this implementation is that it allows calling the super/parent classes method when you overwrite it in your own implementation. This will help devs create their own version of Sprite, Layer etc.. but still have the option to call the super/parent method from within their method.

Phase 3: Combine mouse and touch controls. Since I already had this done in TrexGL it was a matter of converting my Lua implementation to JavaScript... yeah right! See the game runs in the browser so everything in there is laid out using the DOM. So guess what, there are a lot of browser differences I needed to take into consideration, oh and did I tell you about resizing the browser window changes all the off sets? I decided to use a callback system instead of keeping the positions in globally accessible variables. I got the inspiration from Futile an awesome unity 2D framework written by @MattRix. If I ever decide to do 2D this is the tool I'll use. Although it works great now I can actually foresee adding the global variable option as well. Maybe my prototypes are just too simple and the overhead of a loop and function call bothers me. Time will tell.

Phase 4: Fix Scene and Layer implementation. These two were arguing all the time in the previous implementations. Scene was trying to be like Layer and Layer was trying to be like Scene. So it was time to put an end to this. Now Scene behaves nice and manages the drawing and updating of the Layers. Scene is also the main entry point in RaptorGL to start a game and RaptorGL uses it to dispatch draw and update calls. Layers can care less now about their surroundings and obey the Scene. Layer also holds all the Sprites and Labels. Layer can ask the Scene to call it every frame to update with the deltatime.

Thats all for the first post. Stay tuned for the second/final post of this series where you can read the other 6 Phases, two of which are tools to ease development and deploy/build your RaptorGL game.
Next post comes out this Saturday,

Part 2 available here, read on to learn about the tools and the other 6 Phases. :)

If you have any questions leave a comment or ping me on twitter @LZAntal

Monday, January 7, 2013

Found an HTML5 canvas shortcoming: Rotation

As I was working on the RaptorGL.com re-write I found the first noticeable shortcoming of the html5 canvas: rotation

To rotate a sprite on the canvas first we have to call context.save() then translate to the center point of the sprite or any other anchor point. After all this finally we can rotate the entire canvas... in radians. Not a big deal. We can easily convert angles into radians, but here comes the tricky part... what do you think the 0,0 (top,left) position of the canvas is now? If you said it's the center of the sprite then you're right. It took me a few tries to realize that it got moved around. Well now we have two options: call another context.translate or just use the context.drawImage and specify it there to save a function call. I chose the latter, and finally I can call context.restore(). As you can see that is a lot of extra function calls and steps just to rotate one sprite. 

Performance gets hit around 1000 sprites all rotating around at every frame. In the old implementation of RatorGL.com I had every sprite on its very own canvas and that canvas was drawn to the layer canvas. It sounds like a lot of work but it was all done in the background and only costs a little extra time at startup. That design could work in this case to eliminate many of the function calls if an object rotates once every second or so. I can see some optimizations there like group draw calls together for all the sprites that have the same rotation etc...

Since I'm set on entering into the Mozilla Game On Challenge with RaptorGL and also use it to write many of the games for the awesome One Game A Month Challenge I'm ok with FPS to drop to around 56 when rotating over 1000 sprites every frame
It’s not time for optimization yet :)

Thursday, January 3, 2013

One Game A Month Has Begun

As you all probably already know OneGameAMonth is a game developer challenge to build 1 game a month every month in 2013.
It started out as a dozen or so tweets back and forth with Christer aka @McFunkyPants and he took initiative (for which I'm utterly grateful) and started 1GAM challenge. Since then over 2800 gamedevs joined in. Amazing!
If you haven't already, go and watch the keynote on OneGameAMonth.com It will give you a clear picture on what 1GAM is and what it's not. Also read his blog post on how he made 12 games in 2012.


There aren't any! It is all about “You”, this challenge is here to help you start, boost or re-ignite your game developer career. As you heard in the keynote, if at the end of all this it just helps a few developers it's a WIN!


This challenge can help you build a nice portfolio. Think about it, by the end of 2013 you'll have 12 games to showcase. Not just that but you'll gain huge experience in the process. It will also show great on your resume that you committed to a year long challenge and you followed through, shows huge commitment.

How to get started

Come and signup at OneGameAMonth.com website using your twitter account. Complete your profile. Join us on Reddit.com/r/OneGameAMonth and on IRC at freenode #1GAM.
Follow @OneGameAMonth, @McFunkyPants, and @LZAntal on twitter. I also created and am going to make more as people signup Twitter lists List1, List2, List3, List4. Unfortunately I had to split them into separate lists because of twitter's 500 member limit per list.

Start writing the games you always wanted! Anytime you get stuck just come and ask questions. 1GAM is a very welcoming and helping community.

What's coming

Working on a resource list for new game developers but I'm sure there will be plenty of good stuff for seasoned devs as well. It will include everything from tutorials on gamedev, level design, AI, math for games, free game art, game art websites, game art howtos.
Wrote a short blog post coming in a couple of days to help you write your first game, if I have time I'll implement it using RaptorGL.com

I'm also thinking of live streaming some game dev using RaptorGL.com and maybe MOAI if there is any interest for it. All my games will be very simple so even new comers should be able to follow along. Tweet me @LZAntal if its something that interests you.

Hope you join in the fun, I look forward to playing your games! :))