next »

[mbalestrini]

Title: we don't know yet
Codename: Auto Negro (black car in spanish)
Platform: Mobile.

[mbalestrini]

We've started working on a new game.
It all began with the idea of making a simple mobile game, to learn a little bit about the platform (performance, deployment, stores, updates, etc), as our previous game NAVE Arcade was very far from being mobile (for Nave mobile meant renting a van and driving it somewhere )
We wanted to make a very simple game, that ideally wouldn't take more than a month to develop (at least the core of the game, without all the platform specific development).
After a small brainstorming, and some sketches, this idea came up of a kind of horror game where you play with a car that runs on blood
We started prototyping, and doing some tests, but after a while we realized that it wouldn't take a month to develop. We've tried to cut on mechanics and content to keep it simple, but we felt that this game needed more. We had to decide to either leave it apart and start with a more simple one, or assume that it was not going to be a moth-to-develop game.
We choose the later.

The graphic style of the game is going to be pixel art like Nave, but with one more color: blood-red
 
I'll try to update as often as I can.

[and]

The art looks great - I really like that colour scheme. Would be good to see it moving? Will the car leave tyre trails of blood?

[mbalestrini]

The art looks great - I really like that colour scheme. Would be good to see it moving? Will the car leave tyre trails of blood?

Thanks! My partner Hernan is in charge of the pixel art (i'm in charge of programming and animation FX's )
And yes! the car leaves tyre trails. I've made a first version of them. I'll try to upload an animated gif later.

[mbalestrini]

Engine / Language:

The current prototype version is written in haxe/openfl. I haven't decided completely if I'm going to stick with it, or use Unity. I'm felling comfortable with openfl. I like haxe's language, and the game's 2d pixelated style is something that I've doing in flash in the past (Nave specially). But stability and limitations on the sound implementation on android makes me doubt. I also like the idea of using Unity to get familiar with it, and have the possibility of doing 3D games in the future.



Some blood tests:

These are the first versions of the blood splash you get when you hit someone.
The blood on the car isn't just a visual effect, it works as the gas/energy bar.

 

I'll probably re-do it once I finished with other stuff (I don't like the much). I think the new version will be a mix of both, and some splash lines, like the ones Hernan drew for the street splash:

[s-spooky g-g-ghosts]

Personally, I've never liked 1:1 pixel art, but at least it's solid. I must say the idea is simple and cool. The car and colors remind me of Tarantino's Death Proof (which is an awesome film by the way) and this could take it a little bit further.

[mbalestrini]

Personally, I've never liked 1:1 pixel art, but at least it's solid. I must say the idea is simple and cool. The car and colors remind me of Tarantino's Death Proof (which is an awesome film by the way) and this could take it a little bit further.

