Tuesday, 15 May 2012

Generating smooth roads for top-down racing games on-the-fly


I am making a fake 3D racing game (like a lot of flash games you have seen). It looks like a first-person racing game, but doesn't use any 3D functions. Why not real 3D, you may ask and the answer is quite simple:
a. Not every game development tool has 3D support
b. It will be lot faster if designed correctly.

When I was creating the tracks, I was a lot bored and it was a tiring task to lay long tracks by hand just for testing. So, I decided to code for dynamic random road generation, so that I will never run out of road :D

The beginning:

At first, I thought it would be quite easy, you know like:

 Generate random points within a small distance and join them to make a road.

But the major flaw that surfaced quickly was that the road was not at all smooth, it was like throwing away some chunk of concrete at places.
My thought was like:
This is not how roads really look like :(
So, I decided to come up with a new approach to tackle this problem and
the next day, I came up with this solution.

Main concept

 The idea is pretty simple. You'll need to have a knowledge of how sine curves are drawn on graphs.
We won't need any transformation matrices for this.

1. The co-ordinate system is same as traditional, but the origin is at the bottom-center of the page.
   So, Y is always positive and X can be both be positive and negative upto a certain extent.
2. Co_eff is a constant value which constrains the maximum X co-ordinate of the road in order to
    fit it within the view. It is used as the amplitude of the sine curve.

First of all, I decided that that only full sine curves (one total period) will be used to avoid complexity.

 This also gave me one added advantage of smoothness of the curves even when one sine curve ends and a new one is drawn.

This are the steps for generating the first curve … The rest will follow similarly...


1. Generate a random value  (within a  suitable range) and store it as y1
    This y1 value is the (relative) height (distance in the y direction) at which one full sine curve

2. Now, as we know, sine curves have a period of 2⊼ radians.
   But, in our case, the sine curve should start exactly at the current point and terminate exactly at the next
  point (0,y1) [relative to the current point].
  So, we need to find a variable named "value" such that y1=2⊼*value
  We will use a factor of (1/value) with the independent variable [here y-coordinate]
  (as the curves are drawn along y-axis, so the x-coordinate of the initial and final
   point doesn’t change. So, we don’t care about the x-coordinate)

3. Now, draw the curve “ x=co_eff*sin(y/value) ” starting from the initial point.

It will look like this:

Last words...

When I was first thought of this whole dynamic road generation thing, I asked one my friend on Facebook for his view on this matter. From what I could make out, he had a better but not-so-simple approach in mind. So, we decided to make a shared  Google Doc about this and I wrote about this concept there.
As of now, he's working on his version of this solution and hopefully, he will soon be done with it, and we can have a better version in this blog...

Wednesday, 9 May 2012

Using arrays for better analysis of nodes in a tree


Let's start with the basics..
This post is written with the pre-supposition that the readers know about the theoretical concept of trees, storage of nodes of trees using lists and Depth-first search (DFS) used for analyzing those nodes...
[ If you are not aware of this terms, I suggest you read this book on Algorithms 
Also, keep Wikipedia handy if it appears a bit advanced...
Even if you know about these, still it's a good read..
As far as I can remember, it was allowed to be freely distributed; so you shouldn't hesitate downloading it. 
For quick learning, you may start with 3rd chapter named " Decompositions of graphs" and after completing page 95, I think you'll get the context...]


As we all know,  "tree" is a theoretical concept in Computer Science and hence, 
data structures like lists or matrices are used for storing these trees.
Now, all that is fine, but how can you find the relation ( like parent, child, descendant) between two nodes?
For eg. consider this -> 
A company has about 500 webpages in their website.
The webpages are inter-connected among each other, 
but without any looping, for easy browsing of the reader.
Consider that they have maintained a site map as a list.
Now, someone needs to find (separately for each) if 100 of those pages (Group.A) links to another 100 pages (Group B).
So, using a normal DFS search, it'll take 100x100 searches which is not all feasible.
Even an optimized DFS search, which checks the relation between one webpage of say Group.A, with all the webpages in Group.B takes 100 DFS search and each of them needs to loop through many of the 5oo pages to find the required relation..

Can the process be optimized further?

Of course, we can...
Actually, we don't need that much of DFS search (or, just DFS, whatever)...
Whenever  DFS is used a good number of times times,it is bound to search through the same nodes which has been already searched in a previous DFS.
This optimization, on the other hand, increases the speed of the whole process, by sacrificing some storage space.

Ok, just show me how to optimize it... (The main concept)

What I plan is to run the DFS through the whole list  (i.e. all the nodes) only once..
And use a 2-D arrays (with the number of elements being equal to number of nodes) to speed up the later searches...

The DFS search is to be customized such that for every level, when the explore() function :gets called
1. The node address is used to fill up the positions of the first column array sequentially
2. The corresponding second column (of the same row) is filled up with an integer which is decided by the
    following rule:
  • If it is the source, then the number used is 1.
  • For every next level of the tree, zero (0) is apprehended to the end of the number that its immediate parent/ancestor was given.
  • For every node, a number is added (in the end of the number previously obtained), which is equal to the sequential order of that node in that level in which it is accessed, taking only those nodes in account which have the same parent (not ancestor).
For eg, see the below  illustration:
1. The head node is given 1.
2. When the next level is accessed, a zero is added. So, it becomes 10.
3. Now, for the first accessed node in the second level, 1 is added at the end of 10; for the second accessed node in the second level, 2 is added at the end of 10;  and so on...
4. Now for the node in the third level which is the child of the node marked "102", at first zero is added to signify the next level and then 1 is added to show that it is the only child of "102" and hence it the child 
    which is accessed first... So, the number becomes "10201"
This continues similarly...

How is it gonna help me?

Now that the variable is assigned to each node, let's see how this numbers are gonna help us:

Note: This method is applicable only when the number of child of any parent is less than 100, which is acceptable for general purposes... Also, here acceptable zero refers to that zero which doesn't have zero after it and also isn't the last digit of the number... For. eg, if the head node had 40 sub-node, then the 1st child of the 30th sub-node will have a number "103001" : Here the coloured zero is not acceptable zero by definition, which actually signifies 0 of the 30th node..

1. The number with higher number of acceptable zero is of a higher level.
2. The numbers of same number of acceptable zero are of same level.
3. If between two numbers, all  the digits of the smaller number are same as the corresponding digits of the 
    larger number and 
    a) the larger number has no more acceptable zeros than the smaller one ->
        then the smaller number is the parent of the larger number.
    b) the larger number has more acceptable zeros than the smaller one ->
       then the smaller number is the ancestor of the larger one.

