Posts Tagged ‘tutorial’

A quick tutorial on Composite / Component Design Pattern (java)

Posted by (twitter: @doppelgunner)
Friday, April 21st, 2017 12:26 pm

I made the getComponent() similar to unity in which you use Generic in method to get the component that you want.




One Room Factory LD37 Post-Mortem

Posted by
Tuesday, December 27th, 2016 4:01 pm

If only making games was as easy as making custom PCBs

This Ludum Dare was a really interesting experience for both of us. We wanted to do LD36 already together, but one of us couldn’t, so we had to wait for a LD37.


When planning a evening before, we really hoped for a “Small World” theme and were able to come up with an interesting game in matter of minutes. The other themes seemed lackluster, because they were often too limiting – and One Room was one of them.

When we woke up at Saturday morning and started discussing it, we didn’t know for like 3 hours what kind of game to make. There were several options (some of which actually appeared in LD as games – solving murder in one room, time traveling in one room, cleaning a room, …), but we couldn’t think of anything that doesn’t need a good storyline. We just knew two things for sure – we DEFINITELY didn’t want to do a room escape game, and we wanted fancy 3D graphics.

After joking about stupid ideas, we somehow came to conclusion that conveyor belt game located in one factory hall could be quite nice and went to discuss details more and decided on our PCB factory game.

The development

The entire game was developed by two people — one was focusing entirely on programming the game mechanics and logic and other one was doing mostly graphics, lightning and other visual things (he implemented Inverse Kinematics for a robotic hand from ground up!).

In the first day, we managed to implemented conveyor belts, robotic hands and basic movable objects for the transporters. This was a good prototype, and the game already felt like a fun! So we knew we were on the right track.

The second day was dedicated to modeling rest of game objects and programming the rest of the game. At the end of these two days (around 4 am) we had a almost finished game. It still needed some polishing and changes, but it was playable from the beginning to the end.

To make the game totally complete, we really needed that third day – but we were all busy with our real lifes, meaning we couldn’t make much progress, apart from just a few bugfixes and polishing fixes. But we think we still managed to do quite a nice game over the course of these 3 days!

The Good

We really had fun when developing our One Room Factory and shared many laughs over TeamSpeak when developing the game – one can only wonder if the game would be even better if we didn’t have to work remotely, but could develop in one room together as some other teams did.

Also, since this was a first LD for one of our members (and first released game too!), we definitely learned quite a lot. Not only from the actual LD, but also from the feedback we’ve gotten. It was definitely an enjoyable and fun weekend!

The Bad

The HW requirements are quite demanding. Also, based on the comments so far, the game is quite difficult to understand; we did a basic tutorial, but because of time constraints (having to work on Monday AND being based in Central Europe cuts a lot of needed time due to timezone), we just didn’t have time for a proper tutorial.

Combine this with the complexity of the game (and players not being familiar to conveyor games), this game seems to hard to understand for some people. So, to fix this, we are releasing a video tutorial for people who would still want to play the game! (Don’t forget to turn on annotations)

The Future

Depending on how we do in the LD, we are considering to finish the game and release it – we are reading the feedback people give us in comments and it makes us really happy when people like the game! The most rewarding comments are from people who want to see the finished version (with a proper tutorial) – and it’s definitely possible it will happen! 😉

If you decide to check our game out, we will be happy for any feedback you will give us! If not, we are at least thankful you decided to read our post.

To try our game, you can do so here:

Vilem Otte
Pavel Kouřil

[SPOILERS] Fun with shaders for LD37, part 3!

Posted by (twitter: @avaskoog)
Sunday, December 18th, 2016 5:03 pm

Hey! Posted part 1 and part 2 earlier about some of the custom shaders that were written for our LD37 entry, LOCK AND RELOAD. c:

Since the posts easily get a bit lengthy, I decided to divide this into a series of more bite-sized posts so that I don’t have to sacrifice all too much clarity for the sake of space. This is part three, about two shaders that make use of UV scrolling (sort of) and number two is a spoiler, so do play the game first! c;


Some of the effects are connected to slightly fundamental parts of the story, and since the game ended up being really short due to time constraints, I recommend you play the game first to avoid the spoilers and get the most out of the game with it’s little twists! So I’ll be adding a “read more” tag at to some parts to hide some of the stuff from the front page of the blog.

Note: the game was made in Unity and the shaders were written accordingly and so any code will be given as boiled down versions of the shader code written for that, but obviously everything is readily convertible to something like GLSL with minor to no changes.