Actually the game art is designed for 1:2 (the animated gifs I've made are 1:1). But right now the game has two things we know some people might not like: stretch to fit and camera zoom (on my Galaxy S2 the resulting scale varies between 1.5 and 3). We haven't decided if we are going to stay with that or not. The main problem is handling different mobile resolutions with pixel art. If we decide to stretch as a solution, the camera zoom doesn't bother much.

[mbalestrini]

Update:
This last few weeks I've been cleaning up the code from the prototype. I've been reading a little bit about Component / Entity System design patterns (http://gameprogrammingpatterns.com/component.html), and wanted to try some simple implementation for this game, to learn more about them, so I've been working on that while I take the opportunity to clean part of the code. I've also added the Nape physics library to the project, and made some control and collision tests with some NPC cars.

I'm still not sure about the development platform. I think I'm reaching a point where, despite still being a prototype, I need to make the decision because the cost of changing is growing up faster.

Here's a short clip of a couple of weeks old version:

[Office57]

Please add some red splashes on "camera glass" to hit be more visible for player

[mbalestrini]

Please add some red splashes on "camera glass" to hit be more visible for player

We thought about it, it would give a nice effect and could be used as a difficulty feature, but we've decided not to include that right now because even tough you control the car, there's no human behind the wheel (or you don't know if there is) ... 
If I have some time I would like to give it a try just to test the effect

[mbalestrini]

It's been a while since my last post. Development of the game got kind of stuck for a while, specially because we made a little tour with NAVE in Argentina, and that takes time, not only when you are on the trip, but also the time you spend planning and preparing things for it.

But I'm back!

Car Physics

After implementing Nape physics, and incorporating it to the game's simple component system I was ready to start working on some 2d top down car physics simulation.
Up until that moment, the player car was moved using part of the code from NAVE, with no physics, just setting positions and rotations manually. But I needed to change that to let Nape help me with collisions reactions, and to give the car a more realistic feeling, specially if we wanted the player car to do other things than going on a straight line.
I started looking for some info on 2d top down car physics simulation.  I didn't find a lot, but after a while I kept these as my references and places for ideas:
- Car Physics for Games by Marco Monster
- Brian Beckman's The Physics of Racing
- quickb2 2d physics-based game engine

I've implemented a first version of a VehicleBehavior. It has a lot of hardcoding and things to improve, but it's working.
The main component in the simulation are the tires. I didn't make them Nape objects and use constraints to attach them to the car's body. I decided to use the same approach that quick2b did, and make them simple objects that I then use in my vehicle's behaviour to apply force directly on the body.
The vehicle is controlled by some turn, throttle and brake functions.

Here's basically what happens on vehicle update:
- For every tire in the car (I could have more that 4, although I don't right now)
   - Calculate tire position, rolling angle, velocity based on the car transform and velocity and the tire's local transform
   - Calculate tire load as the vehicle's mass divided by total number of tires (I didn't implement weight distribution based on the position nor weight transfer as a result of acceleration for now. I don't know if I will )
   - Calculate tire slip angle: the angle difference between the tire's heading direction and the real direction is going
   - Calculate the lateral force the tire applies to cancel the lateral movement, using the slip angle, tire's cornering stiffness and tire's friction coefficient
   - If the tire has brakes, and the car brakes are on, calculate the braking force, using the tire rolling direction and the config constant tiresMaxBrakeForce
   - If the tire is part of the transmission, calculate the acceleration force based on the tire direction, the throttle applied and the config constant engineMaxAccelerationForce
   - Sum all the vector forces together and, if the length is greater than the tire's maximum friction force I adjust the vector to keep it to that limit (Friction/Traction Circle). If that happens it means the tire is sliding.
- Apply all the tire forces to the car body
- Calculate and apply simplified drag force and rolling resistance force, according to the car's velocity, mass and a couple of config constants

To be able to test and tune the cars parameters and behaviours I've made a simple app where I drive a car and two AI cars chase me. I can change many parameters of all the cars to see what I like and save that configuration.
Here's a screenhot of that app:




What I've found hard to decide is the level of complexity I want to implement for the simulations.
More complex means more realistic simulations, more control parameters and more felixbility, but makes it harder to tune and test, some things might not be noticeable, and might make the playing experience less satisfactory in a simple arcade game (you don't want Mario to have reallistic jumping physics).
Even if I cut down some things I'm happy with the learning experience and hope I can use it on some other future game where more reallistic simulation might be needed.


Ok.
That's it for now. It took me a while to write this post and I have to get back to work on the game!

[mbalestrini]

We've been working on the start of the game. Hernan made a first version of the image of the garage where the game begins.
The idea is that you pull the car backwards, the blood starts to flow through the tubes, and once it has enough blood you let go and the car shoots like a pinball.

We have some basic concept for the game that is that we like it to feel a little bit like a pocketeer. That's why we made this pinball like start, and why the control is going to be with the accelerometer.

Here are a couple of images:



   


I'll try to make an animated gif so you can see how it works

[Juwdah]

Haha at first I thought there was a garage option where you could tune your car, when I saw those last pics.
Would've never guessed pinballing a vehicle, sounds promising. How much mechanics do you really want to add? It seems fun even kept simple.

[mbalestrini]

Haha at first I thought there was a garage option where you could tune your car, when I saw those last pics.
Would've never guessed pinballing a vehicle, sounds promising. How much mechanics do you really want to add? It seems fun even kept simple.

Yes, the idea from the beginning was to make a game with simple mechanics and hopefully fun to play. We are working on it

[mbalestrini]

New Sprite Render Engine

This last couple of months I've been working on replacing the sprite render engine of the game. I wanted to replace OpenFL's displayList and drawTiles, to have more control of the render, and to be able to use shaders in a more controlled way (I found a way to force some shaders with drawTiles, but it was some sort of hack, and too dependant on the inner workings of the OpenFL library which I don't control).
It was also a good opportunity to learn a little bit more about OpenGL, specially OpenGL ES 2.0.
I searched the web for info on implementing some sprite renderer in OpenGL. I couldn't find a definitive resource about the subject. I read a little bit of theory and tips about OpenGL ES on Apple's site: 
OpenGL ES Design Guidelines
Best Practices for Working with Vertex Data
Best Practices for Shaders

and also a series on ARM site:
The Mali GPU: An Abstract Machine, Part 1 - Frame Pipelining
Mali Performance 2: How to Correctly Handle Framebuffers

I then used Luxe 's sprite batcher as a base for mine. Luxe is part of the snõwkit: "a collective of tools and developers for Haxe". I highly recommend checking them (specially those working with Haxe). I was tempted to change from OpenFL to Snowkit as a base framework, but it's still in early development and doesn't have some features I need for the game (yet).

After I had the base sprite batcher implemented, I started playing with shaders to do some effects for the game, and then testing on a couple of devices for performance.
I was naive in terms of shader performance and mobile devices. I thought I was going to be able to do more than I expected.
This made me think that in terms of performance / device availability, we might have to implement quality levels, deciding what would be the minimum level we think the game needs to have (and without spending too much time trying to make it work on every single device).

I'm happy with the results of implementing the renderer. There're still things to implement, refactor and polish, but I think it turned out to be a good decision.

It took more than I planned, specially analysing performance issues, and I think it's time leave this aside and go back to gameplay development.