Thus, we can get all this information which are required for any type of relation between two nodes, without running the DFS multiple times, and using only one variable per node.

The End

Actually, I was reading that book called Algorithms (I mentioned at the Prologue) and I thought that this topic will bring a change of taste and so, here it is...
If you have any suggestions or want to have a small debate, feel free to comment.....

Monday, 7 May 2012

A bit more advanced motion planning ... Revenge of the zombies

Some words on the blog  (You can ignore this)...

Before I start this post, I am taking these opportunity to write something about the blog itself..

No one will like to read this, so let's keep it short..
In short, I made a banner for my blog using GIMP which you can see on the top instead of the text.. 
You can download the banner here if you wish and use anywhere, but don't remove the blog link..

Actually this is a stripped down-version of this image I made today using free GIMP brushes and fonts...
If you didn't notice, this image has a secret word hidden in the title itself !! Did you get it?
 You can get it here and also you can share it freely...
That's all about it, the real post starts here...

The post starts here...

FYI, this post is a continuation of the previous post on Easy Motion Planning made yesterday..

You must read the previous post, if you already haven't, to understand the context of this post..

I told something about optimization on the last post, but instead what I came up with is an algorithm for finding shorter route (compared to the previous one)...

But, unfortunately, this shorter route comes with a lot of sacrifice in terms of memory usage ..

I have always sticked to my philosophy of adding one example game to every theoretical concept offered in this blog and this one isn't a exception too, but, as I already said the game can slowdown a lot, specially if you move away from the zombies to a greater distance in a condition where there are numerous obstacles in between...

The example game is present here in .gmk format and here in .exe format..

Theoretical Concept (A better zombie arrives in the scene..)

 The main concept is a bit more detailed this time and so, it needs to be elaborated from the start...

Remember the previous zombie-human hide-and-seek game ??

Well, they unfortunately couldn't take down the lonely human that time because they weren't intelligent enough ....
So, they decide to learn from a human-vs-human hide-and-seek game and learn their strategy..

Zombies learn a thing or two :

