How to Fund Your Indie Game with Bitcoins and BitConnect

Funding a game

There are plenty of ways in which one could fund an Indie Game. Most of them require third party investors (Indie Fund), backers (KickStarter or IndieGoGo) or patrons (Patreon). You could even try the good old donation route (GoFundMe). Obviously you need a good idea, a well structured project and a business plan. You need to convince others that you're going to deliver a great game!

Those are all fine ways to fund your next indie game and they all share a low risk profile (at least for you, the developer). Low risk is desirable for most indie game developers, most of the time.

But then there might be another way. A very risky but potentially profitable one. One where you don't actually need to ask others for their money (given you have at least a small initial amount of money): Bitcoins and bitconnect!

Why would you want to do it?

You don't! In fact the very high risk profile of this kind of investment kinda makes it look like betting. You basically bet that the price of Bitcoins will keep rising.

Bitcoins and the underlying technology (the Blockchain) are spreading faster and faster. Banks, financial institutions and big names such as IBM (even the European Union itself) are looking into ways to invest in these technologies.

I don't care about the blockchain. I don't believe in the future of Bitcoin as a legit currency becoming legal tender. I just wanted to jump in for some quick profit. And so I did, this summer, investing a small amount of money in Bitcoins. And I got lucky.

I am still making profit but I got all my initial investment back, safe into my bank account. So in case this bubble blows up (and it will), I haven't lost anything but time (and actually gained some money in the meantime anyway).

Where do you get bitcoins?

You can buy Bitcoins with real money (bank transfer or credit/debit card).

It all starts with Coinbase or Litebit.eu. I usually buy Bitcoins from LiteBit via SEPA bank transfer. It takes up to a week for them to deposit the BTCs. Given the daily volatility and fluctuations of the BTC, whenever I need them immediately, I use Coinbase, which accepts credit and debit cards, effectively getting me bitcoins instantly.

Both of these websites require thorough verification of your identity, phone number, bank account and ID documents. If you don't feel comfortable giving away your details, don't use these services.

Earning 30% to 40% monthly with Bitconnect

BitConnect is another shady beast. It's a coin (the BCC) and an investment platform (or an elaborate scheme) working with its own coin.

Basically you deposit your BTCs from LiteBit or Coinbase (or wherever you keep them). Then buy BitConnect Coins (BCC) (they have an internal exchange for that) and then supposedly "lend them" to a trading bot which pays you back a daily profit of around 1%. That's around 365% yearly.

As I said the profit is daily. It means that they pay out every single day. And you can withdraw that profit.

Actually there's more. In fact you can re-invest that daily profit back into your initial lending to get back a compound interest (or lose all your money if the bubble bursts).

