That’s a good question.
This is my first game. When I started one year ago, I didn’t know what to expect.
I didn’t know about code.
I didn’t know about graphic pipeline.
I didn’t know about game design.
So I learned the hard way. And it felt good!
I’m originally a graphic designer and I discovered a passion for coding. It’s so cool to have the ability to create a microcosm, with its inhabitants, its world and its rules. Once past the technical learning, coding is not that hard, It’s just a series of logical problems to solve. Just like a game actually.
Now, when I see the game running on an iPhone, I can’t still believe I did all the game engine. But also, I know I can make it better. When I started, I never though I could achieve this level of technicality.
Actually, I know one or two tricks for graphic production as I worked for 10 years in webdesign. I was in charge of projects that was more than a year in production. So that was the easy part. The graphics didn’t change much as I was pretty confident for the direction I was aiming. And having the best character designer helps.
It was interesting to learned how to make sprite sheets and how they are used in the code. It’s so retro! And you realize that this old video game technology is still the best. People who invented sprite sheets were genius!
Iteration is what is making you a game designer. If you can’t listen to criticism, if you make your game alone or if you don’t want to make thousands of prototypes, game design is not for you. Games are meant to be played and not only by you.
I really loved the first prototype I made. But no one else. Same for the second, third, fourth etc… But each time I asked people to play, I was watching them closely to know what was too difficult, what was repulsive or what was attractive. Then, I applied those informations to the next prototype and so on.
Having a 6 year old child at home really helped me in the darkest hours. She is very new to gaming but she plays games like Spy Mouse (which is incredibly difficult), Jetpack Joyride or Bumpy Road. Yeah, I know, good tastes. Her opinion was taken very seriously. I think I designed the game for her unconsciously.
Simple rule : If she would play my game over her iPhone favorites, it would mean that my game is good and accessible.
That’s what I aimed for all this year. And I’m almost there! Of course, she’s not the only tester but she’s a big reference. But don’t worry, it will not be a game about ponies. The difficulty will ramp up to the hardcore heights.
The most difficult thing to learn in game design is the carrot. That fucking carrot that will make the players play the game even if they die thousands times. And I still have a lot to learn.
Well, that was very interesting but what about the game?
The game will be revealed in the coming weeks along with a lot of surprises… So check back on this blog for updates.
Thanks for reading.
I’ve been watching closely what was going on on the appStore since its opening a few years ago. As an indie developer, I asked myself a simple question : how to price my game right?
The context today is this : both indie games and AAA titles are in an unfair competition. Why? Because they have the same price range (FREE – 10€).
Unlike the Appstore, the PC/Mac/Console market is healthier in this department. Between indies and AAA, the price range is larger (FREE – 70€). So when you spend 70€ in a game, you know you will get fancy 3D graphics and rollercoaster gameplay. But you can spend a few Euros in an interesting looking indie game just to try something different.
On the Appstore, customers expect to get AAA for 0,79€ or even for free. It makes it hard to differentiate your indie product from an AAA production.
A few indie devs took the issue in the opposite way. Simogo priced its fantastic title Bumpy Road 2,59€ at release and got somewhat successful. Superbrothers‘ Sword & Sworcery was priced even higher and got the attention it deserved. They believed in the value of their product and customers recognized this value when they purchased it.
The thing is, as always, those are exceptions, not the rule. The Appstore pricing is not healthy for indies. Long time are gone the days of Tiny Wings.
Having said that, what can we do about the pricing rules of the Appstore? Nothing. We have to wait.
The fact is that iOS devices are getting wider and wider audience. Most notably, younger players now want iPods Touch and iPads for Christmas, instead of 3DS or PSP.
What does it mean? Simply that as iOS is getting stronger as a gaming platform, AAA production budgets will rise and so the price of the games. 0,79€ per game is not a sustainable strategy for major publishers.
And user base will welcome more and more core gamers coming from aforementioned platforms that will be more inclined to spend more that 5€ on an iOS title.
When this will happen, and I believe it will eventually happen, it will give indies some air to exists on the Appstore, at least in the price point area. I just wish it could happen just right now.
In a more short-time window, I strongly recommend any indies wishing to make an iOS game to go cross-platform from the start. iOS, Android, Mac, PC, Flash, HTML 5… Anything that you can think of. The same goes for desktop/web indies as mobiles and tablets are here to stay.
Choose your development tools wisely. A lot of SDKs let you build for different platforms with the same code. As an indie, you may not have budget or time for porting your game. It might seems expensive to get a SDK like Unity vs. an open-source one. But in the long run, you will spare a lot of money/development time.
Share your opinion!
When I decided I wanted explosives in my game, I asked myself which video game grenade did I enjoy the most. Immediately, Quake came to my mind. I loved so much the brown and red art direction and Trent Reznor’s music was fitting perfectly. The grenade launcher was spitting grenades making those metallic sounds and bouncing everywhere, meaning death for the devilish mobs.
Ok, so my game is not about exploding zombies but I tried to find the same feeling that the Quake grenade. Its oblong shape has some interesting features :
- Random factor : you never really know where the grenade will bounce. Maybe to your target, maybe in your face.
- Convenient : it’s not rolling all over the level (vs. circle shape).
- Fun : it’s just fun to watch it bouncing.
All together, it makes things interesting gameplay-wise.
Grenades will be vital during your journey. You can use it to destroy enemies but it’s smarter to keep them to clear access to secret room filled with goodies.
The question now is : rocket jump or not rocket jump?
The last two months, I reworked all the gameplay of our upcoming game. I will tell you about later. But all you have to know now, it’s that you can get shields! Shield absorbs one hit and vanishes. Just like Sonic’s shield (Ooh I miss Sonic 1 so much… Good times).
Ho! And unlike Sonic, you will be able to upgrade you shield to absorb more hits. And as you know, nothing is free in this world. So be prepared to collect a lot of space coins!
Also, a big overhaul has been made to the lasers. Now they can go in any direction, can be any size and come in two flavors : red and blue.
This is a follow-up from a previous article talking about Box2D collisions issues.
That was a long time I didn’t post anything. But I have good news. The sticky situation is solved! Alleluia!
The huge mistake I made was that the different shapes were putted together using weld joints. Weld joints were not adapted as the shapes were “floaty”, meaning that the shapes were not strongly attached to each other resulting in disastrous collisions. Not speaking about the joints themselves impossible to manage in the scene and causing bugs.
The solution is not far from the third attempt. But the hitbox was built with the complex body constructor. Here, the different bodies are considered as one body in term of collision, but with different properties. Exactly what I need!
Now, when a side sensor touches a wall, it cancels the hero’s linear velocity in this direction. So the hero’s main body never touches the walls and that prevents the sticky situation!
The part of the code I re-written the most is definitively the collisions handling. Collisions handling is the program that makes hitting a wall, walking on a platform, pushing a crate, jumping, dying, bouncing… working properly in a game.
Hopefully, most of those actions are working good in my game. The only thing that I can’t get rid of is the “sticky situation”. It’s a well known situation for those using Box2D. I didn’t find any “perfect solution” to this. Only workarounds that could be featured in “There I fixed it” website.
So, I want to share with you my efforts (and misery) to make the best hit box for the hero of the game. So people won’t do the same mistakes I did and, maybe, a Box2D prophet will read this and show me the light.
This is my first very naive approach to the hero hit-box. As you can see, the hero is a simple round body. The ground and wall collisions are handled by those thin rectangles, called “sensors”, that are placed on the actual wall and ground physics bodies.
The sensors are not part of the physics world. They’re just here to send informations when something touch them.
The ground sensor prevent the hero from jumping when in mid-air. If the hero touches the sensors it means that he’s “grounded” so he has the permission to jump. As soon as he’s not touching it anymore, the permission is revoked. Simple and effective.
So why is the wall sensors are for? Is a big physics box not enough? NO! When the hero is jumping and moving against a wall, all we get is the infamous “sticky situation”! Meaning that the hero stays sticked to the wall until you release the left or right direction. This is something that makes me crazy about Box2D. Why don’t he just slides along the wall onto the floor?
Well, this is because of how velocity is handled in Box2D. As long as the hero has a velocity pushing him in a direction, he will stay sticked to any vertical surfaces. So that’s why I used sensors on the walls as well. They simply cancel the hero’s velocity so he can fall gently.
This was good enough. Simple and effective. Until I started to make more levels.
Making sensors on every surfaces was a pain and was quadrupling the physics bodies in the scene. So I had an idea. Why not putting the sensors on the hero directly? A tutorial on iForce2D (an excellent website about using Box2D) was saying like “Yeah, this is the way to go”.
So I came up with this. The same round body but with the sensors all around. The head sensor is for when the hero is walking upside-down but it does exactly the same as the foot sensor.
I almost believed this was the final attempt. Until the hero got stuck on a cliff. Yeah, the exposed surfaces of the rounded body was sticking to the cliff… Gosh…
Well, let’s make a square body then! If it was that simple… So what we have here, it’s that the corner of the main body are stil exposed to collisions without the sensor colliding.
So why not making the sensors the size of the main body? Because the collisions, especially at high speed, are not that precise. Box2D somewhat simulates the collisions but not at every frames. So, the result is that sometimes, the foot sensor hits the wall so the player can wall jump. Even if it’s cool, it’s not what I want. Or worst, the wall sensor hits the ground so the hero can’t move anymore. Bummer!
But, hey, at least, he’s not stuck on cliff anymore!
What I learned here is that I will never ever use a physics engine for a platformer again. There are plenty of “fake” physics that are just enough for this kind of games. But now, I’m too far into the development to restart from scratch. And, honestly, it’s so much fun to play with Box2D. It is far more easy to make physics based puzzles for exemple. So, I will “stick” with it.
I have different hypothesis to fix this sticky situation (which is actually the only issue I have with Box2D). I will try to make different bodies for ground and walls so the sensors will detect which material they’re colliding with and thus, will prevent confusions.
Feel free to share your experiences! I’m very curious to know how you struggled and maybe succeeded with this issue.
And thanks for reading my bad english.
Read part 2.
The last BETA build update brings updated graphics and visual enhancements for the scenery.
We added visual help like those big fat orange arrows that indicate the exit doors. We’ll add more stuff like this, such as “Warning” symbols when lasers are around.
What do you think (click image for larger view) ?
For comparison, this how the graphics looked like in an early build.