They notice a few wonderful things :

  • Humans don't change their direction of motion only when they hit an obstacle..
       They become aware of the obstacle from a distance and plan their motion before-hand before hitting an 
       obstacle and are usually able to avoid it...

       So, in a hide-and-seek game with obstacles, they are planning their motion virtually at every moment..
  • Humans move in curved paths..
          They were confused how humans can move in curved paths !!
          After all, till now, they could move only in straight line...
          But in the end a wise zombie came up with this:
          Why not make small linear movements such that it appears curved as a whole??
           They already knew linear motion and so it wasn't hard for them to grasp the concept...
  • Humans are ugly (What!! I am serious!) 
          After all, the zombies saw only their male counterparts :D

Learn and evolve:

As soon as they noticed how humans perform well in Hide-and-Seek game, 
they were bent on imitating all those good things to better their performance ....

A better strategy:

The zombies change their strategy for good and here's what they come up with:

1. If there's a linear motion possible towards the human from your current position, always take that route...
    (After all, those fancy curved motion ain't the least-distance paths in this case)

2. If there's no linear path available,
    A. At first, you'll scan your nearby places (like the previous strategy)
       starting from closest places and gradually moving to far away places with the help of a (hypothetical) 
       instrument which can tell you if you'll be able to see that human if you move to a certain point or not 
       (without  physically moving to that place) and also check if the path to that point is obstruction-free
    B. Now, if you don't find such a point, you just hope that some other zombie will find him...
        But, as in most cases, you'll find one, which is your "local goal".
        So, when you have that point, you just don't start moving towards that point and stop when you reach 
        Instead you take only a single step towards it and reanalyze the situation starting from point 1.

So, what's the big deal?

Well, you have to do a lot of analysis for sure, because you decide your next step wisely in every instant..

But, as a reward, you get all this:

1. You'll always know the position of your enemy, and you don't follow any obsolete "local goal" 
   (As the player is usually always in motion, your local goal is bound to change every instant..
     There was this problem with the previous approach that you continue to move towards your "local goal"
     even when it isn't the best motion possible, as the player changes position...)
2. You don't ever collide against a obstruction 
    (unless moving along the perimeter of the obstruction is the best possible route... 
     even in that case it isn't technically a collision...)
3. You move along a shorter path
   ( As your strategy is decided in real time, you don't move through longer path wasting some time...
      This is a direct impact of  the absence of "obsolete goals")
4. And can you believe this !!!
    Your motion, in some cases, appear to be curved in nature....


What verdict!! 

Don't ask me if the zombies won or lost.... They don't PM me so often...
In case, they ever decide to, I'll surely share it with you ....

Ok, enough is enough !!

In a more serious tone, though, I think this more advanced Motion Planning has its own advantages and disadvantages...
It follows a much shorter path, for sure, but it isn't practical to  make the basic zombies this advanced because, of course,
a) it'll waste a lot of processing power 
(as it has to plan its next step every instant whereas the basic motion planning required such decisions only when it collided against an obstacle)
b) it'll make the game harder for the player...

So, it is usually better to use this motion planning algorithm only in case of "Boss zombies" or a army of "elite zombies"...
Whatever it is, in the end, always remember to keep the number of such zombies as low as possible....

The END ??

So, here ends my second post on Motion Planning 
And as I can feel, I will have a "overdose of motion planning" if I continue to post on this topic...
To be true, I don't have any more views to offer on this topic at the moment...

Though if I ever come across any fresh idea on this topic, I'll be sure to post theme here ..

So, there will be a change of taste in the next blog post:

The next post is going to be on one of those platforming tutorials I mentioned here ...

So, still tomorrow, good bye...

Saturday, 5 May 2012

Easy Motion planning

Original post

Hey mate! I forgot your name from G+.. Here's what you wanted..
Zombie game fixed 
Hopefully you've re-downloaded it.. (If your downloaded version has a constant val, then it's the correct one)..
 I've changed it a bit..
I've defined a constant val to tweak the values ... Change its value to tweak the performance .. 40 (default) is pretty fine..
It's working pretty good ... Just the way I planned .. Without real motion planning...

Detailed post


James Clerk  on Google+ asked me:

" As for my problem, it's based around Step Towards Point being removed from the D&D options. Turns out all MP (Motion Planning) functions were removed, so my game can't port to HTML5 properly.
What I wanted was for object A (A zombie) to move towards object B (The player), and if it came in contact with a solid object, he would move around it and continue to the player.
However, while the functions can be called in Studio/HTML5, they only do linear paths, and the zombies get caught on solid objects still."