Animated TV noise

In the small room that the game takes place there is a television set, and at the start of the game you’ll find that the screen is turned on, but showing nothing but static. Moving static, of course, and not just a frozen image!

View post on

So how does this work? We could of course have gone super fancy and generate noise programmatically right there in the shader, but since we were not looking to do anything procedural here, that was completely unnecessary, and we’re only using a static texture with the noise already in it. The movement comes from randomly jumping around (rather than scrolling) the UV coördinates! ᕕ( ᐛ )ᕗ

UV scrolling

What does it mean to “scroll UV’s”, or “move UV coördinates around”? Well, the UV’s are what determine where and how textures will map onto a mesh/model. By moving the x and y positions of the UV’s along the surface onto which a texture is being rendered, the position of the texture will move. There are many neat uses for this, so let’s look at a few before we move on, just to make sure you understand! (◕‿◕✿)

View post on

A waterfall is easy to achieve by scrolling a repeating texture vertically along a simple rectangular plane. In this particular case, there are multiple layers of textures moving at different speeds on top of each other, as well as some particle systems to help sell the effect further.

This next GIF was recorded from this YT video from the channel ClassicGameJunkie and their show How did they do that?, so go check that cool channel out! Its creator is also working on the 3D platformer Clive ‘N’ Wrench!

View post on

The flat, cartoony eyes in The Legend of Zelda: Twilight Princess are best animated by scrolling the UV’s of the texture around the flat geometry rather than trying to actually move any vertices.

The noise texture

I admit! The briefing on UV scrolling was a filler, to some extent, because there isn’t very much to say about it. It’s very easy, at least now that you know how the concept works! c:

When UV’s scroll enough that we’re able to see one repetition of the texture meet another, there are two ways to go about rendering it. It can either be repeated/tiled, or it can be clamped. You may have seen these option before when looking at a texture in Unity’s inspector. To make it clearer what’s going on, let’s look at the noise texture in both modes:


As you can see, clamping means that the last pixel of each side of the texture will be repeated indefinitely in the corresponding direction, while repeating means, well, repeating. This is what we want, since we want to be able to move to random locations on the texture and still get the TV screen filled up nicely with static.

The noise shader

Finally! As you would know, perhaps from the previous part, the basic way of going about shaders is to run the program on each pixel, or fragment, of something to be rendered, and process the final colour and alpha to output for each. To get the colour from the currently processed pixel, we just use the UV coördinate in the texture that we got from the previous part of the shader, the vertex part. Like so:

fixed4 col = tex2D(_MainTex, i.uv);

What we can do now is to add some numbers to the UV’s—an offset—that will move to a different part in the texture. We want this to happen in a way that looks random, and we want erratic jumping, not smoothly sliding over to the next part in the texture.

The thing to do when one does want to move smoothly around a texture would be to move by a constantly increasing value, like the game’s time. This might alternatively be plugged into some function, like cosine or sine, to move around in wavy or circular fashions.

We won’t do exactly that, of course, but we still need the time variable to have the conditions keep changing. What we can do to get the jagged movements we want is to make use of the modulo operator to see if the current time is divisible by some number, and use that as the basis of our stuff. We’ll even use some wave functions!

Since the rounded number will remain divisible by something until it has changed into something else that no longer is divisible by that number, we’ll be seeing each position where the UV’s end up for at least a few frames, which is of course what we want. We want this to change over time, so we’ll modulo the time by the time itself, but multiply each operand by a different number.

float factor = (time * 10) % (time * 22);

Something like that! That determines how much we move. Now to determine how far and where to move! We’ll use cosine and sine for this, again plugging in the time, multiplied perhaps by something else (or even nothing at all—i.e. 1.0—this time). This will make it move around in circles, but of course we won’t be able to see that as we only skip around on those circles.

