Tag: GameMaker Marketplace

Visual theory of the Z3D Engine

Editor’s note: [I originally wrote this as an Appendix to the documentation for Z3D Engine, but I think it’s interesting enough to deserve a slightly wider audience.]

I have to preface this section by saying that I have no idea what I’m talking about here, but am trying to learn.  I like math, but I didn’t go to school primarily for it, and that was decades ago. I haven’t studied 3D geometry, or optics, or computer graphics in any formal sense. I’m figuring this out more or less by myself, learning as I teach myself.

So if someone who knows more than I do wants to explain this stuff better than I can, I’d love to hear from you. You can send me an email at the Contact page, or tweet at me @csanyk, or just comment on this article

Thanks in advance!

I’ve called Z3D Engine a “Fake 3D” engine and “2.5D” engine, because those are fairly vague terms that I don’t have to worry about being right about. Someone asked me what type of view it is, and I couldn’t tell them. That bothered me, so I started reading a bit. I still don’t really know for sure.

or·tho·graph·ic pro·jec·tion
ˌôrTHəˈɡrafik prəˈjekSHən/

  1. a method of projection in which an object is depicted or a surface mapped using parallel lines to project its shape onto a plane.
    • a drawing or map made using orthographic projection.

I think this is sortof close to what Z3D is… maybe.  What I can tell you about Z3D is this:  You can see the full front side and the full top side of (most) objects.  These do not foreshorten.

gerund or present participle: foreshortening

  1. portray or show (an object or view) as closer than it is or as having less depth or distance, as an effect of perspective or the angle of vision.
  2. “seen from the road, the mountain is greatly foreshortened”

The blue rectangle that represents the “player” in the demo is intended to show the player as a side view only, with no pixels in the sprite representing the top surface of the player. This is because I’m intending Z3D to be used for games drawn in a visual style similar to the top-down Legend of Zelda games, and in those games, no matter which way Link is facing, you can only see pixels in his sprite that represent his side, and nothing that represents the top of him, even though you’re viewing most of the rest of the terrain in the room from this weird view where you can see both the top and side of things like blocks and chests, and for other things like bushes you can only see the side.

Things in Z3D do not appear to get smaller as they recede into the background, or get bigger as they get closer to the foreground.  As well, the tops of objects (that have tops), the top is drawn 1 visual pixel “deep” (in the Y-dimension) for every pixel of distance.

This doesn’t look correct, strictly speaking; if you’re looking for “correct” visuals this engine likely isn’t for you.  But it is visually easy to understand for the player, and it is very simple.

What I’m doing in Z3D Engine is showing the top of everything (that has a top) as though you’re looking at it’s top from a vantage point that is exactly perpendicular to the top, while at the same time you’re also seeing the side of everything as though you’re looking at the side from a vantage point that is exactly perpendicular to the side.  This is an impossible perspective in real life, but it works in 2D graphics that are trying to create a sort of “fake” 3D look, which is what Z3D does.

Imagine you’re looking at this cube:


At most, assuming the cube is opaque, you can see only three faces of the cube from any given vantage point outside the cube; the other three faces are occluded on the other side of the cube.

Cube with occluded faces

(That image above is properly called Isometric, by the way. Z3D is not isometric).

If you were looking at the cube from a vantage point where you were perpendicular to one of the faces, you could only see that one face, and it would look like a square:


(Since the faces of this cube are all nondescript, we can’t tell if we’re looking at the side or the top of the cube.)

Now, if it were possible to be at a vantage point that is exactly perpendicular to the both the side and the top of the cube simultaneously, the cube would look like this:

Flattened Bi-perspective cube

This is weird and wrong, but yet it is easy to understand, and it turns out that it is also very easy to compute the position and movement along 3 dimensional axes if you allow this wrong way of drawing.  This is view is (or perhaps is similar to) a method of visualization known as a oblique projection.

More properly, if you were positioned at a vantage point somewhere between the two points that are perfectly perpendicular to the top and side faces, the cube would look like this:

Cube in perspective

Here, obviously, we are looking at the cube mostly from the side, but our eye is slightly above, so we can see the top of the cube as well.  But notice, since we are not viewing the top face of the cube from a perpendicular vantage point, it does not appear to be a square any longer — it foreshortens, so that the far end of the top of the cube appears narrower than the closer end.

This is perhaps obvious, because we’re using to seeing it, because we see it every day, because that’s what real life looks like.  But it’s because we see this every day that we take it for granted, and when we have to explicitly understand what’s going on visually with geometry, we have to unpack a lot of assumptions and intuitions that we don’t normally think consciously about.

If we were to put our eye at the exact middle point between the points that are perpendicular to the side face and the top face, the cube should look to us like this:

Cube at 45°

Notice that both the bottom of the side face and the far edge of the top face are foreshortened due to perspective.