This was in reference to his online zombie game here.

As he is going to edit his game, I will be hosting it on my dropbox account soon..

So, he asked me if I could help him solve it and there was a big bonus for completing this task .....

I'll get my first subscriber for this blog...

 My reply was:

Oh.. I checked your zombie game.. Is that the problem?.. 
Yup, I remember your zombies (your zombies.. :D) getting stuck at RIP stones.. 
If that is the problem, I can give you some easy solutions but specific only to that game...

I promised him that I will post a solution within 6 hours but in my count, I took about 30 minutes more though...

You can find the file .GMK file above ...

(As this post is GM-specific and doesn't use any pro-only function, so I am doing away with the .EXE version)

So, here I'll try to break up how the solution works
(even though it's far less advanced than motion planning, it works quite fine)...

James told that he will be looking forward to it and so here's the detailed explanation  of the solution...

Basic Theoretical Concept 


The main concept is  whenever the zombie is stuck because the straight line path to the player is blocked, give the zombie a local goal (which is the closest possible position from where it can make a straight motion to the player) and when the zombie reaches that local goal, change it's goal to the x and y-position of the player..

What is this goal thing you're telling??

The goal is a point on the current room of the game towards which the zombie will try to move in a straight line path ..

Please define the term "try" ??

"Try" here refers to a simple linear movement from one position to another unless it is obstructed by a RIP stone (i.e. a solid obstacle), in which case it will simply stop...

Is it this simple? Or, can you explain the concept in more details?

I have to break the truth.. It isn't that simple..
Even if the theoretical concept sounded perfect, here are some complexities..
I'll try to add  real-life examples to describe the problems easily..

Problem 1:

In defining "try" , I told that it is a simple movement which will stop if its straight path towards the goal is obstructed by an obstacle. But we don't want the zombie to stop (don't we? :D  Nope.. atleast in the game we are going to make those dumb zombies a little bit intelligent..) simply because it's path is obstructed by a solid obstacle .. We want them to move on..

Real-life example 1  and solution (Well, not so real...)

Consider it like hide and seek game.. 
You are the zombie who can walk only in straight lines... You want to find that damn intelligent human..
But as the human is intelligent, he tries to get your view (of him) obstructed by obstacles..
So, here you decide your strategy..
You'll scan your nearby places (starting from closest places and gradually moving to far away places)
with the help of a (hypothetical) instrument which can tell you if you'll be able to see that human if you move to a certain point or not (without  physically moving to that place)...
Now, you find one such place from where you view of the player is unobstructed and you can move in a straight line path towards him.. 

But there can arise this problem:

You can't move towards that nearby place you thought will be perfect because the straight line path to that point is obstructed.. So, you need to know if you can reach that point in a linear path or not..

If not, continue searching for the next closest best place according to your strategy.. 
(This closest best point has been referred to as ' local goal' or 'goal' previously...)

And, if yes, move to that place and continue the chase..

Problem 2 (Based on example..)

Though this problem may sound similar, it's a bit different....
Actually, this problem lies in problem1 too..
So, problem to both these solutions needs to be merged in the end..

So, that instrument tells you whether you can see the human from another point or not..
It doesn't really imply that you can move towards the human from that point or not.. Because your body 
(the body is equivalent to sprite of the zombie and the vision is equivalent to the line joining the center of the sprites of the zombie and the human) has dimensions and it may get obstructed even if you vision isn't..

Solution 2:

We'll need a bit of geometry now and also we need to focus on the game more now...

We'll need a basic assumption (which will make the complex geometrical problem easy) and my game also stands on this..
So, unfortunately this is a must requirement and in some minor way, limitation for the game...

Both the zombie and the player needs to have sprites of same dimensions and the precise collision (in GM) must be turned off for both the sprites

which is equivalent to

Both the sprites must have same size of bounding box used for collision

Look at this illustration:
The rectangles represent bounding box of the sprites, which are of same dimensions

Please note that this is a 2-D diagram though it may appear to be 3-D..

The line joining the center of both the sprites doesn't get obstructed by the RIP stone ...
But the two line joining the left-top and left-bottom end of the two sprites gets obstructed by the stone. So, the zombie can't move towards the human in linear motion without getting obstructed...

So, to make sure that the whole sprite can pass through, we need to do some more checking

We need to check if the line joining all the four corresponding ends of the two bounding box collides with the obstacle or not...

If not, then only that point can be considered as a local goal...

What still needs to be done?

James, at first wanted to know if I can re-write those MP (motion planning) functions and in the end, I can see that I've finally come up with a primitive and this game-specific version of it.....
Though I have always referred to it as a trick...
So, why not make it still better?

There is this one problem:
  • The zombies tend to overlap each other to a high extent such that after few minutes many of them becomes recognizably one... 
          I knew this was to come, and I do have a solution in my head..
         So, this will probably not be a problem in the future...
 Also, my approach can be highly optimized, I know that...
So, I'll make a new post on this optimization part... 
Hopefully, I'll be posting it tomorrow .....
Still then, hang on....

You may avoid this part (Unless you are James Clerk ) ...

Note: This part is GM-specific...

Q:James asked me why  I haven't used the solid property present for all objects in GM..

A:  Well, the truth is you would have yourself stopped using it after some days..
  It can be easily re-created with the place_meeting(x,y,obj) function..
  Just check if the next position will be collision free 
  from the other objects you consider solid and you're done...
  As an added benefit,you'll have full control over your objects..
  The solid property is somewhat mysterious and added in the help file 
  without much details...
  So, everyone tries to avoid it...
  From what I've experienced, I can tell this:
  1.It works only when two objects are colliding due to their speed variables
    (hspeed and vspeed)
  2.If you use like x=5 and y=22 to move an instance of an object to (5,22) and 
    there is already a solid object at (5,22) it doesn't give a error.. 
    i.e. both of them exists at that point in harmony.. but the problem starts
    if you want to move any of those instances using the speed variables they 
    get stuck...
  So, it is like your unrecognizable pain-in-the-ass feature...

 Don't use it at all....

Swift slope movement in platform games...


This is the first useful tutorial in the series of Jumbo Platform Tutorial.. Evolve from a noob to pro .
I have selected one of the topics marked Very Advanced to prove that this blog isn't just all about bragging,
So, let's start the real thingy ...

What is this all about and why is it marked 'very advanced'?


Ok, let's start with a image...

A screenshot from my example game at Game design Practical .. Part1

See those green shining things - yup, those are slopes ... you got it right...
Actually, it shows two types of slopes to be technical...

1. Steps (marked 1 in violet)

[ Many would suggest that the idea of steps and slopes are not identical in terms of physics ... 
That is undoubtedly true..
But when you look at a game, they both serve the same purpose ..
 Move vertically and horizontally at the same time...

 So, in terms of our game world, both can be handled similarly even though slopes are not continuous..]

2. Inclined planes(marked 2 in yellow)

[Slopes, as you know them...]

 [Just to add, straight and sloped surfaces are not distinguished in my approach..
 So, plane surface also fall in this category...]

Clearly, you knew about slopes, but I just revised them to make sure we are on the same page ....

Now, about being hard and marked 'Very advanced' .....

First of all, its better to know how I mark the hardness level of every tutorial..
The ones marked in Red are those which haunted me for about a week
and I spend hours achieving those results with little or no success at all.... 

So, these are like the special ones for me....

One of them is this one...

 Though I believe that it is quite possible for others to achieve this results within hours and with a different approach, I can guarantee can you one thing...

All these approaches are self-thought, original
and hence it is highly probable that it will never match with any other approach of the same problem you have ever known ...

So, it is suggested that you go through the Theoretical Approach section even
 if you already know how to solve this problem ...

Theoretical Approach

It is quite hard to explain it without this edited version of the previous image ..

Note: All the X-axis and Y-axis referred here considers the image displayed above to be in the first quadrant.. This is not similar to the representation of  x-position and y-position in Gamemaker where every object is considered to be in the 4th quadrant..

So, now my approach is:
For. eg. when right key is pressed:
Check the height of the slope in the next x-position you want the player to move, when the motion is possible ...

The checking should be done in this order ->

Start checking from a y-position somewhat below the current y-position of the player whether it is collision-free when the player sprite is placed at that point.

(this 'somewhat' value should be about 5 times the height of the slope sprite)

and continue checking vertically upright (for eg. bottom to top along the blue line in this pic)

until you are equally 'somewhat' above the y-position of the player...
If any check returns true ,

instantly snap the player to that position

and stop the loop..

I have tried to put up a pseudo-code representation here with the concept of maximum slope:

1.Max_Slope=Define the maximum slope that  the player will be able to move up along (0 to 90 degrees)
2.Max_Hor=Define the number of horizontal units that the player moves in each step (Usually, 5 is a good value in GM)
3.Height=Using any loop find the height  in next adjoining area
 (specifically the height of the (x+Max_Hor) position where it is collision-free when a player sprite is placed at that position [where x is the x-position of the player]...
 the place_meeting function of Gamemaker can be used)
(It can be negative or positive)
4. Find  Slope_obtained=Height/Max_Hor
5. If Slope_obtained<Max_Slope, move the player to (Max_Hor, Height) relative to the player's current position...

Example game:

I've avoided the maximum slope concept in the example game to keep it simple...
Controls: Use right and left arrow keys for movement..

If it appears a bit complicated, read it again slowly and try to understand it...

If still some of the discussions appear unclear to you, feel free to comment... I'm there to help you...


Friday, 4 May 2012

Jumbo Platform tutorial.... Evolve from a noob to a pro

Everything you'll ever need to know to make a cool platformer


So, you have decided to make a good platform game? Well, why not make it great!
You have probably heard that platform games are the easiest genre of games to make and it is undoubtedly quite true. Though this blog is inclined towards the "Gamemaker" software, and all the experience I gathered is from the GMC forum, all the discussions (except the GM-specific programming) here is applicable towards game design as a whole....
So, lets turn our head towards platform games again..
The first platform game I remember playing is Dave, though others may relate themselves with  Mario...
But the truth is that inspite of being the most ancient genres in the history of gaming, they remain one of the most discussed genre in every game design forum. This is probably because they still remain the ABC of game design ..... Every game designer starts his journey learning the basics of game programming and design .. and what's better than a classic platformer ??? Every game design forum (and specifically the GMC forum ) is full with "How to"  questions on platform games ...
A typical question starts like ->
" I am a noob in GM forum. I started making a platformer a few days back and now I'm stuck in a problem.
*The problem goes below*  "
So, does it prove that platform games are very tough?
No, it just proves that everyone typically starts with a platformer and they need a bit more help to evolve as a better game designer. Most of these so-called "newbies" starts  googling "Platform Game Tutorial" and no doubt, there exists a lot of good ones... But the problem surfaces when these tutorials end and they suggest you to try some advanced concepts like knock-back, springs, water physics, AI enemies or even slope movements..
Most of the noobs can understand what they have learned till now,
but these new things appear alien to them .....
They try to use real physics laws, which are impractical in this case.. So, I'll try to streamline this self-learning process for the future ones and tell them which tweaks are important for a good game..
Every advanced concept of platformer-cum-fighting game that I can think of will be present in my Blog.
Head over to the To Do list to see what will be added next.

Head over to the Available Tutorial list to see which tutorials have been added.

So where do I start?

Let me suggest you this tutorial page: Tutorials by Mark Overmars
1.You should read the first tutorial  there to get a good idea of what a good game is and how to make sure yours is too.
2.You may read the second and third tutorial if you are not adept with the basics of a game.
3. You must read the platform game tutorial before you continue reading this. This tutorial covers the basics of a platform game in general, and also tells you about its programming aspect in Game Maker 8.
*If the links are ever down, inform me. I have them safe in my hard disk*
This blog post can be considered a direct continuation of this tutorial.
Every advanced topic that is listed at the end for the reader to try out will be present here, but that is not all.
Read the To Do list and Available tutorial list to see what they are.
I can assure you even a Pro in game maker will find something of his interest in those list.

To Do List

All this topics will be added as tutorials very soon...
Technically, 1 (or, sometimes even more) every day....
 Use Atom Feed at the top-right or bottom of the page to stay updated...
And rest assured you'll never miss one..
*Technical information about the Atom feed*
 Atom feed on the top-right -> Feedburner feed
Atom feed on the bottom -> Blogger feed
Choose the one which suits you... 
And if you'll like a RSS feed, tell me through the comment section...
1.AI enemy
(Can be very easy, as well as very complex.. But the one here is mediocre... After all, AI is a vast topic)
2.Spring (Can be used as trampoline similarly)
3.Moving platforms
(To quote Mark Overmars, the creator of Game Maker ->"this is not easy!"
But, personally I think, it wasn't that hard either.. Atleast it was a lot easier than the next one...)
4.Water physics
(I hate to break the truth.. This isn't fluid simulation... But it's better than the water used in the "Bounce" game, commonly found in Nokia mobile phones... This one really wasn't easy to come up with...)
5.Advanced push-back function 
 (This one isn't really as simple as it appears. For eg. even if 2 objects undergo oblique collision in the air, this push-back will work perfectly. Also, this is achieved through an external update function. Just for your info, all the in-built variables of any instance in game maker are updated through an internal updated function.. This is one of my favourite..)
6. Double jump and run
(Maybe only beginners will need it...Commonly asked question on GMC forum)
7.Awesome Dragon-ball style projectile..
(Similar effect as energy balls in Dragon Ball Z(DBZ), if you know what I mean.. It looks very cool...)
8.Swift slope movement
9. *Your request here*

Colour coding-> Red -Very advanced  Blue -Bit advanced Green -Quite easy
Also, you can request anything related to platform games here and if it's good enough, it'll be listed here alongwith your name and ofcourse, an awesome solution...
If you know about a really advanced topic (not only platform games) and how to implement in Game Maker, tell me about it. If it's hard enough (I'll take a 2-day time about learn about it and if I can't find any solution), you can be a prestigious co-writer or guest writer in this blog ....

Available tutorials

1. Swift slope movement

(This is a very popular question in GMC forum ... How can I make the player move swiftly up and down along a slope?? ... The solution will work like a breeze ... Move smoothly along any rough slopes or planes)
2.(To be added soon...) 

One  topic will be discussed from the TO DO List every day..
You can request a topic from this list to be discussed soon by posting the name of the topic and a +1.
For e.g. Double jump and Run +1.
Your vote for a topic counts.. The one with the highest vote is discussed first....
If a topic lingers in the To Do list for more than 10 days, it'll be discussed as a special extra blog on the 11th day, in addition to the one Voted favourite....In this way, there won't be any backlog...

Thursday, 3 May 2012

Game design practical.. Part 1

 What is this?

This is a direct followup to my previous blog here.
I'll try to show you a practical example based on the theoretical  concept introduced previously.
My vision on this blog is to introduce some new or "cool" theoretical game design ideas at first and follow them up with an example game. This follow-up game will highlight as many of those ideas as possible..

Just as a info: 

Most of these  games will be made using Gamemaker 8... It's probably needless to say that i'm a great fan of this software and would recommend anyone to try the free version (though you may want to buy a full version to unleash the actual power)... In spite of all this, I'm highly  dissatisfied with their Gamemaker:HTML5, they've increased the prices many fold just to give you a piece of buggy crap.. I thought that I'll add browser games as example but unfortunately even this example won't run flawlessly in the HTML5 version (thanks to Yoyogames, the maker of Gamemaker:HTMl5).. So, there will be two versions of the examples:  
1.fully editable .GM8 file (smaller in size, but only for those who have full-version of the gamemaker, as it uses the pro-only functions) 
2.EXE version (larger in size, standalone version, for anyone to see the final product).

Recap from previous blog:

The previous blog offered some theoretical  concept on how to improve the looks and feels of a game.
My concept was to make the background dark and introduce a "grunge" feel...
Some discussions were also made on how to utilize shadows wisely. If you haven't read it, you may like to read it here.

Original post starts here:

For those jumping to see the final product, here's the link:
1. .GM8 (Same as .gmk ) link
2. .EXE link
All the controls and instructions can be seen by pressing F1.
Check it out for a secret!!
Special note: Run and jump for a higher jump. You'll need it!!


Note (about the game):

Few things should be noticed in the game:

1.How to implement the spotlight

 The orange lines from the top-left spotlight to the player is willingly left there to be shown.. It is to prove that the spotlight works correctly.. 
As it is quite difficult to make real 2-D light-shadow dynamics.. I've left the complex part aside to show its use.. Frankly speaking, it is a unrealistic light which you can easily understand when you try out the game..
The stripped version of the spotlight physics that I've used follows the following rules correctly:

A. Light originates as a pencil beam (intense bunch of light) and it doesn't spread. 

B.But the object(s) on which it falls spreads the light in a short range to illuminate other objects nearby..

So, when the line joining the spotlight and the player is obstructed by some object, that object is illuminated most brightly and the other objects nearby are illuminated partially depending on its distance from the aforesaid illuminated object.

If you have a better suggestion, I'd love to hear it...

2.The bright arrow

Look at the screenshot.. Can you see a bright arrow.. It is used to implement  this theoretical concept.
Beware.. flashy things can be misleading..

Tuesday, 1 May 2012

Let me share some real stuff..My game design ideas... Part1

Let me get to the point ...
My AIEEE exams are over and I've got a month of time to waste. It wasn't good enough, but it wasn't that bad too. So, I've decided to learn this UNITY game creation software which I've long yearned to do. Thus i can spend my time fruitfully without running out of what to do. That's all great, but let me share some previous game and game programming related ideas.{History: I started Gamemaker about  a year ago, and now I'm quite proficient at it, though i never really wanted to learn the 3d part, not because it is hard, but because it is totally undeveloped and there are no future plans from yoyogames to make it more better. All this lies behind my decision to learn a continuously developed 3D game creation software like UNITY.}
All my ideas here are based on 2D games as I've never worked with 3D graphics.
Okay enough foreplay, lets get on to the real stuff.
So this is my idea to add a whole funky dimension to a game 'cause everyone can make a game but it needs to appeal to the players.
And visuals are a huge part of that.
Statistically, it is seen that some really great ideas have failed on the grounds of crappy graphics and half-assed work in visual effects. So read on to make your game stand out....

  1. Make it dark... so Let there be light !!!

You need to give a whole dark grim look to the game and for that you need light.
Ironic, huh? And as complex as that sounds, it's pretty easy. But you might have to read the rest of the post for that.
So you think I just self contradicted myself in the first line there right?? Not at all!!!
No one would like to wander in your game thinking oh-shit-someone-forgot-to-turn-on-the-lights!
A game should be a masterpiece of art; as with every form of art it is very important to know where to start and where to stop.
See you can control the darkness only by light.
But the million-dollar question is where to place those lights? And of course, how intense should it be?
Actually there is no definite answer to this question. (Actually, it totally depends on the situation.)
Look at it like an strategy game; you choose a strategy and you fine-tune it until it reaches perfection.
Here is a helpful checklist that you might want to read—

          1. Place lights where it’s absolutely necessary:

See we are very imaginative beings.  The mind finds things more invigorating when it is unclear. Like it immediately piques your interest when you see the shape of something in the dark corner and you want to check it out. Even though you have passed the same corner countless times and never looked back at it. The darkness is what makes it mysterious, hence more interesting.

       2. Control intensity and range of light:

Place soft (low-intensity) lights. Preferably with long range. Don’t make it bright enough to jar the eye of the player. Make it blend. Make it natural and subtle.
Also it would provide the player with a longer LOS(line-of-sight).

       3. Use the shadows wisely:

In a black and white world, use both equally.
Place lights so it would illuminate some specific areas and/or objects.
Let the shadow swallow the rest.
Like say, there is a broken platform which is not illuminated in any way. Place lights below it that the platforms above the broken are lighted. This way you let the player know in a subtle manner that he’s going to fall unless he’s careful enough.
This way you make the player analyse the situation, intrigue him with options and generally make him more interested in the game.

      4. Brainstorm, brainstorm and last but not the least brainstorm some more:

So I have noticed that the whole grunge, punk-ish feel has been a part of a number of AAA titles.
But maybe the world hasn’t seen enough of it.
Which gives you the opportunity to come up with new, innovative, dare I say ‘cool’ ideas.
Let me help you get started by telling my own ideas:

A.   Use dim spotlights instead of lamps!

This works very well with platformers where the light comes from above. It will get blocked in certain places by upper platforms, leading you to new paths which you would not generally notice.
Let the light lead you!!!

B.   Throw in some bright colours:

Introduce some glowing platforms.
Or maybe you could illuminate the exit in cheerful colours and maybe also show an ‘easy’ path to it which will ultimately mislead the player.
Use sudden bright cheerful in-your-face  colours to break the monotony of the world and punch the player smack-dab in the face. But DON’t overdo it.
N.B: Most of my ideas are derived from platform games but history has shown that great games have always gone past the barriers of a single genre and there is a plethora of games out there that have mix-n-matched different genres. For example look at Max Payne 2.So even though this is based on platform games, makers of other genre can also find this helpful.