All this lending and profit is calculated in US Dollars (even if you'll be using your bitconnect coin balance). So if you invest, say, 1010$ for a minimum period of 239 days, you'll get paid around 1.1% daily... which means around 11$ each day (or 333$ monthly). Not bad.

It's working pretty fine for me and I have nothing to lose if it all goes titsup.

Personally I believe this platform will last until Bitcoin will last. The reason behind this is that it seems the bitconnect coin mimics the performance of the bitcoin. So as long as people believe in bitcoin, the bitconnect platform should keep on paying lenders their interests.

What to expect from bitcoins and bitconnect?

No one knows. This bubble will burst. We just don't know when. I'm trying to make some profit while I can and I reckon this is not the preferable way to fund a game dev activity, but it's the only one I could think of where I don't need to ask money to anyone. I own my money, I don't need to show my game to anyone and I manage my own schedule, features, work hours and whatnot. I take all the risks, with all the gains and all the losses. It's like a game... about funding a game... it's a bet.

Until it lasts, I'll have a sort of passive income.

Ok, you made profit... now what?

Same process in reverse:

  1. you should sell your bitconnect coins (BCC) for bitcoins (BTC) at current market price (at the bitconnect exchange).
  2. withdraw your BTCs and deposit them on either LiteBit or CoinBase.
  3. Sell the BTCs for Euros and cash in on your profits.

Let me know about your experiences or if you found a better way to generate passive income while you work on your game.

BTW if you want to donate BTCs, here's the address: 1Fd7tYv7jm9M8NGYzcSdmpFT4YR82oS7zF

Fuzeboy – Status Update – [9 AUG 2017]

As some of you might know, Fuzeboy’s project scope changed considerably during its development. There’s been an overhaul of features, specifications, goals and deadlines.

A small mobile game…

Originally thought to be a quick mobile only game, we then shifted our vision a bit to make it playable on desktops as well; now we decided to abandon the mobile world altogether to focus exclusively on the Desktop platform.

This opened up a ton of possibilities as we’re not limited to touchscreen inputs anymore. The very essence of the game changed, as we made changes to game mechanics, enriching and expanding the world of Fuzeboy.

This is the tower with the locked doors… very mysterious…

Fuzeboy’s going to be a full fledged, complete platformer game for desktops (Win, Linux, Mac) but we’re not yet ready to show anything new to the world as I’m rewriting it from scratch in GameMaker Studio 2 while Darftey is reviewing (and adapting) all of the graphics.

We’re also starting a new project. Not because we suffer from shiny object syndrome (basically a disease of distraction) but because rewriting Fuzeboy from scratch, made it possible for us to reset our mental state.

Although far from a possible Fuzeboy-induced burnout, our mental state was then set for something new; different. That not only applied to Fuzeboy, but to both of us as a game development team. We took a step back and looked at our future as team Blocksword. And we saw things…

As we reviewed and re-started Fuzeboy, we reviewed our plans, projects and priorities as well. And we saw this…

Here’s a small teaser GIF

Due to the overwhelmingly positive feedback we received, we’re now thinking about making it our primary focus. We’re also considering funding as I didn’t plan to live off of my savings for this long without publishing a commercial title.

Two projects, two options

Should we decide to crowdfund the new game, we will have to define a clear project scope and commit exclusively to that for the time it will take to ship it. In that case the development of Fuzeboy will be put on hold (let’s say we will change it’s queue priority). As of now this is the most probable scenario.

Should we decide to keep going without funding (or fail at funding), we’ll suffer from a bit of a slowdown. I will have to seek a part-time job (or something) while working on both games at our discretion (we would have zero deadlines and relatively more freedom in the way we manage and evolve our own projects).

All of this might annoy someone; especially those who were waiting for Fuzeboy anytime soon this year. Especially if they were waiting for a mobile game. We know it and we don’t like when people get annoyed because of us; we will make up for it.

In conclusion

To sum it up: we’re working on the new Fuzeboy while defining the scope of this second project and defining the resources we need to allocate to each of these projects. Just know that we could completely shift our focus toward this new RPG game very soon (we’re evaluating feedback).

Fuzeboy is now being made in GameMaker Studio 2

Yet another official announcement: Fuzeboy is now being rewritten in GameMaker Studio 2.

After getting familiar with the new UI and the new GML functionalities, I’ve realized it made little to no sense at all to keep using GM:S 1.x. I’m already rewriting Fuzeboy from scratch so I might just use the new, improved IDE. I need a faster workflow and GameMaker Studio 2 definitely improves the workflow.

Coding with the new intellisense code-completion and making levels in the new room editor is just fantastic.

Since I’m working on a 1366×768 13″ notebook, I set the DPI scaling of GMS2 to 80% (76 DPI) so it doesn’t feel claustrophobic working in it.

I already feel better when coding Fuzeboy in GMS 2.

Fuzeboy – A new beginning

Me and Darftey have been developing Fuzeboy for five months now. We met in late Novemeber 2016, experimented a bit with prototypes and then started serious development in January 2017.

It was small… it was cute… it was mobile…

It all started as a small mobile game (you can see the touch controls in the image above) but soon it was clear Fuzeboy was no small game anymore; the mobile world isn’t fit for him. He’s bigger than that.

This is the tower with the locked doors… very mysterious…

So here we are today officially announcing to the world that Fuzeboy will be developed uniquely for Steam (PC, Linux and Mac). A mobile adventure of Fuzeboy is still being planned but we’re not actively working on it (and it will be a different game).

In fact I am rebooting the development of Fuzeboy. From scratch. Still, I’ll be using GameMaker 1.x but this time the whole project will be PC oriented. We’re letting go of the many mobile limitations to expand on the gameplay mechanics.

While I’m starting to rewrite the engine from scratch, Darftey is already at work to come up with exciting new elements and ideas for the game. It’s going to take time and effort. It’s going to be exciting. It’s going to be big.

How I Scale Fuzeboy Resolution on Mobile and Desktop Devices

Fuzeboy's still in development so it's only natural that sometimes I take time to rewrite stuff, to fix things, to experiment and so on. We try, we break, we fix, we extend, we change. We evolve.
A scene from Fuzeboy. There's only one way to view pixel art... and that is with pixel perfect scaling.
One issue we faced from the start, is the game resolution. What we knew was that we wanted pixel perfect scaling no matter what. Remember that this game will be both for mobile and desktop.Here's my solution as of today.

The Ideal Game Resolution

Fuzeboy cares about its height. The width depends on the monitor aspect ratio (within reasonable limits). The ideal height of Fuzeboy is around 240px. Keep this in mind.

Pixel Perfect, Full Screen, No Black Bars (didn't work)

This approach was the first I used. Since not every device has a vertical resolution that's a multiple of 240px, I allowed different devices to show more or less "game world".First I get the display vertical resolution. Then I cycle from 200px to 300px to see which one fits perfectly the device vertical resolution. If I don't find a perfect fit, I give up and just use 240px.

Fuzeboy on Devices, method 1

DeviceResolution (vertical)Game Vertical ResolutionMultiplier
Amazon Kindle Fire 7"1024 x 600 (600)3002
Samsung S3 Mini800 x 480 (480)2402
Asus MeMO Pad 71280 x 800 (800)2004
This doesn't work. It's pixel perfect most of the times, there are no black bars... but you might end up seeing an unplayable 200px vertical resolution on a 7" tablet.
We don't want this to happen... do we?
Let's have a look at an Amazon Kindle Fire 7"
This is better. Or... is it?
There's a huge 100px difference in height from the Asus to the Kindle. The Fire users would have been able to see 50% more game world than the Asus players. That's wrong. Especially since Asus has a higher screen resolution than the Amazon Fire.

Pixel Perfect, Black Bars (in use as of today)

First of all I decided to restrict the range of vertical resolution of the game. Now it's from 230px to 260px. Still a 30px difference but it's bearable.So I still ask for the device vertical resolution, of course. Then I check which number, from 230 to 260, fits best. By that I mean it either fits perfectly or has the lowest remainder.This is the initialization script. It goes inside the create event of the very first object created in the game.I also leave the view settings in the room editor as they are. Disabled. I enable them via code.
///scr_init_display()

// Let's disable the drawing of the App Surface
application_surface_draw_enable(false);

dw = display_get_width()        // Device Display Width
dh = display_get_height()       // Device display height
ar = dw / dh                    // Aspect Ratio

min_h   = 230                   // Minimum Height
max_h   = 260                   // Maximum Height
height  = min_h                 // We start from the minimum
fract   = frac(dh / height)     // This is the fractional part
mult    = floor(dh / height)    // This is integer multiplier

// We cycle from min_h to max_h
for (var h = min_h; h < max_h + 1; h++)
{   
    var new_fract   = frac(dh / h)
    var new_mult    = floor(dh / h)
    
    // If we have a lower remainder, we store
    // the multiplier and the height we're testing
    if new_fract < fract
    {
        fract   = new_fract
        height  = h
        mult    = new_mult
    }
}

// This will show you the found resolution in the debug console
show_debug_message("Found resolution: " + string(height))

// Width gets decided with a simple division
width = floor(dw / mult)

// And made divisible by 2
if width mod 2 != 0
    width--

/***************************************************
  SET THE VIEW AND THE PORT FOR ALL ROOMS
 ***************************************************/
var i   = true;
var rm  = room_next(room);
while (i)
{
    room_set_view(rm, 0, true, 0, 0, width, height, 0, 0, width * mult, height * mult, 0, 0, -1, -1, -1)
    room_set_view_enabled(rm, true)
    if (rm == room_last)
        i = false
    else
        rm = room_next(rm)
}

// Resize the application surface
surface_resize(application_surface, width, height);

// Let the GUI layer be as big as the device screen
display_set_gui_size(dw, dh)

gw = display_get_gui_width()    // GUI width variable
gh = display_get_gui_height()   // GUI height variable

// We'll need these to figure out the touch commands coordinates
wscale = width / (dw / mult)
hscale = height / (dh / mult)

// Let's figure out the App Surface offset (we want it centered)
Xoffset = floor((dw - (width * mult)) / 2);     // Horizontal Offset
Yoffset = floor((dh - (height * mult)) / 2);    // Vertical Offset

/// Go Fullscreen on desktop
if os_type == os_windows
{
    window_set_fullscreen(true)
}
Then we need to draw the App Surface. So in the game controller object, I have the following code in a Post Draw event.
///Draw the App Surface with correct offset

// This line prevents strange artifacts in Fuzeboy.
draw_enable_alphablend(false);

// The real drawing.
draw_surface_ext(application_surface, Xoffset, Yoffset, mult, mult, 0, c_white, 1);
If I run the game on the Amazon tablet, the result is this:
The game now has a height of 260px

Fuzeboy on Devices, method 2

DeviceResolution (vertical)Game Vertical ResolutionMultiplierBlack bars top/bottom
Amazon Kindle Fire 7"1024 x 600 (600)260220px
Samsung S3 Mini800 x 480 (480)24020
Asus MeMO Pad 71280 x 800 (800)260310px
Now the game scales much better.

Let's fix the Touch Controls.

Those touch buttons share the obj_touch parent so I can do this in the controller Begin Step event.
// Add these in the display init script
xoffsetmult = (Xoffset / mult)
yoffsetmult = (Yoffset / mult)
// Touch Controls
for (var dev = 0; dev < 4; dev++)
{
    touch_dev       = dev
    var _xpos = (device_mouse_x_to_gui(dev) / mult) + view_xview - xoffsetmult
    var _ypos = (device_mouse_y_to_gui(dev) / mult) + view_yview - yoffsetmult
    
    var this_button = instance_position(_xpos, _ypos, obj_touch);
    
    if this_button != noone
    {
        if device_mouse_check_button(dev, mb_left)
        { 
            with(this_button)
            {
                touch_press_action()
            }
        }
        
        
        if device_mouse_check_button_pressed(dev, mb_left)
        {
            with(this_button)
            {
                touch_pressed_action()
            }
        }

        
        if device_mouse_check_button_released(dev, mb_left)
        {
            with(this_button)
            {
                touch_released_action()
            }
        }
    }
}

The Future

As of today, I still experiment with the resolution of the game. I haven't found a perfect way to scale low res pixel graphic fullscreen with no black bars and no distortion... simply because such a way doesn't exist.Things change frequently around here, so we'll see if I'm going to stick with this method or not. Feel free to let me know your ideas on this matter.

Fuzeboy devlog – Fair death system

Don’t you hate it when, during a death animation/sequence, your character accidentally touches a powerup or a health pack… and then it dies anyway?!

Normal Death vs Last Chance (non)Death ™

This is what we wanted to avoid in Fuzeboy: unfairness. If you catch a heart during the final knockback, you will have another shot at it.

Fuzeboy full steam ahead!

In November 2016 I met Denis (@darftey). He’s a pixel artist. One of the best I’ve ever met, actually. We teamed up to develop Fuzeboy.

Full steam ahead! ouch!

It shouldn’t come as a surprise that since then, the development of KREN has been put on hold indefinitely.

We’re pushing hard on this mobile platformer game.

Unnecessary tricks…

There is still no official release date but we’re making progress 24/7 on every front. From music and sound to gameplay mechanics, from platform specific issues to minor graphic details.

Lots of care is being put into making this game as fun as possible. We care about details. We care about story and gameplay. We are in love with this game and we’re making sure everything goes the way we envision.

Stay tuned for more Fuzeboy news in the near future.

Kren devlog #3 – basic metroidvania planning

A well developed metroidvania game should start with a solid planning phase. One of the first things to figure out is the character movement. I’m not talking about physical variables such as speed, friction and acceleration. I’m talking about figuring out what are the movements we want the Player to be able to execute during the game.

Example: crouching.

Can the character crouch? If so, should it crouch only when standing still? Can the character crouch in mid air or does it simply aim downward? Is it possible to walk while being in the crouching position?

These are serious design considerations that should be carefully planned and addressed well in advance as they define the feeling of the game. The player will act and react based on what movements are available. It’s the absolute first response to player’s inputs.

Crouching: Metroid Zero Mission vs Axiom Verge.

In both games, you can crouch. But while in Metroid you stay in that position even if you let go of the down key/button, in Axiom Verge you get up as soon as you let go of the key/button.

Also, while in Axiom Verge you can walk while being in the crouching state, you cannot do so in Metroid Zero Mission. Yet if you press the down key again, you morph into a ball.

The mechanics are different and so is the gameplay. Plan carefully what you intend to create and plan it well in advance. If you can, plan it all out even before any test level you might be tempted to sketch.

It will greatly simplify the overall development cycle (i.e. you won’t be rewriting big chunks of core mechanics code again and again, risking to break previous works).

Kren Devlog #2 – Officially looking for a (Pixel) Artist

Today I started posting around forums. I'm looking for an artist. I have no artistic skills whatsoever; I cannot draw tilesets, sprites, animations... let alone concept art.

My primary objective would be to prototype the game with graphics.

I still don't know if this is going to be a commercial project or not.
Should it become a viable commercial game there could be many options. Here are just some of them

  • Prototype's used to get funding. Then...
    • The artist remains the same, becoming the final game artist. Gets what is due to him/her, plus revenues shares.
    • The artist changes; prototype art won't be used; he/she will get no revenues shares but will get what is due to him/her.
  • Prototype's not a prototype anymore and is ready to market; no more funding necessary. Artist remains the same so revenue share model apply.
  • Project gets cancelled. No one gets anything (this should not happen! at all costs!) Artist is free to use his/her art however he/she sees fit.
  • Project is released as freeware (unlikely). Same as above.

The project is going for the commercial route. It's now a revenue share work relationship.

Right now I'm unable to test the mechanics, to think about what works and what doesn't; to imagine the game world. I need to quickly place things in the levels, test them and get an emotional response as to what works and what doesn't.

That statement is a dramatic exaggeration. But you get the idea.

As of now, everything you see in the image below, except the blocks tilesets, were drawn by me. Ideally, this should change.

Still in early planning stages. Yet testing the platformer engine made in GameMaker.
Still in early planning stages. Yet testing the platformer engine made in GameMaker.

Right now I'm working full-time on this project.

Notes:

  • I will be trying to help the artist as much as I'm able to, given my limited artistic skills.
  • The game will have a resolution of 384 x 216.
  • Player will be more or less 36px tall.
  • The current game art won't be used as a basis (thank god!)

Beware: the game videos/images are only there to show collisions and other tech aspect. The overall feeling of the game is going to differ drastically. Think Super Metroid (there, I said it).

This won't be an action packed game.
In fact, when I think about it, I think about words like

  • solitude
  • isolation
  • mysterious
  • unearthly
  • uncanny
  • dark
  • ghostly
  • unnatural
  • dangerous

If you would like to collaborate, have comments or want to share your thoughts, leave a comment or get in touch via social networks etc.

EDIT:

Use the contact form I set up

Kren Devlog #1 – Upgrade System and Level Specific Items

Player now has data (like energy, starting_x and starting_y positions, starting direction and so on) and a nice inventory of permanent upgrades. I've called it inventory for the sake of it. It's just an array (it really is) of stuff you can get through the whole game. Permanent stuff. Stuff you can get only once per whole game.

In every room (level) there are a number of different objects (like enemies and items). Most of these items will simply respawn once the Player gets back into the same room. Again and again.

This way it doesn't matter how many times you killed the enemies in the room. As soon as you exit and re-enter the same room, all those enemies are just there. Again.

This is fine. Almost essential in some situation (believe me, there will be times when you'll need more enemies to refill your energy or ammo levels).

The green stuff will not respawn once you pick it up. The enemy will, as soon as you re-enter the room.
The green stuff will not respawn once you pick it up. The enemy will, as soon as you re-enter the room.

So what's with the level specific items? If you already acquired the high-jump ability, you won't find it again in the level. This is where the inventory comes into play. And this is what I've coded today.

By the way I'm not using maps. I'm using simple arrays. I just defined a couple of macros so I can use my global array like it's a key/value map. I get the added benefit of speed and code autocompletion in GameMaker. The only thing I made sure of, was to initialize the size of the whole array.

//Arrays
global.player[MAXARRAY]     = 0
global.inventory[MAXARRAY]  = 0

Obviously MAXARRAY is a macro (value is 255).

Then let's say that I have another macro like PLAYER_DATA which is an expression referring to global.player. And I happen to have just the right macro for the 0th position of such array; ENERGY.

If I write PLAYER_DATA[ENERGY] = 99, it'd be like writing global.player[0] = 99. But now I have autocompletion in GameMaker and a list of defined, clear, meaningful, macros.