Sometimes a player asks himself something like ” Wow, how the *%¿! is this made?!” Feeling curious about how a part of a game is made is the first symptom of the gamedev curse and never ever playing a game will be the same. Where there was some portals now there is a code challenge and those awesome shooting mechanics are a nice case of study… it’s the gamedev curse and no one can escape his touch (muahahahaha!) Lots of “how to design games” guides or professional game designers talk about playing games as advice. For me it’s not only a good advice, it’s a must. For me anyone who wants to make games should play other games as much as possible, any kind of games, from AAA games to the last indie scene’s hidden gem. Play , play, play and then look for more interesting games to play as research, using every game as a resource of new ideas and challenges.
Tag Archives: indi
When eagerness is not enough
Some days ago, while having an ice cream with some friends, one of them asked about how much a freelance may charge for some graphics assets, and if it’s viable to hire someone for a game that’s not created to earn money with without a low budget. Most of the time, an indie or a beginner game designer/developer has a huge amount of eagerness and a so much limited amount of resources, including money, time, workers, or even experience and knowledge in some cases, and eagerness is often not enough.
As a beginner is normal to try to build a game alone, but even if someone is able to design, draw, animate, compose music and code each part of the game, it’s going to be a huge amount of work for our lonely developer and a hard test about how much he wants to end his project. Remember, the goal is always to end the game (as Sergio said once upon a time here…)
For those who still are brave enough to try alone with their project, I suggest them to try something before jumping on any other task:
- Think about how much time you want to spend in this project, and when do you think you are going to end it.
- Create a list of specific tasks, like “creating main character sprite sheet” or “coding move inputs”. Usually you should have between 50 and 100 different tasks or more.
- For every task set the time in your opinion is needed to end it. If it’s your first time doing something, mark it with a plus symbol or anything else.
- For each task, add a 10% to your time estimation, or if it’s your first time, add a 50%. It’s uncommon to get something working and fast enough at first try.
This last step shows how much time you will need to end your game, and usually is even more. If this estimation is much bigger than the time you want to spend, the risk of leaving the project before ending it is real. If not, or you still want to fight it alone, go for it as hard as you can and check some of our old posts if you are new to something like this, or this, or even this!
Introduction to enchant.js: part II
Hi!, since there is quite a bit to tell in today’s post I will go straight to the point!, let’s pick up from where we left of on the first part of this tutorial.
As with everything in life, first things first: we are going to need some art for our game.
In order to get moving quickly we are going to use some graphics I already made for this tutorial, but if you are curious on how to make your own assets (and if you are here it probably means you are) don’t hesitate and go check our pixel art tutorial right now!
Back to our game.
As I said, we are going to make a Flappy Bird clone, so we are going to have our player flying around trying to avoid an infinite swarm of green Mario-like pipes. Our player, won’t be a bird this time but this happy fellow:
First, we are going to use the physics simulation box2d provides in order to have our cat hit the floor and pipes in a realistic way. We will also have gravity, that will pull the player down to the ground and an upwards impulse to push the cat into the sky every time the player clicks on his mouse (or taps on the screen).
To achieve this, we have to create and initialize a PhyisicsWorld variable in our GameScene initialize method, like this:
physicsWorld = new PhysicsWorld(0, gravity);
(remember to declare the “var physicsWorld;” before the window.onload declaration to make it a global scope variable).
Now, on the onenterframe method of GameScene we will evaluate every collision and interaction between elements that “live” inside the world by doing and update on each frame, like so:
With this done, it’s time to create our game objects. As we saw before, enchant.js works with classes, so in the same way we did with our GameScene we will create a Player class, with its own methods: initialize and onenterframe.
The player class will look like this:
As you can see this class extends the PhyBoxSprite class, which allows us to have sprites that are able to intract with a PhysicsWorld.
Notice that we create the sprite with the enchant.box2d.DYNAMIC_SPRITE parameter, so our sprite will react on every collision with another physic object in a way that it will be affected by gravity and outside impulses.
Then, we initilize the sprite’s graphic asset and initial position. We also use an internal variable, called animationDuration which will keep track of the time that has passed since the last animation was used, so we can know when to step to the next frame of animation, as we will now see on the onenterframe method.
On every frame we check how much time has passed by updating the value of animationDuration. When a specific value is reached (0.1 in our game) we step the animation to the next frame. We only have four frames on our player’s spritesheet so we will use the mod (%) operation to cycle around every one of them.
Next, we set up the Block Class in a similar manner:
As you can see we have 3 types of block sizes 120px, 165px and 210px, so we can create a block with it’s related sprite depending on the size we want to use. Also, we create their physic body as STATIC, so it does not move when another object collides with it.
In this case we won’t animate the blocks, we just want them to move left, so on each frame we will decrease their x position by a specific value that we will call “blockSpeed” (appropiate, isn’t it?).
Now that we can create our game objects it’s time to put them to good use. Inside our GameScene’s initialize method we create and initialize our player variable, as well as the background image background and the scrolling floor (which will also be a PhyBoxSprite, in order for it to “interact” with our flying cat). We also create a pool for blocks. This is a variable that can hold objects in order to be able to work with them in a easy way.
Using groups we can easily access a whole set of game objetcs and then apply a specific method to them in just one sitting (things like moving them at the same time or even removing them all). This time we just need our blocks to be accesible and removable quickly, so we will group them all together and update them all on every frame.
You might have noticed that we add one background or another depending on a random number. One of them is a day bg and the other one a night bg, so it will give the game a different look every time you die and have to restart it (which will happen A LOT).
We also set up and event listener to the touchend event, which means that whenever the user clicks (or touches the screen) this will fire up. More on that later.
Once this is done we just have to append all this elements to our game class, like so:
We also set up the variable that will keep track of the time passed since the last time we spawned a new block. Since we are initializing the game we set it up to 0.
At last, we get to where the magic happens, the GameScene’s “onenterframe” method. This is just the update method for our game, so we will have to check for the state of every object and update them accordingly.
First we check if the player is contacting something. This means that it’s physic entity is colliding with another one of the blocks or with the floor. When this happens we just stop the game (if it wasn’t already stopped) and play a nice and loud crashing sound.
Just below, we simulate our physics world on each frame, allowing us to update object positions when they are affected by gravity and other impulses.
After this, and only when the game is being played, we update the scrolling floor’s position to give the effect that we are advancing forward.
Below is the block generation code. Every time the spawnBlockTimer reaches a certain value the game generates a new block, randomizing its generation so the game keeps up challenging. Finally, we check when a block has left the screen in order to remove it from the scene, so we don’t have unused objects out of scene that take up resources and eventually slow things up.
And, at last we code up the game’s reaction to player input:
As you can see, it simply applies upwards impulse to the player if the game is in PLAYING state, otherwise it just either waits for the first user input (the game does not start until the player clicks) or checks for player input after the game has finished (the player must click again to restart). When this happens the game just reinitializes everything by destroying the physical entities of every object and then destroys the scene, creating a new one starting the game over again.
And that’s basically it!, you can now play our flappy clone here.
And you can download the full code and assets for it from here.
Of course, feel free to modify it anyway you want and don’t hesitate to show us your results!
Get on with it!
You’ve been there, I’ve been there, we all have been there. You have this great idea for a game, you say to yourself “I have the best concept for a game ever!”, and you keep telling yourself that it shouldn’t be so difficult to code it up and put together, that you only need a few free afternoons to make it happen.
And yet you actually never make it. What happened here?, weren’t you motivated enough?. No, that’s not it, you were absolutely thrilled by the idea of becoming a game developer, of going to the other side, where the cool kids hang out. The side where people don’t play games anymore but instead go bananas and actually make them by themselves.
The thing is, it really takes a long way taking an idea, concept, or drawing to the point where you can call that thing a “game”. You probably filled a few pages with awesome character designs, amazing levels and mechanics, but they probably stay within the limits of that sheet of paper forever.
Unless, that is, you get your *#%@ together and start taking the right path in order to make your goals a reality.
So, for the sake of it (and my very own as well) I’m going to recap a few tips I’ve learnt until now on how to get your workflow, well, flowing.