Featured Entries

Our community blogs

  1. As a professional web developer, I often get asked what’s needed to get started with web development or I’ll find questions relating to web development on the forums.  But, I find that it is often difficult to answer succinctly, because a “Hello, World!” web server involves so many different, yet vital pieces.  Perhaps I’ll detail them out in a series of articles.  Until then, I’ve taken some time to summarize the topics involved in developing a web application:

    • Systems administration. How processes work and communicate, how to add users and groups, how to manage file permissions and/or ACLs, how to set up logging, backups, and automated tasks, how to effectively use a terminal to navigate an operating system, how to setup and configure dependencies and 3rd party software. (Bonus points for having Docker or Vagrant do this for you.) Typically Linux–based systems are used, but does not necessarily exclude Microsoft. Additionally:  How to spin up a virtual machine, and manage servers over SSH or RDP.

    • HTTP and web servers. Web servers are the glue between the frontend and the backend, and HTTP is the basis of the communication between them:  How web servers work, how to configure them to serve both static and dynamic content, and how to leverage HTTP headers and HTTP response codes appropriately.  Web servers:  apache2, nginx, Microsoft IIS.

    • Backend. This is the actual application or “business logic solution”: How to write a program or script that processes requests, performs work, and prepares proper HTTP responses. How to leverage web frameworks to assist in this process.  A backend can be a strict data API to be consumed by one or multiple frontends (web, mobile, console), or a traditional multi–page application (simpler). Languages: Perl, PHP, Python, Ruby, Javascript, and even C/C++. Web frameworks: Laravel, Django, Ruby on Rails, nodejs, ASP.NET MVC, and many more.  Also helpful to know:  JSON, REST, SOAP.

    • Frontend. This is the user–facing piece of the backend:  How HTML works to lay out a page, how CSS works to assist in page layout and theme, how to leverage Javascript to breathe life into the frontend, and how to asynchronously interact with a backend.  Languages: HTML5, Javascript, Typescript, CSS, SASS, SCSS.  Also helpful: JSON, XML, XPath.

    • Browsers: How to use the developer tools in any browser to tweak styles, debug javascript, and debug HTTP requests made by the browser and HTTP responses made by the web server or the backend.

    • Databases. Relational databases are array–of–structures on steroids: How to setup a (relational/document) database and schema, setup database users and their permissions, how to write queries, and how to write database migrations.  Flat files and NoSQL can be okay, too.

    • Version control. Very important in any software project: How to use a version control system, how to write meaningful commits, how to resolve merges, how to submit merge requests, and how to manage branches.

    • Devops: How to configure and build the backend project and/or the frontend project. How to automate builds, run tests, report problems.

    (Not pictured here:  Websockets.)

    With these in mind, read What happens when you type into your browser and press enter for an example of how a sample request is made.

    Hopefully, this has been helpful to game developers looking to build a real–time multiplayer web game or even a high score tracking server.

    Thanks for reading, see you around!

  2. In this daily blog (and video)-series I take a first impressions look at the best mobile games that I come by. Be sure to share your favorite mobile game with the rest of us in the comments below!

    FootRock 2 is either horrible or actually kinda genius. Or maybe the game is actually both. Think Goat Simulator crazy. 

    The game has you run from one end to the other of an American Football field filled with giant wheels, enormous playing cards, dangerous circular saw blades and other obstacles. Your goal is to navigate your way through the map, while shooting everything that stands in your way with an American football that occasionally will turn into a teleport ball or bazooka ball. 

    Yes, I know, straight out crazy. And the monetization has you sit through skippable video ads (although very rarely), but I still couldn't help but laugh out loud as I played this game.   

    My thoughts on FootRock 2:

    Google Play:
    iOS: Not yet released

    Subscribe on YouTube for more commentaries:
    Or join me on Facebook:
    Or Instagram:
    Or Twitter:

  3. The 3D modelling of the colored womans' face was completed last week.

    Of course she still needs hair and ears, but the main work is done. Now we can nail the head to her body in order to finalize the entire modelling of this characters' body.

    After this we will colorize her body in sparkling mixed colors.

    At the end, we will animate her movements, so that she is able to dance in our next video.

    It is planned to make her look sexy and creepy at the same time, as she is going to seduce the main-character of the game, Charly Clearwater, only to harm him later on.

    Let's do this.







  4. Already 5 days since the end of the contest. Here is my post mortem. I liked my week in general. I improved my knowledge on monogame while improving my small personal game engine.

    Things that have been weel
    - The creation of the story was very good. For those who wonder, there are 8 levels of planned in my game. My initial goal was to finish the tutorial and level 1.
    - Finding music has been a breeze. I had already discovered the artist on Newsground in the past.
    - The programming in general has been well. I did not have any major problems.

    Things that have been bad
    - I did not have time to find all the SFXs I wanted.
    - I've lost a lot of time trying to find a good futuristic tileset and that's probably why I could not create Level 1.

    To conclude, a big thank you to slicer4ever for organizing this competition. Also, another big thank you, to those who tested my game and who gave me their comments. I will use it to continue my game. I give myself some days of rest but it's certain that I will work on it again. Those who want to follow me will be able to do it here on my gamedev blog or via twitter:

    See ya

  5. If you haven’t peeked into the Corona Marketplace recently, it now offers dozens of plugins and assets, from art packs to audio tracks to useful utility plugins. Periodically, we will highlight a few exciting products which can help you develop your dream app using Corona.

    Builder Game Audio

    2017-08-07-15-14-39-ESM_Builder_Game_-_FBuilder Game includes 625+ fun, cartoon adventure sound effects that your audience/users will love and recognize. This pack is complete with bubbly items and collects, cute UI effects, cartoon creatures, doors opening, closing sounds in many styles like treasure chests, apothecary cabinets, wooden doors, and so much more!


    2017-08-02_09-12-41_-_fortumo-300x170.jpThe Fortumo plugin enables developers to charge for premium features and sell virtual credits inside their Android applications. Fortumo supports one-click mobile payments in 98+ countries.

    Sci-Fi Sounds and Weapons

    2017-08-07-15-47-39-sci-fi_1920x1080-300Sci-Fi Sounds and Weapons contains 287 sci-fi sound effects, including ambiences, general sounds, and weapons. Also contains an additional 645 bonus sound effects covering guns, 8-bit sci-fi, and general sounds.

    View the full article

  6. It's been five days since the end of the competition and I've thought about how things went and what kind of mistakes I made. So I want to talk about those things for a minute.

    Let's start with the mistakes and bugs first.

    During the introduction sequence of the game a text box pops up which eventually tells the player that the controls are the arrow keys and the X, C and V keys. Problem is, to get to that text box the player would've needed to press either the V or the C button. This is just a little oversight caused by me adding this text pretty late into the game when other things were on my mind.

    Also some players didn't realize that they had to go to the northern area first. Although there is a mushroom before the cliffs area that tells you that you need to go north first I originally planned for this path to be blocked at first. That way the player couldn't enter that area under-prepared. Unfortunately I didn't have enough time to implement such a thing.

    Another thing I noticed is that the random number generator can really screw the player over. During the UFO fight the UFO is supposed to resurrect the other aliens so that the player can create shockwaves again to damage the UFO. However sometimes this resurrection wouldn't occur for a long time, causing the player to burn through their supply of food items while unable to do any damage. The stupid thing is, I did write a RNG a while ago to deal with this problem. I just plainly forgot about it.

    Lastly there was a small graphical glitch on the Intel HD 4600. Apparently it doesn't support a 32 bits depth buffer so some trees appeared in the wrong order.

    And on to the things that went well.

    I started off with a pixel-art pack that ended up saving me a lot of time. Although I did ended up needing to draw some extra tiles it definitely helped.

    Also the original art I made, especially the sprites in the battle, did end up looking pretty okay. Although I will admit that that for the last two enemies, the cube and the recon droid, I intentionally choose easy shapes so I could get them done quickly. It was also necessary at that point because I made them on the last day.

    Using Python generators for animations proved to greatly simplify my code. Especially regarding the battle code, where generators are used for pretty much everything that happens over time: the narration, damage flash, text box shaking, fading in/out, just waiting, etc. Although it's hard to say for certain I think that writing code in this way prevented lots of bugs and allowed me to quickly write sequential animations in a single function that would otherwise need a whole lot of state-management.

    Lastly I'm glad that I didn't run into any major problems with my engine snowy. The only things I added where some convenience functions to existing classes. So no major technical problems like needing to implement a minimal sound mixer like I needed to do two years ago. Also investing some time to be able to load Tiled maps proved to be worth it. Tiled has greatly improved in the last couple of versions, especially the ability to define your own types is an important one for most games.

    Well I think that's about it. If you have any questions let me know in the comments.

  7. Leveraging social media doesn’t mean reinventing the wheel, instead, it’s yet a powerful tool in making the businesses profitable with improved leads and conversion. The sales person is often found scrolling the social media platforms and stalking the LinkedIn groups to achieve the ultimate goal that’s getting the product or services to the right audience.

    Social channels open up the myriad of the options, aids in increasing customer outreach and contributes to the organization’s growth with improved sales.


    According to a research, “Weaving social media DNA into the sales process increases the sales outcome by 23% as opposed to traditional sales.”

    It implies mastering social creates great opportunities on which businesses can capitalize, and grow by leaps and bounds. Let’s shed some light on a few reasons that illustrate why social media has become the next big thing for sales:

    1)      Find your target audience

    Social media is the best place where the people of different demographics, region, and background can be easily identified. The prospect intelligence aids in profiling, which eases targeting the audience.

    Sales representatives can not just find out the customer base, while they can also garner more information about them, which gives a leg up in bringing quality leads.

    2)      Target them like never before

    Billions of users are using various social platforms, and there finding the right audience is a hard nut to crack for the salespeople. With the advancement of the technology, the targeting options for social media have also evolved.

    For instance: Facebook allows the sales rep to segment the target audience based on geography, gender, age, location, and interest so that the prospects to target get zero down to a few hundred. The paid advertising is also run to gain potential leads.

    3)      Nurture the relationship with them

    The prospects are easily accessible on social channels, which offers a golden opportunity for the sales reps by opening a line of communication between them and prospects. The interaction with the audience is an ideal tool that not only creates a relationship with the customers, while strengthening the bond with them.

    The interaction can be held on any topic of their interest or current issues. Additionally, feedback from the customer and answering the existing customers’ questions about their offerings make the relationship better.

    Don’t consider social to just reach the audience, but leverage it to engage the audience.

    4)      Increase your reach with real-time marketing

    When you reached the right audience and crafted a strong bond with them, it’s necessary to keep up with the audience and changing trends.

    With social media, the prospects can be approached instantly, and when the relevant post is shared in a few minutes of the latest happening, the brand gains the public recognition. The real-time marketing increases the brand awareness which in turn boosts sales.

    5)      Uplift the lead generation

    The posts shared on social platforms become a medium to interact with the existing and new prospects. The reaction of the prospects not only helps salespeople in building a following and enhancing access to the new customers, while increase website visit, click through rates and pretty more.

    The reaction of the audience upsurge the traffic to the website and consequently social media becomes a lead generating machine.  

    6)      Bring more leads down the sales funnel

    The lead conversion is the ultimate goal of every sales rep where social media help them a ton. The social channels humanize the brand by interacting with the audience the way they like. The humanization builds the credibility and improves the trust in the brand, which in turn fuel up the conversion rate.

    The studies have shown that lead conversion ratio through social media marketing is comparatively higher than outbound marketing.

    Besides, social media provides great customer insights which make leads qualification easier and the critical information about potential leads enable the sales rep to craft their sales pitch accordingly that accelerates the conversion.


    The Social Media Examiner study states that more than half of marketers who've been using social media have observed improvement in the sales.

    It signals social media is a key to grow the sales. It is the best platform to maximize the access to the potential customers and encourage them to buy services or products. With Social Media Mobile App development or social media page creation, the sales representatives can better drive the customers to the website and generate sales with increased conversions.

    Getting social is a next-Gen trend, which must be put into the sales equation.

  8. In just 7 weeks till steam version has to be completed. Tomorow we will be implementing last enemy (gif). This skull/zombie/spider will be the easiest enemy to defeat (no attack ability). But I guess it is the crepiest one :D


    Here are other enemies from single player mode:


    Bouncy Bob steam page:


  9. Building Block Heroes - Freshleaf Forest

    Following on from last week's feature on Jollyville, I'm going to talk about the second area in the game, Freshleaf Forest.


    Freshleaf Forest is a dense and dark place with colourful flora and gigantic trees that cover the entire area in shade.



    I generally try to introduce some new gameplay feature with each new area, and in Freshleaf Forest players will encounter Leaf blocks. The player characters will fall straight through leaf blocks, but coloured blocks will not. It thus becomes necessary to place blocks on top of the Leaf blocks in order to traverse them.


    Naturally, this lends itself well to levels with bottomless pits in them. There is no damage, nor are there lives, in this game, so falling through the ground only results in being sent back to the start of the level. Nevertheless, it can set the player back a bit if they fall through when near the end of a level. Tread carefully!


    The enemies in Freshleaf Forest are a bit more of an obstacle than those in Jollyville, but aren't too tough to deal with. The first moves back and forth like the enemies in Jollyville, but takes up two spaces rather than one. The second enemy in Freshleaf Forest moves vertically in the air, providing a different kind of obstacle for the player.



    At the end of Freshleaf Forest, players encounter the second boss in the game, a giant mechanical spider that shoots legs out in six different directions while its front legs dangle uselessly in front of it. It's your job to work your way up to his glowing weak point even as he flings his long limbs at you.


    Having a friend to fight alongside you here is useful, as you will be able to attack from two sides.



    Freshleaf Forest was inspired by similar jungle scenes in Rayman and The Lion King. I noticed that they made use of crazy and unrealistic colours for plants in these scenes, and wanted to incorporate the same variety in colour so as to break up the monotony of having green everywhere.


    Nevertheless, Freshleaf Forest does consist primarily of green. It was my job as the artist, therefore, to ensure that I used different shades of green to prevent everything from looking the same. I mentioned in a previous article that warm tones work well with highlights, and cool tones work with shadow.

    The concept is demonstrated well here. Notice that foreground elements and leaves near the top of the screen - thus near the sun/primary light source - tend to consist of warmer and yellower shades of green, while foliage further in the background or closer to the ground tend to make use of more bluish hues of green.


    Judging from the thumbnail of the background, it is plain to see that green and turquoise are the colours that really stand out. This deliberate association with green helps set Freshleaf Forest apart from the other areas in the game and give it its own "character".

    It is also important to note that, despite the overwhelming focus on green, it doesn't feel too monotonous or repetitive due to the mixture of different hues of green, as well as the smattering of colourful foliage along the ground.


    For the music, I wanted to capture a jungle vibe, so I began by composing a percussion track consisting of conga drums and maracas. Once I had that nailed down I threw in some extra "percussion" using a bass to add in a "creepy-crawly" feel. From that point, coming up with a main melody to match the beat was relatively easy. Like the percussion, I made use of "ethnic" sounding instruments to make the track feel more exotic.

    At the end, there was still something missing. It was my goal to give the players the feeling of traversing through a dark jungle while still encapsulating the cartoony look of the game. To emphasize the silliness, I added a string section to the percussion track, to include some of the same "bounciness" that Jollyville's music possessed.

    Every area introduces its own challenges, and things will only get more challenging from Freshleaf Forest onward. I hope this was an interesting read!

  10. Hi everyone! :)


    I hope you’re all doing great!


    Today, we’re going to talk to you about what we’ve been doing on “Project SpaceVille” in the last couple of weeks. This last one in particular, we focused on fixing the most critical bugs in the prototype. As you may already know, that was the last week before submitting the final demo for Lisboa Games Week. So, that was quite stressing! (laughs)

    By the way, here’s a screenshot of that said demo. Enjoy!





    Bugs. Bugs everywhere!

    Something we didn’t tell you before (ups!) was that you were actually able to dig holes inside houses... But, we fixed that and you are no longer able to plant trees in your living room. There goes the environment, I guess. (laughs) Speaking of that, another bug that also occurred inside the house happened when you tried to place an item from the inventory in the room. Suddenly, it would start to be multiplied insanely (laughs), but that’s fixed as well.


    While fixing these “small” issues, we were breaking other things related to the player's actions. For example, the player couldn’t catch butterflies anymore, trees wouldn’t fall no matter how hard you struck it with the axe! And after fixing these action related bugs, the achievements stopped working as well! What a mess, I know... (laughs)


    Bugs aside, we’ve finally changed the player’s 3D model and animations to the “final” ones. But even there we found some issues. The new model’s rotation and player input sync was all wrong. So the player would be walking right with his body facing left (laughs).


    We’ve also changed the NPC models to the cat models. But unfortunately, we haven’t had the time to implement their animations yet.


    Art Styles

    Finally, we’ve been testing a couple of different art styles in the game. We want “Project SpaceVille” to have its own look and feel. So, we’re giving a lot of time and thought into this. We haven’t set anything in stone yet, other that we want it to feel cartoonish, somewhat stylized and, above all, unique.


    So, if you could help us, we’d love your opinion! Gil has been playing around with shaders and he has came up with these.





    What do you think?


    Cya next week, everyone!

    The FAXIME Team


    Follow us and keep updated at:


    • 1
    • 1
    • 56

    Recent Entries

    Hello everyone,
         we have been developing this game for a while and here are our old dev logs to catch you up from the beginning to current.

    Now here's our brand new steam page...



    Thank you everyone, for looking at out game.



  11. So WOA V has come and gone. My submission was supplied just barely under the wire, flaws and all. Over all, I'm fairly happy with my submission and I don't really want to point out all the assorted negative things to the judges that I see when I look at it but those are the things that I had hoped to find and learn from by entering.

    Thanks to everyone for making this jam possible. To our hosts at for providing the venue, to Slicer for setting up and running the show, to the judges, and to the participants. This all is a very different experience than just coding whatever I want at my own pace with no worries about bringing assorted features together to serve a purpose.

    Things that went well:

    • I was able to submit something.
    • I'm generally happy with my submission.
    • I had fun.
    • While there was a need to quickly hack together some bits of code to make stuff work, the majority of the code changes needed to the base engine felt much less like a hack and more like a natural extension of the code than last year's attempt. I consider this a really nice personal success.
    • Avoided energy drinks on the late night development sessions and thus no post project migraines.
    • Level editing stuff that I did put together worked ok. You can actually still add in some stuff if you right click (should've turned that off for release, I suppose).
    • Spoiler

      (quick editor instructions if anyone is interested)

      • If you press F6 you get a bit of debugging info including which actor you can place.
      • Press F9 and F10 to actor selections. Right click to place actor.
      • Towers and Wizards are the only actors that really have properly defined behavior.
      • Pressing Ctrl-O saves actor positions to binary file.
      • Level terrain file saved as text can be edited.
      • Level list file allows you to enter the terrain file, actor position file, and size of the level.
      • Level number should then be selectable from the main menu.


    Things that just sort of went:

    • I spent more time this year on a main menu and on having a few levels to play. And with having a few levels to play I figured it'd be a good idea to allow for which one the player would like to start from and to put a small break in between levels. This all took up one of the late night dev sessions I had available to me. I wonder a little how things might've turned out if I had left these details and instead focused on other things.

    Things to learn from or think about:

    • I struggled with figuring out what to do with the theme more than I had hoped. I ended up just with starting to work on small bits and hoped that an idea would come together, which it actually did in the end.
    • Level creation/editing is something that I found to be like smacking into a brick wall. This is likely to be my focus for the next several months, particularly since I'm at the stage of needing to look in this area for another personal project.
    • I had hoped to write more about my progress each day but I just didn't end up leaving enough time at the end of each dev session and was way too tired.
    • Could've planned time better.
    • (hiding some flaws from judges)
    • Spoiler
      • Didn't spend as much time on sound as I had thought I might.
      • Should've spent more time thinking about the game name and backstory. "Wovanosh" is basically inspired by "WOA V" with nosh at the end because I happened to be pretty hungry when I was trying to quickly think of a name.
      • A few components I had planned to add didn't make it in. I had intended on adding some alien soldiers you could "beam" to the surface to deal with the wizards on the ground by mutating them into more soldiers. The alien soldiers would be faced with human soldiers on the ground to defend the wizards and there were to be houses that the alien soldiers could convert to something the UFO would pick up to restore shields. In theory then, I could've added more wizards to shoot at the UFO and the player would have to plan the attack more carefully than just flying up and blasting at the castle.
      • I think the graphics ended up being way too simple. I had envisioned having more interesting looking human sprites but I got too hung up with proportions and perspective early on and didn't get back to revising the sprites at all.
      • Animations were less than I intended. The wizards were at least supposed to bounce a bit as they moved around. "Explosions" didn't really look like I had hoped and could've been worked on some more.



    I tell myself that I'd like to do some finishing work on this when I have time to sort of bring it all closer to the point that I had envisioned. But I do have another personal project that I'd like to get back to. I'm not sure yet on what would be the best way to take things forward from this project into the other one. But eventually, forward it will go.



    • 1
    • 0
    • 58

    Recent Entries

    THE GAME: 
    Project XSYS is an untitled indie game that features world map HEX crawling, turn based combat, and multi-character party RPG adventuring. 

    Features thus far:

    Hex Crawling

    World map hex crawling is a unique feature. It's up to the player to ensure his/her party is well prepared and provisioned for each journey. Like many 4X games,time controls allow the player to speed up, slow down, and pause the passage of time. As time passes, various events will occur such as combat encounters, interaction scenarios, inter-party personality conflicts, discoveries, etc.     

    The screenshot below is the most current view of the hex map. It is auto-generated by stitching smaller hand crafted Terrains together.   But, yes, it's  pure programmer art. :) 


    Tactical Turn Based Combat
    The combat system was built to satisfy the itch of tactical turn based enthusiasts.  In addition, I've worked hard to ensure that the combat grid is truly 3D. This means that characters can climb, fly, crawl, and jump over and under obstacles. 

    The action point based combat system is designed around the concept that your character can try to do anything.  For example, if you want to fight with two weapons, trip, guard, parry, or disarm you don't need a special skill to try it. There are no talent trees just proficiency levels. 



    Character Party 
    The character creation system is extensive and is a multi-step process. Steps include selecting Class, Race, Ability Scores, Interaction Skills, Combat Skills, Exploration Skills, Spells, Appearance, Personality, Backgrounds, etc.  At the moment, the system allows you to create up to six characters. 

    At the moment, the graphics are nothing more than prototypes / placeholders. I don't plan on hiring or partnering with an artist until next year. One of the first things I will have commissioned is a base character model and various pieces of equipment for each race.  

    For the moment, Adam and a pair of Mixamo thugs will do just nicely. 

    Create New Character.PNG



    Thus far, I've spent many long nights coding and refractoring the games numerous subsystems (true 3d grid pathfinding, sqlite database, event message system, animations, personality system, combat mechanics, inventory, character sheets, items, vendors, character creation, terrain based hex map, encounter system, survival mechanics, campaign events, etc).  The game has truly become a labor of love and I'm quite happy with the code thus far, but of course it's not perfect... yet.

    My current focus is developing the content pipeline and assessing what Unity assets (if any) I will be integrating.  In fact, I can't wait to start adding more creative elements to my game. The game is now moving from being a game framework to an actual game, but there are still many detailed decisions that have not been made. 

    Anyway, I hope you enjoy watching my game take shape.  I really need all the feedback I can get as I have much to learn. 



  12. Ideas for armour sets & jetpacks Mito Horvat

    I made a couple of different concept sketches for the armor sets that I mentioned in the previous blog post. From simple wooden planks tied on the player to welded metal plates that form a strong looking armor. Below you can see some of the examples (arms, legs and helmet).

    arms legs head armour floatlands

    sketches for arms, legs and head armour

    This week I mainly focused on the player jetpack. I created various jetpacks that would fit into the game, and then create 3 different “skin” types that will include particle effects individual to each “skin”, and added modular pieces so they will differ from each other.

    jetpacks sketches lowpoly floatlands

    jetpack variations

    Armour sets Andrej Krebs

    After we got settled into the new offices and extended the weekend, I started preparing the gear and outfit models for the player’s 3rd person model. Mito prepared some sketches for me and I modeled wooden and junk metal armour sets so far. The armour sets are made as separate items the player will be able to equip: Head gear, body armour and leg armour. The jet pack will also be an item that will be equipped. The armour sets will also get more models as skins for the players to collect and wear proudly.

    armour sets lowpoly floatlands

    armour sets

    Drone destruction tadej vranesic floatlands

    This week was all about the way enemy drones react when they get hit by a bullet. Running away manouver really gives them a life-like feel. Another cool little quirk we added was, how drones fall apart when they are destroyed. The connections between parent/children parts are being disabled and a small “invisible” explosion is created, so that parts fall away from that destroyed position.

    drone destruction lowpoly floatlands

    drone destruction

    Logic Gate system vili ikona

    Lately I’ve been improving the Logic Gate system. I wish to make event-driven logic simulation, and it’s quite a hard thing to do. Why did I decide to do this? Because current implementation of logic gate simulation is really bad and I doubt people will be able to play with complicated logic. Unfortunately I can’t show you any pictures yet, but I can explain a little bit about the base components of current state though:

    • Pin – can be input, output or bidirectional
    • Connection – connects two pins
    • Element – element consists of many pins, can think and update state
    • Event – events are raised on changes, then processed when it’s time
    • ProcessingSystem – this system holds all those components and processes events

    The hardest part so far has been building a correct simulation. A simulation that can be modified in real time – adding and removing elements, connecting elements, or pressing hubs on switch.

    Recording voices for NPCs chris icon

    Currently we are recording and reviewing different ways of incorporating voices for our NPC’s. When it comes to speech, we will not record out every single line, but we will try to bring reactions and emotions across. I have build a homemade vocal booth that will serve for recording the voices and sound-FX.

    voc floatlands

    Sound-FX will be partly recorded and partly created with synthesizers. For recording sounds we will switch between an instrument microphone (SM75) and a condenser microphone (NT1A).

    instmic floatlands

    Singal processing is important. Every recording will be enhanced and amplified. You can’t go anywhere without a Pre-Amp and my weapon of choice is a Golden Age Pre 73 MKIII.

    preamp floatlands

    Further sound processing will be done with plug-ins that I will demonstrate on a later update.

    More about Floatlands: website, facebook, twitter, instagram

  13. Play it! | View on GitHub

    Now that I am slightly recovered after the Week of Awesome, I want to share my thoughts about what went well and what I have learned after this experience. A quite important part of my project was to experiment with functional reactive programming in games, and I promised to share some reflections about it afterwards. I'm going to talk about that in the second part of the post-mortem, which I expect to publish early next week.

    What was great

    Community support and feedback

    The absolutely best thing about participating in this contest was all the encouragement and feedback I got from the community. Big thanks to everybody who took the time to play my game, read my blog entries, post feedback and encouraging comments, and even find and report bugs!

    My game would have been a lot worse without that feedback. Many people suggested features I hadn't thought of or I had dismissed earlier because I didn't think they were that important. The ability to move to the left and better control of the landing position when jumping are clear examples of this. It was also really motivating to see every day people playing the game and posting new feedback.

    Browser game

    I think that going down the browser route was a good idea after all. The cool thing about the browser is that everybody has one. Distributing your game is so easy: no installation or configuration required, and everybody can play it regardless of operative system or installed runtimes. I could upload the game to my VPS since day one, update it often, and have people trying it out, which was great and I think that it made a difference in the amount of feedback I received.

    What I would do differently

    Have a level editor

    The game I delivered is inexcusably short. Once I had the basic mechanics going, it would have been really easy to add more and longer levels. The only reason holding me back was that I didn't have any visual tool to create and edit them. I created the only level in the game by manually editing a JSON file. As you can imagine, that was a tedious job and I decided to invest the little time I had in solving other stuff. Not having a level editor also prevented me from iterating the level and making sure it was fun and challenging enough.

    Next time, I will make sure to have a visual tool to create levels and maps at hand before the contest starts.

    Test the delivery format early

    When I set off to make a browser game, I set up a local development web server to serve the file and recompile and reload the changes quickly. I knew that I would end up delivering an index.html file with a .js bundle and that the judges would load that file from the file system instead of a web server. That should make no difference, right? Wrong! Turns out that Chrome, among other browsers, doesn't allow AJAX requests when loading a file directly from the file system. And guess how the rendering library I used loads spritesheets? Exactly: AJAX calls.

    I should have tested running the game from the file system since day one. Instead, I only tried it when I was about to upload the final submission. If I had known about the AJAX issue earlier, I could have written my own resource loader, or bundled the game with electron. Instead, by the time I noticed the issue, I didn't have the time nor the energy to do something about it.

    Even though the game can still be run locally with Firefox, I provided a python script to run it on a local web server, and some judges didn't mind playing it on my VPS, my developer soul still hurts because I wasn't able to deliver software that runs with a single click.


    This community is awesome. I got far more interest and feedback than I expected. I liked the experience of making a browser game, even though at the end it wasn't as smooth as I thought, and I definitely need to get a level/map editor next time.

    If you are interested in reading my musings about using functional reactive style in games, stay tuned  for the second part of the post-mortem.

  14. Hi. To be honest, but the game design for me has always been something unique and interesting. My path of game development first started with programming. After I began to draw, in order to be universal, but later, I discovered the game design and that was for me, on a pedestal favorite direction. Today I would like to touch on the types of players, why they play the games and pleasures of games.



    Be brief and clear. In our nature there are 4 types of players: explorers, killers, sociable and those who like committed to something. 

    Crooks. This type of players are focused more on the quick passing game. It does not matter the study and details in the game. 
    Killer. These guys love to destroy everything and kill everybody. Just put them in the tank, tell them where it is necessary to blow - trust me, they will not leave anything alive there.
    Sociable. They love socializing, but most of all they love online games where can someone make friends, work in team and to tell you the recipe for a delicious mother's cookies. 
    Researchers. How do you think, what you like to do this group of players? I also think that they are exploring every path in the game where you can collect all achievements. 

    Every time you create a game, ask yourself the question: "what kind of player I do my game? Is it possible to combine these types of players in my game, changed some part of it?"




    Incidentally, with regard to online games. Why do you think people play online games? First, they like competition, will compete to get to the top and gain respect. Secondly, people like to work in a team. Personally I play team games and more hours spent in team modes rather than in single. I love this mode. Thirdly, people play online games in order to meet and chat with friends, spend time with them online and meeting them to have constant, friendly contact.

    As you know, men play more games than girls. Their main game is the first 20 years. Action and aesthetics - their element. From 20 to 30 years, men are already playing something more calm and tactical, where you do not need a lot of push on the joystick, but need to think. And about men from 30-35 years to play in something calm, for example in genres "I'm search" and "Farm".

    But women, as a rule, begin actively playing with for 30 years. More women in the world, but I don't like the game. But often after 30 years of playing farm frenzy.





    Identify the main fun of the players: 

    Fantasy. We love to feel part of another world, which could be anyone. 
    Plot. Sometimes the plot can cause a pleasant sense of his sudden change of events, a dramatic denouement and linearity. 
    Partnership. Teamwork is enjoyable. 
    Discovery. The opening of the new - is the main game fun. 
    Expression. Everyone loves to brag about. 
    Obedience. Cool when you can control others.
    Feeling. When you realize that step the expected event, then the waiting becomes a pleasure. 
    The gloating. When you killed your enemy, it's nice. 
    Gifts. We love to receive gifts? 
    Humor. No comment. 
    Choice. To go left or right? I have a choice?
    Fulfilled goal. We love to reach goals and to feel pride because of this.
    Surprise. We love to be surprised. The Japanese are masters at it. 
    Fear. We love to be frightened and to feel the shaking. This is an interesting kind of fun that we both and hate. 
    A miracle. When we are strongly of something was surprised and experienced a wild delight from something. 
    A tough win. That moment, when initially there was little chance to win, but you win.


    So when making a game, think of the fun highlights of your game and how much to add. My name is Flatingo and I love to make games. If you also like to make games, welcome to my YouTube channel. Good luck in your projects.


    About the game

    Aliens from the Sky is an arena based shooter, where you as an alien need to destroy the human castle, avoid the mage spells and upgrade your ship.

    What went well

    • Game in a playable state.

    • Effects and details that adds up to the overall user experience.

    • Flexible design that allowed to cut some features without compromising gameplay.

    • Implemented at least 3 upgrades.

    • Both themes (Alien invasion, Castle) seems to work well.

    What went wrong

    • Spend the first 2 days mostly designing, had several ideas but all were out of scope.

    • No main menu.

    • Wanted and still want to do pixel art instead of vector art.

    • Music and sound effects could be better.

    • End game scene needs a lot of polish.

    • Had to cut difficulty levels and just focus on one.


    When designing I was thinking only on themes instead of mechanics, which led to projects out of scope. And I should work look for teams to work with.

    Overall I’m happy with the results, hopefully I’ll participate next year.

  16. title.thumb.png.a49110f89b2638cd8677a5c3d5a19e85.png

    This is another fairly short update. Beta testing is now ready. I am having issues getting an account setup with AlphaBetaGamer so I will have to do this manually. If your interested in testing the game shoot me an email at or contact me through my website and let me know which build you would like Android, Windows x64, or Mac . Not sure what kind of response I'll be getting so I may not be able to give access to everyone. I'm hoping to have 40 to 60 people test this out for me. I will respond to requests as fast as I possibly can. The beta builds will only work for a limited time.

  17. Hi guys! We've finally set the release date for Rock of Ages 2; August 28, which is just around the corner! Check out our latest "Rockin' Trailer" to get a preview of what we've been working on all these last months. 

    The title will release for $14.99 and as a bonus we're throwing a free 'Binding of Isaac' themed pack for all purchases made the first 4 weeks from release (huge thanks to the awesome guys at Nicalis/Edmund McMillen).

    The game will be available for purchase on the 28th. We'll also introduce a few purchasing options for people that already own RoA1 (get OST and 'Classic Pack' for free!).

    Enjoy the new trailer and make sure to share the news with your friends!

    And check out a brand-new RoA2 website! There's more information and details about the game, pricing/bundles and other media.



    What is Rock of Ages II: Bigger & Boulder?

    Rock of Ages II: Bigger & Boulder is a game that improves on all aspects of the original. Up to 4 players can battle in crazy boulder mayhem. New impressive art periods, more historical characters and the funniest story clips we've ever made. All rendered with highly improved destruction / physics and effects - powered by our first Unreal Engine 4 game.

    Follow ACE Team:

  18. So just got online when I noticed a few emails asking me how I got so many physic objects working in Unity.

    The answer to that is nothing special. On average there should only be a 1000 physics objects on screen. The physics is also a lot more strict on making objects sleep.

    The way this is done is the same most AAA games work with art. In a AAA game it isn't rare to have a static duplicate of a skinned mesh. As a example take the players gun, often the gun will be a skinned mesh, playing it's firing animation while the player presses fire.

    However skinned meshes have an extra cost just to be in a game, so because exporting the static model only takes a click of a button and the code for swapping them is very fast you can just change your animated model into a static model. Some engines even turns a animated into a static when it's done with the animation.


    So in Project Castle I did what most games would do with a destructible wall. First I made a object using physic blocks, then I took there meshes and generated a new mesh. The blocks are disabled and the new mesh is displayed. When any object that can hit it is near the static mesh is swapped for the rigid bodies.


    Now at this point of the blog I thought I would share the code, although @Avalander says my new build still doesn't working so I realized I could just upload the Unity pack. Everything, except Unity, was made by me for this game so you can use it as is.

    Import the Unity pack as a custom pack. The layer for shooting is "Water" because the Unity pack doesn't export layers. Space key will swap physics for static meshes, causes a kind of freeze time effect.


    I would like criticism on my code if anyone has time for it.



  19. Welcome to another dev blog of Hell Warders, this is Godboy!! Yes, it is me again...

    Last week, we were busy with the exhibition in Hong Kong. We had a booth with a trailer showing and two game trial station. It was fun to talk with the players face to face and listen to their comments. It lasted for four days. It was fun to step out of our office and do something different! We will be joining more and more competitions and exhibition in coming future! Let us know if you would like us to join some of your events!

    After the exhibition, we are now back on working the major update. Lots of scene updates, balancing, character designs, tons of stuff need to improve. 







  20. New video featuring last week of work, getting more views with every new video :



    Please, give me some comments to improve.


    Thanks !

    • 1
    • 1
    • 63

    Recent Entries

    Greetings everyone!

    I finally managed to put together complete system that will be used as a backbone of my new game. The game itself is supposed to be a mix of Kerbal Space Program and Space Engineers in 2d, maybe with some added influences from other games. I'll get back to this later, when gameplay is more fleshed out. Right now what the game needs is: orbital physics of planetary system, large deformable terrains with rigid body simulation and transitions between those two.

    tl;dr; There is a video.

    Orbital physics

    This part was relatively easy. I choose simulated n-body system over fixed orbits with patched conic approximation. It's simple to write and supports all phenomena like Lagrange points. My system uses Verlet integration with fixed time step (64s) for planets and adaptive time step for small entities (artificial satellites, asteroids). The only drawback here is that plotting trajectories requires to know positions of all planets ahead of time, so it's best to evaluate whole system many steps to the future and just playback current position from history. (You can see these in video when debug drawing is enabled)

    Planetary physics

    I modeled planet's surface as linear space located around planet radius, with wrapping around when traveling sideways. Since I want my planets big (not real live big, not even KSP big, but still), each one is split into spaces that span around 4km.


    Those spaces are all linear and centered around origin. Rigid bodies can move from one to another, can have joints across spaces, but will never collide or interact in any way.


    Of course the problem is when some body wants to leave one space and enter another. We could simply teleport whole rigid body, but it would miss some collisions.


    My solution is to clone whole body at new location and link them with teleport joint. It's similar to fixed joint, but maintains relative offset. (don't forget to split mass in half between two bodies)


    In order for this to work, you need two bounding rectangles: tight and fat. When tight intersects space boundary clone body (2). Destroy cloned body only if fat stops intersecting boundary (4).


    For all this to work I made some changes to Box2D library, you can find my fork on github.

    Stitching it together

    Moving from planet surface space to orbital space is using simple teleportation with conversion from local space coordinates to global orbital one. I sill have some quirks to iron out, but hey, you can fly to the moon!

  21. Day 5 - 7 & Beyond!


    Link to a google drive folder of our game:


    Helter Skelter


    What a busy few days...

    We missed a few days of blog posts as we were too busy getting things to work and couldn't pull ourselves away. So i'm going to try to cover everything that happened along the way as best I can.


    After day 4 the panic was starting to set in, we still had so much to do and the clock didn't wait for us. I was stuck trying to learn and build a working third person controller while Moofle was busy with getting interactable barrels to work. Those would be used by the AI to knock them down and slow you if you were chasing them.


    At this point I was busy trying to get ground collision and walking to work. I made this work using raycasts to check how far the player was from the ground. The raycast was from the character's origin straight down with an extra variable in place so that we could change the height of the character to account for different model sizes. if that raycast failed I had 4 more in each cardinal direction so that the character could be on the edge and not fall off, making them more than just a single point. there are still places where this could fail with weird terrain but that's an acceptable constraint for the time being. if they were on the ground then using a state manager they would have an idle state and be set as on the ground. if there was forward input from the player (w key) then that would set them to moving and the animation controller would transition them to walking.

    Now if they aren't on the ground I set them to inAir and start a counter to check their airtime (used later to drive the type of animation when they land, could alternatively save the position they were at and then when they land and calculate the distance which could also be used for fall damage, however this doesn't account for jumping.) while they're in the air I turn off jumping ( could be tweaked to allow air/double jumps). At first I used horizontal input from the A & D keys to drive their rotation however due to the camera we created to drive the player's rotation based on the camera's view made things a little complicated. Ideally I would have the player control the rotation with the camera and then strafe with the directional keys. however this wouldn't work for all game types so I might do away with this in the future if it doesn't work well.

    Next I added running which is driven by the shift key. The shift key drives the forward velocity and the animation state changes to running when the forward input is greater than the walking magnitude. within the controller I setup a blend tree to handle running in either direction. Due to animation limitations and not wanting the character to slide I implemented a limit to the amount in degrees that you could turn while running, If you exceeded it then the character would stop and make the turn. This doesn't feel great with the fast paced nature of the chase, so it's first on my list of things to fix.

    After running I implemented a state change to go from running to idle, with a small animation that has them slowing down before stopping, this looks way better than going from running to 0 in 1 frame. Alternatively I could just transition them back to walking before going to Idle but I think that will take too long in the animation phase and look weird, but stuff to experiment with after.

    Next I worked with jumping and falling. jumping has an addVelocity function attached to it which I can tweak in the inspector. Along with this I do a check using the position of the feet to see which leg is in front and then mirroring the jump animation to make the transition a little more natural.

    the in air state is basically and opposite of on ground and while it's doing that it has a counter, if it's greater than a threshold then it will play one of two animations. One for falling normally from a great height and the second if the player is inputting for the character to move then it will do a roll when it lands which they can transition to walking and then running. I might implement one for running after the roll in the future if I get a good animation.

    That's the basic functionality done. most of that was done in day 5 and some in day.


    While I was going crazy with the movement controller Moofle was busy figuring out raycasts for clicking on objects to interact with them in some way. He started with barrels, whcih when clicked would send them flying in the opposite direction from the player, think of this as the player running up to a barrel and kicking it. This took a while to setup mostly because he didn't want to do it the quick hacky way and wanted to make it easier to add interaction to other objects without having to write a script for each type of object. this worked well until there were more than one object of the type in the scene it would send the first one flying. After some fiddling and brainstorming we got that to work in the intended manner. Next he worked on a castle portcullis that would open and close with a little animation when clicked on (ideally it would be a lever close to it that would drive this) this took a little longer as he learnt about animation controllers and animating in unity as well as needing to alter one of the models as they portcullis was attached to it. It was quite an experience but I think he learnt a lot. We also configured it to work with the navmesh as an obstacle so when it's closed the AI would know they couldn't go through it.


    Day 6

    Day 6 was more environment building for me as well as adding things to my movement controller and getting the model and animations setup correctly. Moofle on the other hand worked on some more interactables, one an informant that would let you know where your target is on your minimap and the other that goes up to them and slows them down, or stops them if their paranoia is low enough.


    The next thing I added was walking on an incline. Using more raycasts and math to check the angle of the surface you are walking on, if it's not too steep then the character would be able to go up or down them, albeit more slowly and with a specific animation. This worked well but didn't look that great when you stopped as the other animations didn't work so well with inclines. This will be fixed when I add foot IK into the mix.

    I had some available time (not really but I went for it anyway because it was cool) I worked on adding vaulting over thin enough objects, that way if there was a fence they could just hop over it. This was done with - you guessed it - more ray casts. There is already one sent outward to check for obstacles, now I added one higher up that would go forward to the max vaulting range and then cast downward, if it doesn't hit the ground then it's too thick otherwise it's ok for vaulting. There's also a check for the angle so that if you're running next to it or at a steep angle you won't just vault over it. I had to fiddle quite a while to make the animations work nicely, I have one for walking and another for running.


    Learning from my work Moofle implemented raycasts to check if the informant or agent can see the player and if they in range then they would do what they're supposed to. This works really well and we have some cool agents that would go up and stop or slow the target down for the time we set and others that would follow the players position if they in range and can see them then they would be displayed on your minimap. I'm making it sound easier than it was, it took quite a while to make everything work and look great and work together without breaking the game, he did a good job.


    Day 7


    The final day hit and we still had a mountain to climb infront of us.

    I finished up enough of the level and got the navmesh to play nicely. Moofle set up all the waypoints for the AI to go to. Next was a few hours of merging our different parts and making sure we got rid of game breaking bugs. it took longer than we thought and was filled with frustration. But we got things to work together for the most part. The last thing was driving the target's paranoia and setting it to full when the player is in range and the AI sees them for long enough ( a second or two)

    In the end we didn't manage to use the portcullis and there was still much of the level that was unfinished.

    Unfortunately we didn't have time to add a kill assassination sequence in it for when you reach the player and we were also having trouble with the win condition of touching the target. So for now when you get close to the player you win the game and it quits. Not quite what we wanted but it's somewhat functional.

    We rushed to get everything done and built and then submitted.


    It was late we were exhausted but we did it for the most part...

    It was a great experience and we will definitely be doing it again! We both learnt so much and we now have a list of what not to do when doing a game jam. But for our first one we're both quite happy with the work we did an what we got out of it.


    From here on we're going to keep working on the controller and probably the AI too to get a much more functioning and fun game.

    Thanks to everyone that got this far and joined us on our adventure!!

  22. Hey guys!

    From the 22nd - 26th of august, The Whaler will have its own booth at gamescom in cologne, Germany.

    I (Tommy) will be there presenting the game and ready to answer any questions you might have, so if you have any plans of going there, please come by and say hi!

    20525384 10159126988255297 83515


    We also have the brochure ready for Gamescom as well, if you do not get to go, you can have a look at the brochure here! If you want a better resolution uploaded, let me know and I will take care of it.



    The webpage has also been launched, this is how it looks now until we have a full launch of the page sometime next year, but for now you can go to and sign up for the newsletter, closed beta and some radical giveaways!



    Other then that, development is going ahead at full whale and pretty soon I will show you guys were we are at.

    Hope you had a great weekend, talk soon!