• Advertisement


Featured Entries

  • QLMesh 2.0 and Asset Import Library

    By piecuch.p

    For QLMesh (and some other projects), I am running my own fork of Asset Import Library.  The difference: it is amalgamated build - all sources are merged into one file (including dependencies). Since Assimp recently switched to miniz, I have replaced remaining references to zlib with miniz - so zlib is not required too. drwxr-xr-x  85 piecuchp  staff     2890 Jan 17 23:34 assimp -rw-r--r--   1 piecuchp  staff  4921627 Jan 17 23:34 assimp.cpp -rw-r--r--   1 piecuchp  staff  2893785 Jan 17 23:34 private\assimp.h   Everything you need to buid the assimp is: g++ -c -std=c++11 code-portable/assimp.cpp or just add assimp.cpp to your project/IDE (you can find code-portable directory in my repo. One disclaimer: I have only tested this amalgamation under OSX with QLMesh). Main reason for this amalgamation is that it makes compilation/recompilation on different platforms with different configurations rather easier. Side-effect is that single-file assimp.cpp compiles really fast (like 10x faster on my MacBook than original project files). (http://pawelp.ath.cx/)(http://komsoft.ath.cx/)(https://itunes.apple.com/us/app/qlmesh/id1037909675)
    • 1 comment
  • Devblog #36: UI, Terrain, Companions

    By Ph4nt0m

    ANDREJ KREBS I started making the player’s companion based on Mito’s design sketches. This will be a small floating robot, that will follow the player around and be available to him. The companion will mostly stay out of the way, but the player will be able to call it to help him with certain tasks. Usefulness of a companion They will be projecting the inventory, crafting and character UI. This will be a mostly aesthetic task that should add some more immersion. Companion will have a limited healing capability. It will be able to heal the player, but its healing capacity will deplete quickly and will take time to recharge. It will work as a limited gathering tool. The companion will be able to shoot a mining laser, that will break trees, rocks and mining veins, but it will quickly run out of power and need to recharge. This will give the player the ability to gather resources, even if he finds himself without any gathering tools, but also give him incentive to craft them, because they are much quicker at the task. Technically, the companion will be regarded as a tool that will always be available. It is animated in a similar way as the weapons, meaning it has animated interactions with the player character’s first person rig.   More User Interface Changes
    DOMEN KONESKI Player Stats
    In the lower right corner you will find various player variables: health points, energy points, companion energy points and jet pack fuel. The panel is intuitive – the most important player stats have colors. If a certain stat is being low, the icon starts flashing (there will be also danger SFX for it later). If you gain certain stat (e.g. you are getting healed or damaged), the text color is changed as well to notify you something is happening to you. More details about a certain player stat:
    Player stats Health points: this is something you will have to watch out for a lot, like in other games. You will be able to replentish your health in various ways, from consumable items, companion healing and world “healing stations”. Energy points: this is the secondary stat to monitor. It depletes when doing certain tasks: mining, jumping/running endlessly, diving in waters, staying in radioactive zones, to name a few. To replentish the energy, you will be able to craft yourself energy batteries or build yourself (or finding one in the world) a charging station. Companion energy: as mentioned before, you will be able to use your companion to heal yourself or as low-level resource gathering tool (until you craft yourself a pickaxe or another more advanced tool). Companion energy will deplete and replentish fast and its resource gathering/healing capabilities are basic. Jet fuel: it will be used to reach previous unaccessable areas with fast depletion and slow replentish rate. There will be no way to replentish it with consumable items.
    Item Bonuses
    Since we have player stats now defined and ready to use, there should be an option of improving or degrading them. For this purpose, I’ve implemented item bonus system that’s going to be enabled if you put items in your hotbar or gear slot (gear items won’t work in your hotbar though). A sample item with bonuses:
    Item bonuses Crafting Menu
    Crafting menu has been overhauled to be more intiutive. The design is not yet finished as it requires SDF icons and other minor tweaks. Items are sorted in different categories, from weapons, tools to electornic devices. You can easily see what items are still missing to craft a certain item or if it requires a workbench to craft it (applies for bigger, more advanced items).
    Crafting menu Crafting Queue
    You can add up to 5 items to your crafting queue where items are being crafted for you. You can cancel certain recipe from being crafted and regain all items needed for this recipe back to your inventory.
    Crafting queue Resource helper
    TADEJ VRANEŠIČ I’ve been creating an in house resource helper, that will reduce time costs of searching and manually changing files containing item definitions and resource definitions. What you see is an XAML app, that parses .json file and gets out values of each item. These values can be manipulated easily through WIP UI interface and later simply replaced by just one click of the button. Soon I’ll be moving to crafting variables, and its manipulation.
    Resource & Crafting Helper As you can see, this is a necessary chore, which allowes even non-coders in the team to easily fix over or under saturated values of variables. This will become specially useful in the testing phase, so we’ll be able to change things on the fly. Later on, I’m going to implement server connection, which will broader the options what we can do with it. Nothing is sure for now, but a bit deprecated version could be used even for players. That way they know which items/crafting receipts are used in the game, or even for modding support. But as I said before, this is just a thought, we will let time decide other proper use cases for it.
    Updating UI icons
    MITO HORVAT Since Domen is extensively reworking the entire UI and the whole inventory system, we’ll have to update the icons as well. The current icon style won’t fit the UI design that is currently being created. So this week was kind of frustrating, simply because its not the simplest task to find the exact type of icon style to fit the UI. After plenty of rejections and reworks this is what I came up with. Some of them will probably get replaced in the near future.   Terrain
    VILI VOLČINI Due to creating a new Floatlands world lately, I had to rework terrain as well. Optimizations: Multithreading of all operations on 2D maps, which includes Perlin noise generation, filtering, map rotation, addition. Pool for 1D and 2D arrays, also with thread-safe functions. Direct mesh contruction (previously mesh was constructed then modified). Caching where possible to avoid Garbage Collection. New features were also added: Signed Distance Field for each Biome, so I can know how far away from biome edge I am (inside & outside). Picking quad diagonal based on surface curvature, so that mesh looks more natural. Multithreading: To demonstrate how it’s done on 2D arrays. Lets say you have a quadcore PC, then we split any workload to 4 parts, so each thread gets it’s own part to work on. A code example of how it’s done in our project.     1 2 3 4 5 6 7 8 9 10 11 12 /// N is resolution map /// x is index MapUtils.ForPararell(N, (x) => {       // this closure inside is now running on it's own thread       for (int y = 0; y < N; y++) {           // do operations on 2D arrays as you'd normally do,         // don't share state between threads though, or bad things will happen     } });   This is the current state of terrain, with still some tweaking to go:  
    More about Floatlands: Discord Facebook Twitter Instagram  
    • 1 comment
  • Components and Messages in Unity

    By nbrosz

    Up to now, I have had a tendency toward monolithic classes when developing in Unity. My experience has always been with the typical object-oriented approach (with the exception of when I was developing using batari Basic), but I’ve been trying to train myself toward small, reusable components with focused purposes. I’ve had some good success lately, breaking larger scripts into smaller ones and using interfaces as a means of communicating between components where possible. public class ReportAttack : MonoBehaviour, IDamageable { public Team team; void Start () { team = GetComponent<Team>(); } void IDamageable.TakeDamage(MonoBehaviour from, DamageType type, float amount) { var attackerTeam = from.GetComponent<Team>(); if (team && attackerTeam && team.team != attackerTeam.team) Debug.Log(gameObject.name + " says: I've Been Attacked by " + from.gameObject + " on team " + (attackerTeam ? attackerTeam.team.ToString() : "no team") + " with " + System.Enum.GetName(typeof(DamageType), (DamageType)((int)type << 1)) + " (" + (int)type + ")"); } } While I’ve been fairly satisfied with the use of interfaces for calls to multiple or unknown components, I recall fondly the rapid development and flexible approach provided by utilizing messages in my 2017 Global Game Jam submission, Metalmancer. However, since Unity’s message passing uses reflection (or at least probably does, given that it takes the string name of the event to call), it does not perform particularly well. With that in mind, I hoped to make my own, alternative messaging system which is used much like the existing messaging system, but uses delegates and event handlers under the hood. This was the result. While I felt that I succeeded in my goal of providing a useful interface that hid the reflection-based old messaging system, I was crestfallen once I began running tests. On average, I see a performance increase of about 33% over Unity’s built in SendMessage, with the complication that all components using the new system must inherit from the new MessagingBehavior abstract class, rather than directly from MonoBehavior. Still, given that a direct call (as would be the case using an interface) is still about ten times faster, I wasn’t particularly encouraged by these results. On the other hand, as tomvds said in the Unity forums: Still, stubborn as I am, it’ll be hard to convince myself to use even my own message passing architecture in lieu of more efficient interfaces. Or maybe I should just use an adaptation of wmiller’s Events system. Or I should just stop worrying about it.
    View the full article
    • 1 comment
  • Code Reuse In Actual Practice

    By ApochPiQ

    It’s very common to hear engineers talking about "code reuse" - particularly in a positive light. We love to say that we’ll make our designs "reusable". Most of the time the meaning of this is pretty well understood; someday, we want our code to be able to be applied to some different use case and still work without extensive changes. But in practice, code reuse tends to fall flat. A common bit of wisdom is that you shouldn’t even try to make code reusable until you have three different use cases that would benefit from it. This is actually very good advice, and I’ve found it helps a lot to step back from the obsession with reusability for a moment and just let oneself write some "one-off" code that actually works. This hints at the possibility of a few flaws in the engineering mindset that reuse is a noble goal. Why Not Reuse? Arguing for reuse is easy: if you only have to write and debug the code once, but can benefit from it multiple times, it’s clearly better than writing very similar code five or six times…​ right? Yes and no. Premature generalization is a very real thing. Sometimes we can’t even see reuse potential until we’ve written similar systems repeatedly, and then it becomes clear that they could be unified. On the flip side, sometimes we design reusable components that are so generic they don’t actually do what we needed them to do in the first place. This is a central theme of the story of Design Patterns as a cultural phenomenon. Patterns were originally a descriptive thing. You find a common thread in five or six different systems, and you give it a name. Accumulate enough named things, though, and people start wanting to put the cart before the horse. Patterns became prescriptive - if you want to build a Foo, you use the Bar pattern, duh! So clearly there is a balancing act here. Something is wrong with the idea that all code should be reusable, but something is equally wrong with copy/pasting functions and never unifying them. But another, more insidious factor is at play here. Most of the time we don’t actually reuse code, even if it was designed to be reusable. And identifying reasons for this lapse is going to be central to making software development scalable into the future. If we keep rewriting the same few thousand systems we’re never going to do anything fun. Identifying Why We Don’t Reuse Here’s a real world use case. I want to design a system for handling callbacks in a video game engine. But I’ve already got several such systems, built for me by previous development efforts in the company. Most of them are basically the exact same thing with minor tweaks: Define an "event source" Define some mechanism by which objects can tell the event source that they are "interested" in some particular events When the event source says so, go through the container of listeners and give them a callback to tell them that an event happened Easy. Except Guild Wars 2 alone has around half a dozen different mechanisms for accomplishing this basic arrangement. Some are client-side, some are server-side, some relay messages between client and server, but ultimately they all do the exact same job. This is a classic example of looking at existing code and deciding it might be good to refactor it into a simpler form. Except GW2 is a multi-million line-of-code behemoth, and I sure as hell don’t want to wade through that much code to replace a fundamental mechanism. So the question becomes, if we’re going to make a better version, who’s gonna use it? For now the question is academic, but it’s worth thinking about. We’re certainly not going to stop making games any time soon, so eventually we should have a standardized callback library that everyone agrees on. So far so good. But what if I want to open-source the callback system, and let other people use it? If it’s good enough to serve all of ArenaNet’s myriad uses, surely it’d be handy elsewhere! Of course, nobody wants a callback system that’s tied to implementation details of Guild Wars 2, so we need to make the code genuinely reusable. There are plenty of reasons not to use an open-source callback library, especially if you have particular needs that aren’t represented by the library’s design. But the single biggest killer of code reuse is dependencies. Some dependencies are obvious. Foo derives from base class Bar, therefore there is a dependency between Foo and Bar, for just one example. But others are more devilish. Say I published my callback library. Somewhere in there, the library has to maintain a container of "things that care about Event X." How do we implement the container? Code reuse is the name of the game here. The obvious answer (outside of game dev) is to use the C++ Standard Library, such as a std::vector or std::map (or both). In games, though, the standard library is often forbidden. I won’t get into the argument here, but let’s just say that sometimes you don’t get to choose what libraries you rely on. So I have a couple of options. I can release my library with std dependencies, which immediately means it’s useless to half my audience. They have to rewrite a bunch of junk to make my code interoperate with their code and suddenly we’re not reusing anything anymore. The other option is to roll my own container, such as a trivial linked list. But that’s even worse, because everyone has a container library, and adding yet another lousy linked list implementation to the world isn’t reuse either. Policy-Based Programming to the Rescue The notion of policy-based architecture is hardly new, but it is sadly underused in most practical applications. I won’t get into the whole exploration of the idea here, since that’d take a lot of space, and I mostly just want to give readers a taste of what it can do. Here’s the basic idea. Let’s start with a simple container dependency. class ThingWhatDoesCoolStuff { std::vector<int> Stuff; }; This clearly makes our nifty class dependent on std::vector, which is not great for people who don’t have std::vector in their acceptable tools list. Let’s make this a bit better, shall we? template <typename ContainerType> class ThingWhatDoesCoolStuff { ContainerType Stuff; }; // Clients do this ThingWhatDoesCoolStuff<std::vector<int>> Thing; Slightly better, but now clients have to spell a really weird name all the time (which admittedly can be solved to great extent with a typedef and C++11 using declarations). This also breaks when we actually write code: template <typename ContainerType> class ThingWhatDoesCoolStuff { public: void AddStuff (int stuff) { Stuff.push_back(stuff); } private: ContainerType Stuff; }; This works provided that the container we give it has a method called push_back. What if the method in my library is called Add instead? Now we have a compiler error, and I have to rewrite the nifty class to conform to my container’s API instead of the C++ Standard Library API. So much for reuse. You know what they say, you can solve any problem by adding enough layers of indirection! So let’s do that real quick. // This goes in the reusable library template <typename Policy> class ThingWhatDoesCoolStuff { private: // YES I SWEAR THIS IS REAL SYNTAX typedef typename Policy::template ContainerType<int> Container; // Give us a member container of the desired type! Container Stuff; public: void AddStuff (int stuff) { using Adapter = Policy::ContainerAdapter<int>; Adapter::PushBack(&Stuff, stuff); } }; // Users of the library just need to write this once: struct MyPolicy { // This just needs to point to the container we want template <typename T> using ContainerType = std::vector<T>; template <typename T> struct ContainerAdapter { static inline void PushBack (MyPolicy::ContainerType * container, T && element) { // This would change based on the API we use container->push_back(element); } }; }; Let’s pull this apart and see how it works. First, we introduce a template "policy" which lets us decouple our nifty class from all the things it relies on, such as container classes. Any "reusable" code should be decoupled from its dependencies. (This by no means the only way to do so, even in C++, but it’s a nice trick to have in your kit.) The hairy parts of this are really just the syntax for it all. Effectively, our nifty class just says "hey I want to use some container, and an adapter API that I know how to talk to. If you can give me an adapter to your container I’ll happily use it!" Here we use templates to avoid a lot of virtual dispatch overhead. Theoretically I could make a base class like "Container" and inherit from it and blah blah vomit I hate myself for just thinking this. Let’s not explore that notion any further. What’s cool is that I can keep the library code 100% identical between projects that do use the C++ Standard Library, and projects which don’t. So I could publish my callback system exactly once, and nobody would have to edit the code to use it. There is a cost here, and it’s worth thinking about: any time someone reuses my code, they have to write a suitable policy. In practice, this means you write a policy about once for every time you change your entire code base to use a different container API. In other words, pffffft. For things which aren’t as stable as containers, the policy cost may become more significant. This is why you want to reuse in only carefully considered ways, preferably (as mentioned earlier) when you have several use cases that can benefit from that shared abstraction. Concluding Thoughts One last idea to consider is how the performance of this technique measures up. In debug builds, it can be a little ugly, but optimized builds strip away literally any substantial overhead of the templates. So runtime performance is fine, but what about build times themselves? Admittedly this does require a lot of templates going around. But the hope is that you’re reusing simple and composable components, not huge swaths of logic. So it’s easy to go wrong here if you don’t carefully consider what to apply this trick to. Used judiciously, however, it’s actually a bit better of a deal than defining a lot of shared abstract interfaces to decouple your APIs. I’ll go into the specific considerations of the actual callback system later. For now, I hope the peek at policy-based decoupling has been useful. Remember: three examples or you don’t have a valid generalization!
    View the full article
    • 1 comment
  • First Mine Seeker Demo Ready

    By HunterGaming

    I am finally ready to release the first demo for my next game Mine Seeker. I ran into a bunch of issues with gitlab, which I was using to host my code. They did an update and I lost the repo for this game. Thankfully it hasn't been released yet so I was able to create a new repo and migrated the code and issues to the new repo. Then I ran into issues pushing my code up to gitlab. I was unable to resolve that so I made the switch to Perforce. I've never worked with it before so there will be a bit of a learning curve as I go, but I have it set up so I can change files and submit them to the depot. I lost about a week maybe 2 because of this. On to a brief overview. The game play is similar to Minesweeper. You have to click tiles and try to avoid clicking on a mine. The first area of 20 levels is available in the demo. I plan 8 more each with an increasing level of difficulty to make it harder as you play. If you click on Quick Play you will be able to choose your difficulty and a game screen will be show. The Quick Play is similar to the original Minesweeper except there is no time or scoring. Clicking on the Play button will load the single player adventure with (eventually) 9 areas of 20 levels each. So far I have 1 area with all 20 levels.    Choosing the Play button will load the level selector screen. Each area is divided into 2 sections. This shows the second section of the first area so these are levels 11 through 20. The next and previous buttons will take you to the next and previous worlds if available. Click on a blue level button and the game will load. If the button is grey the level has not been unlocked yet. You must complete a level before the next one is unlocked.    Here is a quick look at the game screen. The buttons I think are fairly self explanatory. The score of the game starts at 1000 and decreases over time plus you get 1 point for every tile uncovered. It tells you the number of mines remaining as well as how much time has passed since the game started.    So because of the git issues I currently only have the windows demo available. I will add the Mac version as soon as I figure out how to get my Mac to connect to my Perforce server to checkout the code. If you have any suggestions, ideas, comments or issues of any kind let me know. You can either comment on this post, email me at support@hunter-gaming.com or contact me through my website. See my next blog post for an updated demo.

Our community blogs

  1. HTML5_Badge_512-150x150.pngHTML5 opens up some great opportunities for developers and one of those is plugin development using JavaScript.

    While most Corona developers will only use Lua in a cross-platform manner like they are currently using, it’s super easy to add JavaScript features to extend your app.

    You need two things: a .lua file that tests to see if your platform is HTML5 or some other platform and the actual JavaScript .js file. If you detect you are an HTML5 build, then you require the JavaScript plugin, else provide default functions that prevent those calls from creating errors for the non-HTML5 builds. Consider this code:

    -- myplugin.lua
    -- Copyright (c) 2018 Corona Labs Inc. All rights reserved.
    local lib
    local platform = system.getInfo("platform")
    if platform == 'html5' then
        -- use native JS plugin
        lib = require("myplugin_js")
        -- wrapper for non web platforms
        local CoronaLibrary = require "CoronaLibrary"
        -- Create stub library for simulator
        lib = CoronaLibrary:new{ name='myplugin', publisherId='com.mydomainname' }
        -- Default implementations
        local function defaultFunction()
            print( "WARNING: The '" .. lib.name .. "' library is not available on this platform." )
        lib.set = defaultFunction
        lib.get = defaultFunction
        lib.addEventListener = defaultFunction
    -- Return an instance
    return lib

    If you’re on HTML5, it includes the JavaScript plugin. If not, it simply lets the app know the function isn’t available.

    Plugins have to have a unique namespace and that’s accomplished by this line in the .lua file:

    lib = CoronaLibrary:new{ name='myplugin', publisherId='com.mydomainname' }

    Obviously if you intended to publish this to the Corona Marketplace, or if you want to use multiple plugins in your code, the name needs to be unique. Change “myplugin” to a proper name. Then set publisherId to the reverse domain name you use to publish with. For instance, Corona Labs made plugins would have a publisherId of “com.coronalabs“.

    Then you create a plugin with the same name except with an _js as part of the name. For instance if your plugin is “awesometimer.lua“, you would create “awesometimer_js.js“. This file will contain your JavaScript code. Here is an example:

    // myplugin_js.js
    // Copyright (c) 2018 Corona Labs Inc. All rights reserved.
    // JS plugin is an child object of 'window'
    window.myplugin_js =
        // all the 1st-level functions are available to call from Lua
        // so 'get' and 'set' functions are available to call from Lua
        // function may use up to 10 args; use Object or Array if you want to pass more than 10 args
        // arg maybe a Number, String, Boolean, Array or Object
        set: function(bool_arg, number_arg, string_arg, table_arg, array_arg)
            console.log('js set() is called');
            var data = window.myplugin_js.data;
            data.bool_arg = bool_arg;
            data.number_arg = number_arg;
            data.string_arg = string_arg;
            data.table_arg = table_arg;
            data.array_arg = array_arg;
            // Lua callback
            // you can pass to Lua a Number, String, Boolean, Array or Object args
            this.dispatchEvent({ name: 'onData', data: {
              arg1: bool_arg, arg2: number_arg, arg3: string_arg, arg4: table_arg, arg5: array_arg
            console.log(typeof(array_arg), array_arg.length);    
        get: function()
            var data = window.myplugin_js.data;
            console.log('js get() is called', data);
            return data;
    console.log('myplugin_js is loaded');

    We of course can’t teach you JavaScript in this tutorial and there are plenty of examples on the Internet to see. The main point is that you add your plugin to the JavaScript window object, provide your functions as part of the plugin namespace and add your methods to your plugin object.

    Then in your .lua modules, i.e. main.lua, you can require the plugin and call the functions as necessary.

    -- main.lua
    -- Copyright (c) 2018 Corona Labs Inc. All rights reserved.
    -- A sample of using JS native plugin for Corona
    local widget = require( "widget" )
    local json = require( "json" )
    local myplugin = require("myplugin")
    local label = display.newText( "output", 50, 220, native.systemFont, 16 )
    label.x = display.contentCenterX
    local data = native.newTextBox(160, 360, 320, 250)
    data.isEditable = false
    -- JS event listener.
    local function pluginListener( event )
        local str = json.prettify(event)
        str = 'got event from JS plugin:\n' .. str
        data.text = str
    local setData = function()
        -- call JS native plugin
        -- arg value maybe boolean, number, string, table
        local bool_arg = true
        local number_arg = 123
        local string_arg = 'abc'
        local table_arg = {key1='key1value', key2={1,2,3}}
        local array_arg = {1,2,3,4,5,6,7}
        myplugin.set(bool_arg, number_arg, string_arg, table_arg, array_arg)
    local getData = function()
        -- call JS native plugin
        local tbl = myplugin.get()
        if tbl then
            local str = json.prettify(tbl)
    -- Important: use index-debug.html if you want to see print output
            print('Data: ', str)
            data.text = str
    -- event listener, it's an option
    widget.newButton { onRelease = setData, left=60, top=60, width=200, height=50, label = "Save Data in JS", labelColor = { default={ 1, 1, 1 }, over={ 0.6, 0.6, 0.6 } } }
    widget.newButton { onRelease = getData, left=60, top=120, width=200, height=50, label = "Read Saved Data", labelColor = { default={ 1, 1, 1 }, over={ 0.6, 0.6, 0.6 } } }

    This example shows you how to call functions to get data, set data as well as dispatch events from JavaScript back to your Lua code.

    You can download the complete sample project from our GitHub repository. If you have questions please reach out on our HTML5 forum!

    View the full article

  2. Hey guys,

    The sixth devlog is here. Today I want to demonstrate another experiment with post processing filters. New Whitish mode will be available in the main menu. The player can choose Toxic mode or Whitish mode as alternative to the standart Pixelated mode. I considered that it would be fun.

    So, here is the video:

    The main menu will look like this:


  3. 1.thumb.PNG.61ca574261400c241b602a9f29bd3ca2.PNG

    In Part 4 I will quickly go over the 2D prototype.

    You can see a quick 23 second video (so-so quality) here showing movement, and how the monsters chase you (some move at different speeds for testing purposes), as well as the "animated" ice block sprite. In my actual game I'm using a Fixed Time Step with Variable Rendering, so my graphics are smooth thanks to interpolation. Sadly in these videos you barely notice any difference if I turn it off or on, and I wasn't able to make a good comparison video so I just left it on to showcase.

    (NOTE: There are no black bars in the game on the sides, the camera does not go outside of the level bounds, it's just the 'video' padding on the sides)

    I did plan on using different graphics for the tile set as seen in Part 3:


    But I decided to simplify the processes because it would take a lot time creating additional breaks, and nodes to connect the lines. I opted for just two textured blocks - I took a higher end versions and converted them to 2D:



    The ice block will freeze the Alien's skin allowing you to touch them and shatter them which will cause them to reset.


    This also got converted and animated to 2D:



    As of now the following works:

    Level Setup, Player Movement (With gliding - no stopping unless directly moving into a wall - you can also hold up and still glide in the direction (left or right) until it's available), Collision, Enemy path-finding + full movement, and Ice Block with animation.

    I still need to complete the following:

    - Main Menu

    - Top Menu

    - 2nd Player

    - Power Orbs to Collect

    - Lives + Ice Block Effect

    - Background with stars, or something so it's not just black

    - Audio

    I would like to animate the player a bit, and Aliens if I have time as I'm pretty busy this month.

    I hope you enjoyed Part 4, I'm looking at finishing the project this weekend with a final update - Part 5. :)

    If you've missed any of the earlier parts, check below for the links:


  4. We are small indie studio from Ukraine focused on Soulsmith card game creation. In this article we would like to share our experience of testing early paper prototypes and what we have learned from it.

    The reason why you need a paper prototype is quite obvious and well-known by every game designer - creating a test build requires a lot of time and efforts. Testing small balance changes is not a big deal even if you have to prepare a new build. At early development stages, on the other hand, you can't afford spending a significant amount of resources every time you need to test something fundamental, especially if you are an indie developer.

    As Jesse Shell stated in his wonderful "The Art of Game Design" book, it's quite possible to make a paper prototype even for a first person shooter. Fortunately, if you are making digital card game you won't need one person for each character. You'll need quite a few things:

    1. An IT geek and a gamer (that's me);

    2. A bunch of MTG cards from good old days;


    3. Deck protector sleeves and pieces of paper with some weird symbols and numbers;


    4. Another addicted card game fan (that's Anna);


    5. Old magnetic "Almost Every Desktop Game In 1" (or something similar) set;


    6. Some dices and coins;


    7. Woolen handmade whale (optional).


    That's it, you are all set and ready to go! BTW, things may escalate quickly. These red dices on my cards are damage counters and I'm not happy about it.


    Still, hope never dies. Especially if it is supported by battlemages on one lane and a firewitch covered by an armored knight on the other!

    You see, you can easily test core mechanics with paper prototype of your digital card game. Just don't forget to make additional notes when you test the main idea or solution as you may forget them later, trust me.

    When your prototype is mature enough, it's possible to literally play the game you make. We learned that it's very useful to play your prototype a lot even if it's (almost) final. Playing your game by yourselves, inviting friends to a pizza party and playing together, trying to find new sneaky strategies and super strong combos - everything helps in finding hidden issues in your gameplay. Difficulties with ending the game when one player is far ahead, lack of comeback mechanics in certain situations, dumb dominant strategies, stalemate scenarios, and many other nasty things can be found only after dozens or even hundreds of playing sessions if your game is deep enough. It's better to find and solve core gameplay problems in a paper prototype and not when everything is coded.

    Last but not least. After months of playing final prototype, when you become an expert in your own game and if you still love it, you can hope that players will also love the game. That is why you make it, at the end.

    P.S. Including a couple of links for those interested in who we are and what we do:

    • 1
    • 0
    • 39

    Recent Entries

    One thought you might have when hearing "LED Cube" is: What use are the LEDs in the center? Are they even visible, or are they covered up by all of the other LEDs surrounding it?

    They are. That's why it's preferable to choose LEDs with small housings and space them as far apart as possible. The "empty space to LED ratio" needs to be as large as possible.

    After searching multiple LED suppliers, I found that the smallest viable RGB LED is 5mm in diameter, with pin lengths of 25mm. To get an idea of what the cube might look like and also to figure out how the LEDs should be connected to one another, I decided to model the LED in blender. I came up with the following layout.


    It would be impractical to address all LEDs simultaneously. This would mean having 4096*3 control signals! I figured that the highest number of LEDs I would dare control simultaneously would be 768, which happens to be the exact number of LEDs in a single "slice" of the cube. In order to control all 16 slices, we use multiplexing: That is, we need to cycle through each slice repeatedly and apply the 768 signals for the active slice. If you do this fast enough, the human eye will think all of the LEDs are turned on.

    Knowing that ICs generally are able to sink higher currents than they are able to source currents, it is preferrable to use a common anode LED and connect all anodes in a cube slice together, making it possible to switch slices of the cube on and off with power transistors. The anode is the connection branching off to the right in the picture above.

    The 3 cathodes for controlling the red, green and blue LEDs in the housing are branched off downwards.

    The idea here is to chain the LEDs together such that the anodes can be soldered together like so:


    And by soldering these strings into an array, we get a single slice of the cube with all anodes connected to the same net:


    16 of these slices are then stacked on top of each other such that the cathodes align perfectly with the underlying layer and can be soldered together:


    The result is a structure that looks like this (using 4x4x4 here for clarity, things get messy to look at with 16x16x16):


    The 768 + 16 pins that end up sticking out of the bottom of this structure will be soldered onto a PCB. The number of signals can further be decreased by using shift registers (most likely I'll be using 32x 24-bit shift registers which will decrease the 768 signals to 32. This, an FPGA can handle).

    To finish things off, since this is blender, I rendered some pictures of how the cube might look in the end. Enjoy!



  5. We've finally finished a new game mechanic, 'Mag Blocks'.

    These blocks are magnetized and attract (Blue) or repel (Orange) the Phys-Blocks in the puzzle sections. They can either hinder or assist you, and can make some of the puzzles harder to complete.

    Initially blocks can only be pushed 1 tile at a time, but now as the puzzles progress, Mag Blocks will be placed as obstacles and you will need to figure out how to use them to help complete some of the puzzles. 



    Click the link below, to see a video of them working:



  6. Hi, everybody!
    Since the November 2017, we are working on our second game #TERRORHYTHM (TRRT). It makes us a great joy to inform you today that the game will be released on March 30th. So, get ready to meet the TERRORHYTHM (TRRT) - the music powered beat 'em up game.

    Check out the Official Teaser:

    Steam page - http://store.steampowered.com/app/752380

  7. This is a link to six barrel bill on Android, we would love to get some feedback on this so we can improve.



    Thanks in advance


  8. Latest Entry

    Change Of Plans:

    I decided to use Unity instead of my own personal game engine, Ignis Game Engine.

    I made this change because I believe Unity will alleviate some stress in the development of the game.

    In addition, I am convinced that I finished the 2D system interface for the Ignis Game Engine; however, the 3D system implementation

    will take some time to complete.


    Good Start:

    I am excited and nervous at the same time when I started developing this game, Iron Age Stories.

    On the other hand, I managed to create a Sand-Box scene with a prototype coming together.



    What's Next:

    The next step is to tread carefully and plan accordingly on how I can succeed in this project.

    I did create a TODO list for the prototype to keep track of my progress; however, the list keeps growing.

    I can feel the stress already but I can spread the work into smaller pieces to determine the work load.


    Thanks for reading and happy coding!




  9. Hello there!

    So obviously I have submitted my game to the jam. I even changed the title slightly again (added the "Twin" word), because I can! :)

    Anyway, the cover mechanics that I started working on during the jam looks pretty interesting, so I decided to progress further with this idea, even though the jam has already ended.

    First of all, I added some more visuals to indicate that a character is hiding themselves behind a cover:


    Additionally, I have fleshed out the cover system, making it more similar to the one from XCOM. Basically it does not rely on a simple line-of-sight mechanics, but also implies that a character might be able to lean to actually hit the target (which might be leaning as well):


    Player on the left is able to hit the enemy even though there is no direct line-of-sight. What is more, the hit probability is 100%, as the enemy is flanked.


    I guess the next thing to take care about is to make it more clear to the user what kind of cover (light/heavy) are the characters having. I will keep you posted on updates!

    Take care!

    • 1
    • 0
    • 71

    Recent Entries

    Latest Entry

    This is the first week of our Blog Entry.  We hope to update this weekly, if that does not happen forgive us, we are very busy.  We will certainly update when we can.  

    We are making this game as a family.  The game will be completely done by my Wife, 2 kids, and myself.  I will do all of the coding, as I have experience with this, and teaching my son along the way.  All of us will do the artwork and game ideas.  We are going to be sticking to pixel artwork as none of us are great artist and this is much more forgiving and fun to work with.

    The game is going to be an RPG game.  However it has heavy influences from games like:

    • The Binding of Isaac
    • Feral Fury
    • Wayward Souls
    • Space Grunts
    • Legend of Zelda
    • Among other greats!

    This will be a rouge-like RPG with permanent un-lockable's and upgrades.  The game is being coded in GameMaker 2.  We will be using other programs as well for the sprites and other pixel goodness.  At the current moment our target platform is IOS and we plan to make the game a free download.  This game will be completely self-funded. 

    Our target audience is anyone who likes playing Rouge-Like RPG's, like the games above, and of course anyone who has battled cancer, battling cancer, or close to someone that has.  This is going to be a kid friendly game.  We hope the game is played by kids and adults who are battling cancer, or have been effected by it, and gives them hope that they can beat the disease and live a healthy and long life.  

    The story of the game is influenced by my wife.  My wife is currently battling cervical cancer.  Throughout this journey we have come to realize there is not a lot of info on cervical cancer.  There is barely any awareness and we could not find any support.  Don't get us wrong there is a MASSIVE amount of support out there for cancer.  However we realized that certain cancers like lung cancer, breast cancer, etc. have there own support channels, as well as foundations for donations.  This unfortunately is not the same for cervical cancer.  We hope to help that.  

    With our website we want to curate all of the information we have gathered and learned on our own and from research.  We want to give a "one stop shop" for people that want to learn more about cervical cancer to come to the website and have all of their questions answered as well as learn more along the way.  We hope the game also helps promote that.  

    So with all of that said the game was more of a vision.  Something fun for kids to play, and more importantly something for our family to create together.  

    Current Status:

    • Main Character, my wife, sprite has been created.  This includes front, back, left, and right side. 
    • Main character has full movement, walking, and running animations. 
    • Main character also has collision set. 
    • Base room has been created for testing.  This is an empty room with just walls to test collision and the sprite animation. 

    What is being worked on in the current moment:

    • Building array's for inventory management 
    • more animations for attack and character rolling
    • more sprite creations
      • enemies
      • bosses
      • levels
      • props

    Will post some sprites here soon once I get them in a proper GIF.  

    Till next week, Thank you.




  10. Welcome to another weekly wrap-up on all things Game-Guru.  Things continue to shape up post-public preview v2 and we're seeing most of the artists develop a workflow around PBR assets which really add a level of depth and dimension pretty far beyond what Game-Guru has been known to do.

    Official Game-Guru News:

    Game-Guru now has a donation link for 3rd party development.  It's about time!  Remember, these monies won't go towards Lee & Company.  It will actually go for people who are doing contracted work outside of TheGameCreators to fix up long-standing issues in Game-Guru.  I've already put a few bucks towards it and encourage you to do the same to help reward those who are really getting this project moving again!

    In other news, the Easter DLC is also free so grab it while it lasts!
    It's also got some new models added so existing owners of it who bought it last year should have that in their inventory as well.

    Beyond that, work continues on the pending 'regular' release of Game-Guru.  Bear in mind beyond public preview editions, we have seen NO real updates to Game-Guru since May of last year.  That's quite a long time to wait.  So I think a lot of us are really hoping to see something magical though I think it's fair to expect we'll run into some snags as well.  Hopefully Lee and team are agile after the fact and fix whatever whack-a-mole bugs pop up.

    New Products on the Store:

    This week we're starting to see the current crop of PBR related assets coming forward as more and more artists get used to working with the new medium.  Some of this stuff looks really great!

    Most, if not all of these are PBR enabled.
    I noticed Mad Lobster Workshop's Mad Scientist Lair now has a second 'kit' to it which is an 'essentials/lite' pack.

    I love this brain in a jar, Mad Lobster!

    This is a good idea to corral the ever-expanding inventory and help break it out though I still would have made pack 1, 2, 3 instead of his method.  To each their own though. 

    Graphix's work on a playground set is really turning out nice, about time for us to get an updated one.  I have been using an older one for years and it's about time to update.

    Finally there's this way, way, way overpriced toilet from newcomer HomeWreckers Studio.  I mean I get it, everyone needs a good quality toilet for their games.  For the price though he's going to find it a struggle to sell this piece.  Probably.  My recommendation would be to offer it significantly reduced by itself (say $3.50) or include it much reduced as part of a pack.

    Free Stuff:

    This week there's not a lot going on.  I will say though Bod has been working on updating his assets for PBR and they look phenomenal.

    Though word in the winds is that a fix is coming to PP that will render a lot of his updates unnecessary.

    Beyond that we see some new stuff from Graphix (notably a cabinet) and  some free music from the probably very-hard to pronounce "eluukkanen".

    Third Party Tools:

    This week we got to see a glimpse of something REALLY cool.  A third party tool called "Game Launcher Creator".  This program really allows some impressive things such as live updates, notifications, a WYSIWYG editor, and more.   You can find info on it here: https://forum.game-guru.com/thread/219455 ... lots of potential in this one.

    Someone found a new PBR tool: https://forum.game-guru.com/thread/219467

    Random Acts of Creativity:

    This week Bugsy put up some new screenies of 'Direct Action 2' and it looks great.
    He's really getting a handle on GG's lighting and it shows:
    Great use of a dynamic (RED) light with lots of soft blue static lights.
    Also it's nice to see 'Len the Man' still working on his cowboy shooter game.

    In my own works:

    Sort of a lazy week for me.  I have a lot of life stuff going on.  Lately I've been playing Galaxy on Fire 3 on iphone, World of Tanks Blitz (iphone) and also Tera had an event for Male Brawler classes this weekend .. and I've been a founder in that since the dawn of time.  So not much going on.  Pounded out a few thousand words on the book.  Books are a process of constantly grinding out more material.  I did obtain licensure for a few more assets so that's coming along nicely.  I now have some custom models worth noting and am looking forward to revealing them as time goes on!

    Eventually the book will come with:
    A full set of level-building supplies (buildings, clutter objects)
    A custom character (enemy/npc)
    Custom Character Creator assets
    Custom weapons and more!

    I'm still looking for qualified artists.  Let me know if you have an interest in having some of your work included!

    View the full article

    • 1
    • 3
    • 89

    Recent Entries

    King Of Pirates


    Development Diary









    hello there my name is ROX and i'm a college student and i work on creating this game in my spare time

    this is not the first day for me working on this project (Actually it's been almost a year now),but it was today

    that i decided to start a diary(mostly to keep myself organised and to keep my mind from flying elsewhere) 

    and  also too show people what's going on behind the scenes.

    I don't have a lot to say about the game as it's still in a very early development stage ( almost a year in 

    development and still in an early stage 😁😁, Yeah I Know I'm Lazy)

    But i've decided to seriously start working on it from now on 😁😁



    I Think I've Talked ( Or Wrote ) Too Much For Today , In The Days That Come I Promise I'll Talk More About The Useful Things






    Farewell For Now










  11. Main characters concept art and rough in-game setup.


  12. Breakable object physics

    Let's talk about physics in the game. We will introduce breakable glass, door and wall to the game to make things not only more alive but also give you more choice about your path to reach each level goal. A building is locked down ? Maybe you just jump through a window to get in ! A door is lock and you haven't found the key ? Maybe you just blow that thing out of your way ! There's no exit ? Well crank your energy up and destroy that wall ! This is the kind of choice you will be able to do as long as you live with the consequence of making a lot of noise and attracting more attention to you and potentially increasing your awareness level. Remember that your global awareness is what make your next level harder and harder. Physics will allow for more interactive game play and better replay-ability. Let be honest to, when a game require you to keep a certain level of stealth, you will eventually want to go destroy everything and play careless so why not make this fun !


    Frag, IEM and Gravity bomb

    The player, depending on the active character, will have access to a limited amount of grenade. You get a sneek peak about it in the video below. Frag grenade will allow you to destroy glass, door and wall too. 1 character have access to frag, another one have electromagnetic device that will shut down most electronic device and the last one will have a devastating black-hole type of grenade that will serve as a way to grab item at a remote distance or to simply make things vanish in another dimension ! More to come on those soon !

    C# Break in parts

    Our script rely on unity internal physic engine, which is quite good. Physics can become very CPU intensive so a lot of testing will be required to ensure smooth gameplay. I don't intend to go to far away into destruction. This is not a procedural "red faction" destruction system ! So destruction will happen, but in a limited amount of location. Destroying everything to get through is NOT an option. That said, i'm happy with the script performance and how it work.

    Magnitude of an impact

    For of all, the script take into account the magnitude of a hit. If the hit is too weak, the object won't break. Each object have their own breaking point which me require to walk into, run into, shoot at it, trow a grenade or use a special ability.

    Parts physics

    Once an object is broken, it fracture into multiple parts. The glass in the example video is make of 160 rigidbodies and it still perform well. Each part take into consideration their surrounding. Depending on how many piece stick together, the script determine if the piece can hold in place. The system also check for "framed" part. For a window, the framed parts are the object around the edge that would be hold in place by its frame, for a door it would be the part connected to the hinge. Those part don't fall by them self since they are hold in place by another object. Those part need to be hit again to fall and each sets of broken part need to be connected, within a certain range, to a framed part to be considered structurally stable. Basically that mean that a broken part cannot float in the air if it's not link to enough pieces and that a large glass would break realistically even if you hit limited area because the weight and size of the part would make them fall in real life. Then again, this is not a fracture simulator and we can't go too far into reality. It remain a game, so the main goal is to have fun with the system and to have smooth gameplay. The focus is about the gameplay feature or having more choice, more path and more replayability.

    Explosion shock-wave !

    Each explosion in the game come with a shock-wave effect. The shock-wave, in my own unscientific terms, is the air getting compressed and the explosion expanding over time. That mean that an object closer to an explosion will get hit faster than an object located further. On top of that, we take into consideration the distance between the explosion and the object to determine the amount of force received by the affected object. Obstruction is also considered, if something explode and there is object between you and the explosion, you will receive less damage.

    The shock-wave introduce a very important time factor to the game-play. Making thing explode at a distance and have a split second to get out of the way may be a life saver for you or the AI.

    See and be seen

    The video showcase a turret being able to see you through glass and it shoot at the player destroying the glass. This behavior will of course be extended to AI but be aware that militarised zone or city will benefit from upgraded unit that may have heat sensor and a turret may just decide to kill you through a wall or a door if you are not cautious enough ! Soldier may also be equiped with those special google.  The game AI have nightvision and heat sensor to track you down. More to come on that in a futur post.

    Let me know what you think about the feature or share your though about current game that use physics such as RB6  ?



    After almost two years of grueling full time development the anticipated 2D RPG Towards The Pantheon has a release date of May 16th, 2018. While lead developer Connor O.R.T. Linning had been thinking of dates between April and June for quite some time, the date was solidified during a shower one morning and the Lagwagon song ‘May 16th’ from the legendary Tony Hawk’s Pro Skater 2 soundtrack began playing.

    Development of Towards The Pantheon started when lead developer Connor O.R.T. Linning collected a long list of RPG clichés and decided to avoid as many of them as possible while designing his game. Gone are elemental types, elixirs, elves, inns, and generic love stories. Instead players of Towards The Pantheon will ride hamsters, journey through a survival horror inspired mansion, collect dead memories, make new friends, and partake in regular chats around the campfire. Artist Leandro Tokarevski joined soon after to create the pixel art for the entire world using a palette of only 16 colors resulting in a vibrant and distinct world full of charm.

    Towards The Pantheon follows the journey of Freyja the warrior, Bam the cat, Mishima the electropunk, and Phenez the ghost as they strive to defeat the source of a malevolent regime The Sworn Light at The Pantheon. To make the gameplay of Towards The Pantheon more unique, elements of adventure and survival horror genres have been implemented. The standard HP/MP system for party members has been altered so that every character has their own stat system. For example Phenez the ghost only has Necropoints which means that he must hurt himself to be able to attack, and Bam the cat has Energy Points which are restored by snoozing or using catnip.

    With a world containing over 10 distinct regions to explore, 45 enemies to battle, 80 soundtrack songs to experience, hundreds of items to collect, hundreds of NPCs to interact with, and over 15 hours of gameplay, Towards The Pantheon is the unique type of game for those looking for a new and fresh adventure.

    In October 2017 the horror/mystery themed prequel game Towards The Pantheon: Escaping Eternity was released for free and received an 89% positive score on Steam. The game was praised by reviewers and streamers for its original premise and dark atmosphere.

    Towards The Pantheons release date of May 16th also brings lead developer Connor O.R.T. Linnings journey full circle. 15 years ago he spent his time at school creating an episodic pixel art story accompanied by trading cards that he distributed among his friends named ‘May 16th’. Now at age 26, he’s bringing that same love and dedication to storytelling and game development to Steam, Itch.io, and Gamejolt. Towards The Pantheon can now be added to your Steam Wishlist! http://store.steampowered.com/app/709510/Towards_The_Pantheon/

    Press Kit: http://www.towardsthepantheon.com/index.php/press-kit/
    Steam Page link: http://store.steampowered.com/app/709510/Towards_The_Pantheon/
    Website: http://www.towardsthepantheon.com

    Social Media Links:
    Facebook: https://www.facebook.com/TowardsThePantheon
    Twitter: https://twitter.com/PantheonDev
    Tumblr: http://towardsthepantheon.tumblr.com/
    Reddit: https://www.reddit.com/r/TowardsThePantheon/
    Instagram: https://www.instagram.com/towardsthepantheon/
    Twitch: https://www.twitch.tv/connorort
    Google+: https://plus.google.com/u/0/114060823024573957788?hl=en
    Indiedb: http://www.indiedb.com/games/towards-the-pantheon

  14. Oops,today i'm so sad.

    Because our computer classroom was requisitioned because of the "THUSSAT" examination.

    And i have to move my projects to our e-book lyceum , and there's no Visual Studios installed.

    Perhaps i have to pause my project for one day.



    Hope it won't take too much time.

  15. This week I want to give you some technical insight into our project.

    I want to start with recapping what happened over the last week: The player movement for the cell stage is implemented and the GUI is wired up, too. There is now a health-bar, DNA-bar and you can see your current compounds as well as your compound balance.

    Currently I'm working with or rather exoerimenting with Unreal's UProceduralMeshComponent. My main goal is to create a mesh I can manipulate on runtime. The first thing I want to use it for are the compound clouds. When the player swims into them they should bend around him as if they were being absorbed while simoultaniously decreasing their value until it reaches 0 and the dissovle completly.


    Once I'm familiar with how this class works I will use it for the creature editor. So far it's the best thing I know of for creating meshes that can be generated on runtime. 

    Currently I'm struggeling with writing an algorithm that creates a mesh that roughly outlines the shape for the compound cloud and mostly acts as a trigger and the bounds for the simulated clouds. On that point I discovered somethin you might be interested in this topic: 

    So far I haven't tried it but it looks exactly like the thing I need for this.


    And something special: Version 1 of the Lyfe Main Theme is done. (Lyfe_Main.mp3)


    That's it for this week. I want to focus on the cell stage for this devblog as long as I'm working on it. This might result in shorter entries but we want to keep you up to date.


    We're also still looking for people to join the team if you're interested.



    I managed to create an actual cube with a procedural mesh



    UPDATE 2:

    We go some actual random shapes that will later function as the outline for the clouds.


  16. Latest Entry

    Good Morning everyone! I had to take a bit of a break from school/weekly goals to attend to some issues but I am back on track this week with another goal I have set for myself! I will say I love writing this in this blog. Its a great way to stay accountable. My goal this week will be to start working on learning C#. As I have mentioned in other/previous posts I am still new to all of this. I will say what I have learned so far has blown me away. I never knew how interesting all this was until I started doing it! Since I am going to be doing a bit of traveling this week it was recommended to me to download an app called Sololearn. Apparently it is a good way to get learn on the go. I'll update on my impressions about this app shortly :) 


  17. Refining the tutorial was probably one of the hardest part of the "later development". Everything was in place, but how to teach the player how to play the game was still a struggle.

    The first time somebody tried my game, he was 15 minutes on level 1 and he couldnt even solved it. So this was a major issue. The game evolved from a "this is a full level, here are the controls, good luck", to "this is a much limited level, lets try the first feature first and will see how we go".

    The things that helped me:

    1. Limiting number of limbs.

    On the original first level, you controlled all 4 limbs + head of the character. That was brutal for a first timer. Understanding how physic works on the character is not easy. So I changed that to only 1 limb, and the character starts tied up to a chair. You have to limit the degrees of freedom that you offer the players.




    2. Explaining the movie, the poses, and how do they work.

    Although the concept of a timeline is easy to understand now that everybody browses youtube, keyframes and poses needed to be explained. I tried explaining the bare minimum because I don't want to overwhelm the player on the first level.



    Explaining that a pose is what make the difference in the movie.




    3. Slowing down the player

    Although it may seem weird, sometimes you have to slow down the player so they dont hurt themselves. At first, just standing on some point in the timeline and moving the character would create a pose. Very fast, very simple. Except that it lead to players creating poses everywhere, anywhere. Not realising where they are standing, and not giving importance to the appropiate time.

    I had to slow them down, asking them to create the pose manually.


    This simple creation with a button made the player pay attention where the pose was, and at what time was the movement happening.


    4. Teaching by doing, not just showing.

    This is quite straight forward, but players learn a lot more by doing the actions than just reading about them. In this case I showed an animated example of what the player was suppose to do, and waited for the player to do it themselves.



    5. Gameplay before story.

    I'm pretty sure some writers may hate me, but I was willing to destroy the story if that meant a smooth gameplay/learning curve. One of my biggest fights with players was gravity. It was not easy to teach someone to move and jump, beacause... well... most people don't realise "how" they walk, they just walk. And when they have to pass that expertise to a dummy character, they struggle becuase in their mind is just automatic. It's like tryin to teach a kid to tie their shoes. You just do it, and you would have to analise step by step just to make it work.


    Original first level. Gravity can be a bitch.


    In my case, the fact that gravity was such a hussle to overcome, I couldn't add it in the first levels where players were just getting the grip of the game. So I moved my story to space, and then to the moon, were gravity is lower. After several level then the player lands on earth and the gravity challenge appears. Does it make 100% sense as a story now? No. I tried to fit the changes in to the story, but the realism of the story is a little stretched out now. I'm not gonna win any writing prize for it. But I haven't received any of the complaints and struggles I use to see from new players. 


    After refining the tutorial several times, I haven't received a single complain about no understanding the game. Some people still don't like it, that acceptable, but at least now everyone gets to evaluate the game other than "too confusing".


    I hope my mistakes help you out a bit in your tutorial. Cheers.

    If you want to know more about the game: Posable Heroes on Steam

    • 2
    • 2
    • 130

    Recent Entries

    Latest Entry

    Morning guys!

    Today I'll talk about some of the content in my game. Right now, it's still in early development, and I'm the only active artist on it right now. But I'm working on multiple aspects of it at once every day, so we're definitely making progress. Any default art you see from RM (rpg maker) will of course be replaced with my own. I'm designing maps first in RM then replacing the tiles I use afterwards. 

    This screenshot was taken not too long ago, where you can see that the majority of the tiles are the (hopefully) finalized art. I went with a clean, simple shading for all of it, with usually no more than three shades of the same color. The border for the text box is our own, though the color may change depending on what changes we make to the gui. There's also the character art of Marie of which I did myself, and is the template style for the rest of the art in the game. 


    Speaking of Marie, here's some emotion character panels!


    Here's some of the tiles I've been busy with, replacing defaults with these. I have 100+ items scattered around 4 or 5 sheets, but this ones the most cohesive. 


    Here's one of our Void monsters, the Caterwaul. It's one of the antagonistic creatures that show up at night and it spews a deadly energy concoction known as Osu. 

    Here's the World Anvil article for it with full sized digital art. 


    This is the Frostbite, also with its own full sized art and article.


    Here's some more creatures with full art, but no pixel art yet. Each of these has an article on my World Anvil Worldbuilder.


    And that'll be it for today- juts wanted to show you guys some of the work I've put into it so far. Once more tiles are finished, I'll record a video of some game footage to show some of the things I've already implemented. For now though, thanks for taking a look! 


  18. I'm a man on a Mobile Gaming Quest (MGQ) to play a new mobile game every day, documenting my first impressions here and on YouTube. Below is the latest episode. Here's a quick overview of all games I've covered so far.

    A visually stunning auto-run side-scrolling platformer (just like Rayman: Jungle Run) with great humor, a high difficulty level, awesome slow-mo explosions, and insane weapons.

    There are no annoying forced ads (only incentivized ads to get double gold after each run), and the in-app purchases are never needed. 

    Honestly, I feel like this has game-of-the-year potential - at least for its genre! 

    My thoughts on Lost Socks: Naughty Brothers:

    Google Play: https://play.google.com/store/apps/details?id=com.nerfgame.lostsocks.LostSocksActivity
    iOS: https://itunes.apple.com/us/app/lost-socks-naughty-brothers/id1074889855?mt=8

    Subscribe on YouTube for more commentaries: https://goo.gl/xKhGjh
    Or join me on Facebook: https://www.facebook.com/mobilegamefan/
    Or Instagram: https://www.instagram.com/nimblethoryt/
    Or Twitter: https://twitter.com/nimblethor

  19. The new sprint starts today. We've done a lot during the last 4 weeks!

    We deployed the game on our mobile phone and fixed some bugs. Charly Clearwater is looking good in UE4 now! All his textures and maps look fine. All his animations run fluently.

    He's now able to walk and run when reaching some defined speed limits. (Blueprint)

    He is also able to recognize a stair and to use the right animation when climbing upstairs or downstairs. (C++ and Blueprint).

    Clearwater can now pick up objects from the environment and can save them in an inventory. (C++ and Blueprint)

    For the new video, the main-character Charly Clearwater must also learn to shoot in all directions when a button is pressed. A topic for the current sprint.

    Another thing is the game controller. We want to make it easy for the player to move the character, to open the inventory, for example, we want to make it easy to interact and play (on the mobile phone).

    For that reason, we'll integrate a simple game controller, that is to use and to learn as easy as possible. Simple HUD's will stay in the background, won't disturb the player, but will be there when necessary.

    The player will get introduced to these elements during the first scene of the game and can use them later whenever he needs them.

    The new video is going to happen in his apartment, the first game scene. The place where the player is going to learn more about the character Charly Clearwater himself, more about how to play him, how to handle the game elements and the game controller, etc.

    Plus, the apartment is still incomplete, so we need to model a lot of furniture and objects during this sprint to finish both the videos location and the first game scene.

    Why the new video? We want to show you what kind of game BIZARRE is. Who main-character Charly Clearwater is. And what kind of quality the game is suppose to have.
    Call the video "Get to know BIZARRE". :-)

    That's our plan for the next 4 weeks.



  • Advertisement