float2 movement = float2(cos(time), sin(time) * distance;

The distance variable ensures that we move about a fair distance on the texture, so that the difference between each position is clear. And honestly, we might as well plug in something like time % 100 in there as well to make the noise as varied as possible!

And so we modify our initial line of code:

fixed4 col = tex2D(_MainTex, i.uv + movement * factor);

That’s it! Incredibly cheap cheating for some fake randomness that looks good enough for something like this, where the texture is already very random to begin with. I only used a texture that’s big enough to precisely cover the screen, but in retrospect I’d say this works even better with a texture that’s much bigger than the TV screen, to make any repetitions less obvious!




Thus you may want to play the game before you move on! c;




[NO SPOILERS] Fun with shaders for LD37, part 2!

Posted by (twitter: @avaskoog)
Saturday, December 17th, 2016 9:45 am

Hey! Posted earlier about some of the custom shaders that were written for our LD37 entry, LOCK AND RELOAD. c:

Since the posts easily get a bit lengthy, I decided to divide this into a series of more bite-sized posts so that I don’t have to sacrifice all too much clarity for the sake of space. This is part two, about one of two shaders that make use of separate cameras and render textures!


Some of the effects are connected to slightly fundamental parts of the story, and since the game ended up being really short due to time constraints, I recommend you play the game first to avoid the spoilers and get the most out of the game with it’s little twists! So I’ll be adding a “read more” tag at to some parts to hide some of the stuff from the front page of the blog.

Note: the game was made in Unity and the shaders were written accordingly and so any code will be given as boiled down versions of the shader code written for that, but obviously everything is readily convertible to something like GLSL with minor to no changes.


Inventory inspection

This one is not a spoiler! c:

When picking something up, or clicking something on the inventory bar that was picked up earlier, the player will see a 3D view of the item in question along with some descriptive text.

View post on

This view is rendered by a separate camera than the main one to get a nice 3D render of the spinning artefact. The main camera that renders the room (still visible behind the UI) cannot see this model, and the camera that renders the inventory view cannot see anything except the inventory item.

Separate camera setup

This is achieved in Unity by setting inventory items to a render layer of their own, and then unchecking that layer from the main camera, while unchecking everything except that layer on the inventory camera.


Then you’re free to render your inventory and your game world in the same place, without them actually interfering with each other, like so:


Render texture

Next, we need to create a texture for the inventory camera to render what it sees onto, since we don’t want it to render into the main game view and replace what the main camera sees. A render texture can be added by right-clicking somewhere in Unity’s file inspector and finding the option in the create menu.

It then needs to be connected to the camera, but we’ll not be using the field in the inspector for this, as it won’t work as intended. Instead we’ll be creating a small script that sets the camera up with the texture as the game starts. Something like this at the top:

[SerializeField] private Camera m_cam;
[SerializeField] private RenderTexture m_tex;

This way we’ll be able to drag and drop the camera and the render texture onto our script. Then as the game starts we’ll call this:

m_cam.targetTexture = m_tex;

Simple as that! Finally we’ll need to draw the texture somewhere so that we can see it. We’ll do this by adding a “raw image” to our UI canvas which will take the render texture as its sprite/texture, and that’s it. Now during runtime the UI will show what the inventory camera sees in that image, and we can edit the UI element as usual to get it to appear where we want it!

Remember we can also adjust the resolution of the render texture by opening it up in the inspector, in case the default 256×256 is too small, or has the wrong proportions.

The shader

You may have noticed we haven’t actually done any shader work yet! ヽ(゚Д゚)ノ

We can see there is a white border around the inventory item’s model, and also a circle behind it. But of course that’s not automatic. Without any shader, the inventory would now look like so:


Not very fanciful, nor stylised. And potentially difficult to see, depending on the background! And of course this game’s UI has a dark overlay, so we want that white border around the model to make it stand out nicely no matter what’s below!

Border shaders can be tricky or not depending on the circumstances. In our case we’ve got a mostly transparent image with some non-transparent pixels in the middle; namely, those that make up the model. This makes it simple: we look for pixels that are transparent but have an adjacent non-transparent pixel at a particular distance from it (which will determine the thickness of the border), in which case we make those pixels as opaque as we wish and then assign the border colour to them! (◕‿◕✿)

Remember that we get the colour of the pixel/fragment at any given position in the texture by sampling a UV coördinate. To get the currently processed pixel, we just use the unmodified x and y that we got from the vertex shader:

fixed4 col = tex2D(_MainTex, i.uv);

To for the alpha value of any pixel around this one, we need to offset the UV coördinate by as much as it takes to move on to the next pixel. We’ll start simple, by only sampling the nearest pixels above, below, to the left and to the right of the current pixel. This gives us a less smooth border, but is easier to keep track of.

UV’s are normalised between 0.0 and 1.0, so to get the size of a pixel at this scale, we will need to divide 1.0 by the width and height of the texture’s resolution (in pixels). If we want our border to be thicker than one pixel, we can multiply the result by some value.

fixed2 one = fixed2(1.0 / width, 1.0 / height) * thickness;

Now we can get the alpha values around the current pixel by sampling the surrounding UV’s and only storing the alpha value and ignoring the RGB components.

fixed left = tex2D(_MainTex, i.uv - fixed2(one, 0.0)).a;
fixed right = tex2D(_MainTex, i.uv + fixed2(one, 0.0)).a;
fixed up = tex2D(_MainTex, i.uv - fixed2(0.0, one)).a;
fixed down = tex2D(_MainTex, i.uv + fixed2(0.0, one)).a;

The case may well be that up actually means positive values rather than negative depending on your coördinate system, but it makes absolutely no difference to the end result of this effect, so we need not worry about it. ᕕ( ᐛ )ᕗ

Now we can accumulate alpha values by adding all of these together, then clamping the result to 1.0 and do some more maths to finish up, which will be explained below the complete line of code.

fixed border = min(1.0, left + right + up + down) - col.a;
col.rgba += border * transparency;

Finally we subtract the alpha value of the original pixel that we are currently processing.

  • If all surrounding pixels as well as the original pixel are transparent, the end result will also be transparent, and we’ll either get no border at all, or a semi-transparent border pixel, which will give a nice and smooth result so long as the original model was also rendered with anti-aliasing.
  • If the original pixel was not transparent, the border value will be reduced (all the way to 0.0 if the original pixel was completely opaque; otherwise a semi-transparent value) and the original colour will overtake the border, since there will be nothing to add when we finally add the border value to all of the channels (RGBA) of the final colour.

We can also multiply the value we add by some factor below 1.0 to only apply a semi-transparent border. Et voilà!


This border actually also samples pixels diagonally from the original pixel to make it even smoother. Note that this doubles the number of texture lookups, which can be slow, so choose carefully whether to add this extra overhead depending on the needs of your own application.

As you can see we still haven’t added that circle, but this post is getting lengthy, and you can get an idea of how to render a circle all in shader from the previous post. It’s one of the easiest things one can do, actually! Or you could just add a circle image to your UI below the UI image with the render texture if you’re not feeling up to it!


That’s it for this part! In the next one (and I won’t be posting it right away as I don’t want to be spammy), we’ll be talking about some UV scrolling shaders (one of which is a spoiler) before we move on to the second effect in the game that required extra cameras and render textures, which will be a SPOILER, so play the game first! c:

Remain at the edge of your seat! ☆

[NO SPOILERS] Fun with shaders for LD37, part 1!

Posted by (twitter: @avaskoog)
Friday, December 16th, 2016 2:34 pm

Hey! They’re not all too advanced, but I still thought I’d share a little something on the custom shaders that were written for our LD37 entry, LOCK AND RELOAD. c:

Since the posts easily get a bit lengthy, I’ll divide this into a series of more bite-sized posts so that I don’t have to sacrifice all too much clarity for the sake of space. We’ll start with the main shader that gives the game its look and feel!


Some of the effects are connected to slightly fundamental parts of the story, and since the game ended up being really short due to time constraints, I recommend you play the game first to avoid the spoilers and get the most out of the game with it’s little twists! So I’ll be adding a “read more” tag at to some parts to hide some of the stuff from the front page of the blog.

Note: the game was made in Unity and the shaders were written accordingly and so any code will be given as boiled down versions of the shader code written for that, but obviously everything is readily convertible to something like GLSL with minor to no changes.


Post effect filter

This one won’t spoil a thing as it is the very first thing to see upon starting the game: the wonky colour effects and checkerboard overlay. There’s also a dark vignette as well as some increased contrast.

View post on

This effect applies to the whole final rendered image rather than individual objects and is therefore done in one step at the end of each frame, simply applying the shader to each pixel, or fragment.

Let’s go! ᕕ( ᐛ )ᕗ

The low-fi colour effect

This is achieved by first multiplying the colour values (which are all normalised between 0.0 and 1.0) by some factor, then rounding the numbers so that any resulting decimals disappear, and then dividing the values back down again by the original factor. This effectively decreases the colour variation. The smaller the factor, the greater the effect.

col.rgb *= factor;
col.rgb = round(col.rgb);
col.rgb /= factor;



The contrast effect is fundamentally not so complicated. It can be done in different ways, but for this particular game what I found worked best was to subtract some of the intensity of the colour if the original colour was below some tolerance value, but multiply it by some factor if it were above it.

col.rgb += (col.rgb < tolerance) ? 0.5 : 1.5;



Alternating dark and bright squares are all over the screen. This isn’t some texture; just a little bit of maths. By checking the position of each pixel on the screen and figuring out whether it’s even using the modulo operator (which gives the remainder of a division), we can figure out whether the number is evenly divisible by two and thereby whether it’s odd or even.

If we multiply the coördinates by some factor to pretend that the screen is smaller or bigger than it really is, we can control how big the squares get. We apply the effect by darkening odd squares and leaving even ones untouched or vice versa.

col.rgb -= ((floor(x * s) % 2.0) - (floor(y * s) % 2.0)) * darkness;



In this case, a vignette is a darkening of the corners of the screen. We’re basically applying darkness to the whole screen except an oval in the middle, leaving the corners dark but the middle unaffected. Circles are easy. We can achieve an oval by pretending that our rectangular canvas is in fact square.

fixed ratio = height / width;
fixed2 middle = fixed2(0.5 * ratio, 0.5);

We can then check the distance from the center to the current fragment, adjusted for the rectangle’s ratio, to get its position inside a circle, which will appear as an oval thanks to the ratio.

fixed2 pos = fixed2(x * ratio, y);
fixed factor = length(pos - middle);
col.rgb -= factor * darkness;


You will probably want to adjust some values by multiplying them by various factors to make your vignette look the way you want.

That’s it for this part! In the next one (and I won’t be posting it right away as I don’t want to be spammy), we’ll be talking about the first of the two effects in the game that required extra cameras and render textures!

Stay tooned! ☆

Rough interface in the working, levels galore.

Posted by (twitter: @tselmek)
Sunday, August 28th, 2016 11:37 am

Got a rough base for a menu and a level selection screen as well as sketches of what the first tutorial levels could look like. Will leave them as is for now and improve them tomorrow, let’s make more levels now.

View post on

Unity WEBGL in under 3 Mins.

Posted by
Wednesday, August 24th, 2016 11:00 pm

Every single year we are plagued by poeple who still use unity web player or PC/MAC downloads only, if only you could just export to webGL and your game could be played in a browser…. well you can.

every LD i get frustrated by this and every LD i say to myself “next time you should create a video about using webGL”. but i dont because im usually too busy… well my friends, i may need to get an extension on my uni assignment now but BAM! i did it.

For Anyone thats in…. ill just leave this here:

Biological Warfare – Tutorial

Posted by (twitter: @ArtjomsNeimanis)
Monday, April 25th, 2016 9:50 am

Biological Warfare


Hello! Have you played our game? Are you curious about how we did the effect? Do you use Unity and want source code for it? Well, we are here to help you! 😀

We made a tutorial on how to achieve this effect (and it’s our first tutorial ever, so we hope we’ve explained everything well enough, and this can be useful to someone). In case you have any questions or suggestions – you know where to find us! We would be happy to hear them!

Metaballs tutorial


A tip for Platformer Developers!

Posted by (twitter: @ToastedGames)
Sunday, April 3rd, 2016 3:26 pm

Platformers have been a fairly difficult genre for beginner programmers to design. Most of the problems I’ve encountered come from the physics engine that has to be built. Generally, people don’t know how to program collisions with tiles and end up with players hovering over the ground, falling through the ground, or some other equally annoying glitch. I want to show you how to issues like this, with a script I made. Well, I won’t give you the exact script, because you won’t be using the same program as me, but here’s the basics:

(make 'i' equal 'velocity', if 'i' is greater than 0, repeat this loop until it equals 0, subtracting 1 every time)

//Run the script below for every pixel the player would move.
if there's an object at 'x', 'y'+'i' and it's a platform,
subtract 1 from 'velocity' //Lower how far down to go.
'y' = 'y' + 'velocity' //Go to the new velocity.

Well, that’s all for now. Hope this helps! Bye :)