This is how they “should” look in a “correct” 3D graphics system, but Z3D “cheats” to show both the side and top faces without doing any foreshortening, which means that it can draw an instance as it moves through any of the three dimensions using extremely simple math.

Visually moving 1 pixel left or right is always done at a hspeed of -1 or 1, regardless of whether the object is near (at a high y position) or far away (at a low y position).  Likewise, moving near or far is also always done at a rate of one distance pixel per apparent visual pixel. And moving up and down in the z-dimension is also always done at a rate of 1 distance pixel per apparent visual pixel.

If we wanted to draw more convincingly realistic 3D graphics, we need to understand what’s going on with the eye, with perspective, and things at a distance.

Eye viewing the cube at a 45° angle

The same object viewed in Z3D’s perspective is something like this:

Eye looking at Z3D rendering

(We’ve omitted the occluded faces on the back end of the cube relative to the viewer, for simplicity.)

These two “apparent” perspectives are combined at the point where the player’s real eye is, resulting in something like this fake-3D perspective:

Z3D Flattened Orthographic bi-perspective rendering

So, in conclusion I’m not 100% sure that my terminology is correct, but I think we can call this perspective “flattened orthographic bi-perspective” or perhaps “oblique projection”.

(From this, we can begin to see how a corrected view might be possible, using trigonometry to calculate the amount of foreshortening/skew a given position in the Z3D space would need in order to appear correct for a single-POV perspective.  But this is something well beyond what I am planning to do with the engine; if you wanted this, you would be far better off creating your game with a real 3D engine.)

It gets weirder when you realize that for certain objects, such as the player, we’re going to draw only the side view, meaning that the player will be drawn a flat 2D representation in a fake 3D space.  Yet the player’s “footprint” collision box will likely have some y-dimension height to it.

Achievement unlocked: $100 in revenue on GameMaker Marketplace

On July 20, 2014, I released my first asset for GameMaker Marketplace, MMap Mini Maps.

Today, nearly three years later, I have finally reached the $100 author revenue milestone, meaning I’ll finally get paid.

In celebration, I’ve put all of my paid assets on the GameMaker Marketplace on sale for just $0.99 for one week, ending 4/10/2017. Update: I’ve decided to extend the discounts by one day per asset sold during the sale. So currently the sale will run through 4/12/17. We’ll see how long we can keep this going.

You can buy them here.

Enjoy! And share! And thanks!

UPDATED – YoYoGames Marketplace EULA now allows Creative Commons licensing

Update: It turns out that it has always been possible to link a Marketplace asset to another EULA; I had never noticed this before!

YoYoGames apparently has added Creative Commons licensing to their standard EULA for purchases made through their Marketplace with the Creative Commons Attribution-ShareAlike 2.0 Generic license.

The old GameMaker Marketplace EULA is still in use for some assets:

GameMaker EULA (old)

Assets sold under the Creative Commons license show a different EULA:

YoYoGames now uses Creative Commons licensing on the GameMaker Marketplace

Oddly, though, YYG have set up the checkout so that people purchasing assets for GameMaker Studio can make a donation to Creative Commons during checkout. At first, I thought that this was a donation to the asset maker, which would effectively allow a “pay what you want” model for free assets. But after clicking the Donate Now button, it became evident that it was for donating to Creative Commons, the organization that created the Creative Commons licensing. While I’m glad to see the Creative Commons organization getting support this way, it’s a bit confusing at first to someone who just wants to pay for their marketplace purchase.

Creative Commons licensing is a great idea and is exactly the right fit for the purpose here. I’m thrilled to see YoYoGames using CC licensing as another option in addition of their own license.

GameMaker Marketplace new checkout system now allows direct downloads!

Yesterday, 9/7, I noticed a big spike in downloads of my GameMaker Marketplace assets. I also happened to notice when looking around on the Marketplace that they’ve changed the checkout so that you can download the .gmex files directly through your web browser, bypassing the My Library interface in the IDE.

As I’ve remarked several times in the past year, My Library is crippled by terrible performance when the user’s purchase manifest exceeds some number that is far too low. Allowing purchases to be downloaded directly through the browser makes a lot of sense, and is probably the simplest solution to the performance issues, which still plague GM:S as of 1.4.1760.

It remains to be seen whether this spike in downloads will be sustained as the new normal, or represents pent-up demand for users who were reluctant to buy due to the poor performance of My Library. Despite the seeming smallness of this change, I’m really excited that YoYoGames have made it, as it alleviates a significant pain point that I’ve been complaining about for well over a year, and means that I’ll likely be making more use of extensions in my projects.

Graph showing sales spike on 9/7/16. Could this be due to the change in delivery method?

On 9/7, 18 downloads. The other spike earlier in August was due to my Ludum Dare 36 sale, when I put my paid assets on sale for $FREE

Update: 9/8 saw another 18 download day.

The Math: doing business on itch.io vs. GameMaker Marketplace

Following up on my previous post comparing itch.io vs. the GameMaker:Marketplace, here’s some math that explains the difference in costs for selling an asset through each store.