(This post was a snip from my post on the Toasted Games website. Here’s the full post.)

Tutorial Page for Grow

Posted by (twitter: @fullmontis)
Tuesday, August 25th, 2015 4:26 am

Since my game, Grow, seems to be quite obscure, I made a simple image tutorial so that you can understand how to play it.

Grow Tutorial Page

You can check out the game here.

How to use Krita for cheap, quick pixel art

Saturday, August 22nd, 2015 1:14 pm

Here is a video tutorial for how to set up Krita for easy pixel art style painting: (HD index painting in krita)

Here is a link to do it in photoshop (original tutorial)

Game maker tutorials

Posted by
Thursday, June 4th, 2015 3:08 pm

I am working on some game maker tutorials and so far i am on ep 3, with stronger enemies and health bars, feel free to check it out if anyone wants to actually make a game instead of play them on this site. you can upload these to any website. so i hope you guys enjoy :)

Tutorial: creating circular worlds

Posted by
Wednesday, May 6th, 2015 8:57 am

I just published a tutorial on creating circular worlds here. This tutorial is pretty simple and describes the technical details to create a circular world like in my game, democracy.

I hope it may be useful for someone. Enjoy =)


PSA About Unity controls

Posted by
Wednesday, April 22nd, 2015 1:48 pm

I have noticed a lot of peole complaining about lack of suport for varius kind of keyboard configurations, so I thought I should make a post about this.

Alot of Unity games use Unitys built in Input system like this: “yAxis = Input.GetAxisRaw(“Player1AltYaxis”)”  (from my LD game)

This means that when you start the game after it’s built there is a tab called “Input” (it’s allways there).


You click on it and then you find the movment keys/Shoot keys or whatever you want to change.


Dubble click on it and it will ask you to chose what key you want for that command.


And then you are done, chose whatever key you like.


I hope this post will help you. Go and enjoy the great LD32 games now :)

I haven’t been here in a long time. So I thought I would share this code I made with you and explain how it works (so people who don’t use Gamemaker can reverse-engineer it). Unfortunately I’m not taking part this time round, but I felt like helping those who are!

Gamemaker Script Code

Simply copy and paste these into two seperate scripts:

Ring Health Bars

Circle Health Bars

To execute the scripts simply use:




Meet The Variables:

Ring Health bars

x,y = the coordinates of the center of the ring

radius = the distance from the center to the start of the ring

thickness = the thickness of the ring

rotation = at what angle is the zero mark of the ring?

angle = over how many degrees does the ring span?

max segments = how many segments the ring is split in to

segments = how many of those segments are visible

direction = which way is the ring drawn? 1 for anti-clockwise and -1 for clockwise