YoYo Marketplace Itchi.io
base price  $1.99  $1.99
store’s cut  $0.60  $0.20
paypal’s cut  $0.36
net income  $1.39  $1.43
net income % of gross 70% 72%

As can be seen, the transaction fees are not included in itch.io’s cut, while they are included in YoYoGame’s cut.

For low-cost assets, this eats up much of the 20% difference between YYG’s 30% cut and itch.io’s 10%, resulting in just a 2% difference after the per-payment transaction fees are factored in on a $1.99 asset. A difference of 2% may not sound like much, but in business that’s actually huge.

The gap only widens with more expensive assets:

YoYo Marketplace Itchi.io
base price $19.99 $19.99
store’s cut  $6.00  $2.00
paypal’s cut  $0.88
net income  $13.99  $17.11
net income % of gross 70% 86%

For assets that are priced higher, the cost of transaction fees will be less of a factor, meaning the advantage of itch’s service model will only grow as the sale price increases.

In the end, it will come down to which marketplace is more effective at generating a volume of sales that makes publishing there worthwhile in the first place. With the current glitch affecting the performance of My Library, causing “large” purchase manifests to take several minutes to display in GM:S, it seems to punish GM:S users for purchasing a lot of assets, and this would seem to concede the edge to itch for now. I keep hoping that YYG will fix this bug, but I’ve been waiting over a year since I first reported it.

But clearly, there’s a need for transaction costs to go lower in order for low-cost items to be worth selling. I’ve been waiting for a viable micropayment system for going on two decades now, though, and nothing seems to be going on in that realm. (PayPal does offer a micropayments option to merchants, at $0.05 + 5% per transaction, but it does not appear that this is an option through either itch.io or the GameMaker Marketplace, and this fee schedule replaces ALL transactions paid to the account in question, not just microtransactions, so it’s not really an ideal solution.)

Of course, you can also adjust the cut that itch.io takes from you to as low as 0% if you want, but it seems fair to allow them to have something for the benefit they provide you, so they can keep operating. Bottom line, a 10% cut for the services that itch provides is a very good deal compared to what you can get elsewhere.

Itch.io also offers greater flexibility with payouts, allowing sellers to have access to their money immediately after every transaction if they wish, or to receive a periodic payout. YoYoGames holds seller’s income until it reaches a minimum amount of $100 before you can get paid, so essentially you get paid in $100 chunks, and YYG may end up holding up to $99.99 of your earnings indefinitely. Two years on, and I’m still waiting to collect my first payday from YYG — I’m a little over 3/4 of the way there now.

A great feature that itch.io offers but the GameMaker Marketplace currently doesn’t is bundle sales. Bundle sales can help by cutting many payment transactions for multiple assets down to one. I offered my four paid assets in a bundle at a 33% discount, and so far all of my sales through itch.io have come this way. Such an option would be a welcome improvement to the GameMaker: Marketplace.

GameMaker Marketplace Asset: PNG_2_room

PNG_2_room is a simple, easy to modify demo for how to populate a room with instances according to a color coded image file.

Each pixel in the source image can be color coded to correspond to an object or tile in your game. Use the script room_instance_add_from_png() to populate a room with instances using the image as a key.

For example, this PNG image:


…was used to generate this room:room

You can modify the script to use whatever colors you wish to represent whatever objects or tiles in your project.

With this script, instead of using the built-in room editor, now you can use any image editor to create maps for your game more quickly!

You can even allow players of your games to create their own custom maps for your game, using whatever image editor they choose as a resource editor for your game!

A simple demo included in the asset shows how to use the script.

Full documentation at: https://goo.gl/z3du5f

Purchase at the GameMaker: Marketplace.

scrollsnap extension for GameMaker: Studio

My latest GameMaker extension, scrollsnap, is published!

Asset listing at the YoYoGames Marketplace


Demo video:

What’s scrollsnap?

Scrollsnap is a way of setting up a View in your room so that it “snaps” to the next screen’s worth of space when the followed instance moves outside the view. Simply put, it’s a view that stays put, but if you walk off the edge of the view, the view updates, giving the appearance that you walked off the edge of one screen and on to another.

Old-school video games such as Adventure, Pitfall!, and Berzerk used this approach to provide a larger game world to explore and play in, before programmers figured out how to make the hardware support scrolling.

Control Schemes 0.1 released


This is a collection of scripts and macros that handle motion and action. A “control scheme” is a set of inputs and their associated actions. Add a control scheme to your player object with just two lines of code!

It is intended to handles input, motion, and action quickly and easily, while allowing you to extend to include any audio or visual effects that may be needed.

Documentation is awesome.

Currently, just two control schemes are implemented; I’ll be adding others in the future, much more is planned.

It’s currently free, as I’d like to get everyone to try it out and provide me with feedback, but when I’ve added more features I’ll be charging for it, so be sure to get it now while it’s free!