For the circle health bar the variables are the same except that thickness is not included.

Demo download

A demo (gif):

Circular Health Bars Demo


The demo is using two rings; one red and one green to simulate health.

What is this sorcery?

When a computer draws a circle, it is actually just a bunch of triangles arranged in the same way as slices of pie.

To find the coordinates of each triangle to be able to draw them we need a big steaming pile of math.


Specifically we need some trigonometry. Let’s start with which way is up:

Ring Health bars angles

Or in this case, which way is right: zero degrees.

A new temporary variable, i, will count our current angle as we sweep around the circle.

After each cycle in the loop it will change by the angle variable divided by the maxsegments.

Ring Health bars sections


Add to the mix our variables for radius and thickness and we can draw a triangle to work out our x and y coordinates for our triangles to draw!

Ring Health bars triangle

From this we can get the coordinates for the two points a and b. To get point b we simply add the thickness to the radius:

Ring Health bars triangle ab


Then we add the angle change to i, and get the variables c and d. Then we can connect the dots and draw one section!

Ring Health bars triangle cd

Ring Health bars section

Repeating this process for how many sections we want to draw will result in a ring!

This process is the same for the circle, except we only need points a, c, and the center for each triangle.


Good luck for LD 32! Hopefully this tutorial will come in handy.

I kinda rushed this. Hopefully you can understand it if you have a basic grip on maths.

Hexagonal Grids!

Posted by (twitter: @theupgradezone)
Wednesday, November 12th, 2014 5:10 am

So, I did the maths on how to draw a perfect hexagon. Now, using the same logic from that
tutorial, in this tutorial I will show you how to make a hexagonal grid!

Let’s say we have a hexagon with width a and height b.
(If you used the last tutorial, then the value of a from the last tutorial becomes twice that
value in this tutorial)


Now we generate a bunch of hexagons to fill up the screen area.
For this example the point of reference is in the center of the hexagon.

Each hexagon will be 3/4*a to the side of the last one, and b above or below:


Remember to keep a and b as whole numbers!

So the screen should look like this: (grey = hexagon, dark grey = overlap)


But we need every 2nd column to go up a bit, so that the hexagons interconnect properly.
So we use this equation, where x and y are the coordinates of the center of each hexagon:


Now your screen will look like this:



Now we can code it!

Pseudo Code:

width = (width of hexagon)
height = (height of hexagon)

Creation Loop:
create hexagon
x = x + (3*width)/4
if edge of screen is reached {
go back to starting edge of screen
y = y + height

Creation code for each hexagon:
y = y + mod(sin((90*(x/width))*height/2)



And there you have a hexagonal grid!

And this is the last of my little group of tutorials :3
Thanks for the comments on how to refine the logic and code of previous tutorials :)

[cache: storing page]