dimanche 28 août 2016

Rushin Delivery: Devblog #4

Sometimes, sh*t happens...

🚗 Previously...

Sooo, yeah... A few days ago I realized that my Devblog #3 had disappeared. I am still kind of upset about it because I talked about many things and I had cool .gifs to show you the 'throw feature' (it was the main subject of this devblog...) and how it works. Since I moved to the south of France for my internship, I took my laptop but didn't make a backup of my work (which stayed on my other computer...). This week did not start very well...

Anyway, I wanted to rewrite it, but I do not have much time and I thought that a short summary could be enough. So, what did I talk about? I talked about this new feature I called the 'throw feature' which allows players to throw packages towards a target by sliding their finger on a touchscreen, or with their mouse on a computer.

Now do a 360 throw!

Then, I also talked about the mobile version (and there was this gif, it was awesome!) and it turned out to be better than I expected, so I decided to continue on this path, while of course, still working on the pc version. But I have to admit, this 'throw feature' has a better feeling on a touchscreen device! 

And to conclude this (not so) short summary, I talked about this new tutorial level, that looks like you are taking a driving lesson on an empty car park, and how I found it difficult to make sure that players learn all mechanics in a short period of time. Maybe I will have to make more tutorial levels, because this one is actually quite difficult...

I think that's it. So yeah, sorry for that. But, there are new things to talk about now (yey!)! 

🚗 The Good, The Perfect, and The Miss

Not so new actually, because I'm going to continue to talk about this 'throw feature'. Indeed, now that players can "choose" where packages will go, I had to work on those targets.  It's actually very simple: the nearer to the target the package is, the better. For now, I use colliders to detect the package's position. It works, but I have to manually set those in each level for all targets. I could use code to save me some time, we'll see. 

As you can see on the gif (the title was a clue too), there are different rewards. 'Perfect', 'Good' and of course 'Miss' if players miss their throw. There's also a fourth one, called 'Special Landing'. The special landing reward is given to players who managed to make their package land on, well... special places. They are not shown to the players and need to be discovered. They're not very intuitive, and I think players' reaction will be like "oh, okay... cool I guess." In conclusion, I'm not sure if I should keep this one.

Git gud 

🚗 Unity Tip

Those feedbacks were added on a canvas set in world space. Thus, when those were behind a building, players could not see what was written (you can actually see this happening on the second gif I show you earlier). But I wanted to keep them in world space, to make them appear at the package position, and stay at that position even when the camera moves. I tried so many things and it didn't work...

But thanks to this guy, I managed to do it! Here are the steps he described that you have to follow if you want your world space canvas to render elements on top of everything (well, it worked for me at least): 

  1. Put your UI on a Layer called UI (if it isn't already).
  2. Duplicate your Main Camera and call it UI Camera.
  3. Parent your UI Camera to the Main Camera.
  4. Remove scripts like camera control, post effects and audio listeners from the UI Camera.
  5. In the Main Camera Culling Mask turn off UI
  6. In the UI Camera turn everything off but UI.
  7. In the UI Camera change Clear Flags to Depth only
  8. In the UI Camera change the Depth to something higher than the value on your Main Camera.
  9. Then in your Canvas set the Event Camera to the UI Camera.

But because of the zoom effect, I had to apply this to the UI Camera too, in order to keep the feedback at the same position.

🚗 Reload System

So now, throws can be missed, but I didn't want the fact that players can miss one shot to be a way to lose the game, because of the innacuracy I think it would be cruel. Okay, the thing is, indirectly, it is actually a way to lose the game, but it is because a player took too much time and missed A LOT of shots.

To make sure players do not run out of ammunitions because of their lack of ski-... I mean, because of the innacuracy, a new package appears if they miss their throw. 

🚗 And now what?

What is going to happen now? Well, if I have the time, I will continue to work on the 'throw feature' because I already found so many ways to improve it. especially when packages are landing on targets. And when this will be done, I will work on a scoring system

Then, I will rework my tutorial level (maybe levelS), and create more levels! When I will have enough of them, I'll release an early version on pc and android to make some playtests. And, well, we'll see how it goes!

see ya

dimanche 24 juillet 2016

Rushin' Delivery: Devblog #2

Definitely shorter than last week's devblog!

🚗 New AI: Firetruck

This week, the biggest addition to the game is the 'Fire truck'. Like other cars, it has a defined route, but once a fire breaks out, the firetruck's speed increases and it continues on its route until it reaches the fire. It will take a defined amount of time for the fire truck to extinguish a fire. 

What I have in mind here is that this value should not be random, and thus, could be more easily anticipitated by players (I hope!). For now, what I plan to do is to have multiple houses that could be set on fire, and the game chooses randomly which one will catch fire. Is it worse than a random time to extinguish fire? Is random really necessary? (I think so, but it should be used sparingly).

As you can see on the gif, it totally ignores other cars and sends them off the road. The thing is, they can land on the road and be obstacles or land and you and make you lose (truth be said though, I kinda like it, but I do not think players will...).

In conclusion, this firetruck could be a great addition to the game, but it could also turn out to be a major constraint and frustrate players. I will undoubtedly have to get back to this and rework on this AI. And, last thing, yesterday I added a feedback that I will also use for the pizza truck. This could help players to anticipate if the amount of time for the fire truck to extinguish a fire is a random value.

plz don't mind the cars in the background!

🚗 NPC ('Non-Playable Cars')

I think you have already understood this quite well, there are several non-playable cars that will be used as obstacles on the road. Some have simple behaviors and others have more sophisticated. So far, there are 6 non-playable cars divided in 3 categories:

Standard: cars, buses, trucks
Always the same path, at the same speed. Because of their size, buses and trucks are harder to avoid. They will always interact with traffic lights. 

Random: fire trucks, pizza trucks 
The fire truck has a defined route and travels at standard speed until a house catches fire. Its speed will increase and it will continue its path until it reaches the house. Pizza trucks (not done yet!) will travel slightly faster than standard cars and will randomly (or not) stop in front of some houses for a defined (or random) amount of time.  

Two-stated: police cars
The police car, as seen before, has a defined route and travels at standard speed until it sees the player overspeeding. 

Note that in their 'urgency state', police cars and fire trucks will ignore traffic lights (obviously!).

With those different types of behaviors, I should be able to find some great combinations and make more levels with more variety. I have more levers on which I can work on to avoid repetition. If 6 are not enough, I have a few ideas left, but for now, I am afraid it will be too much. 

🚗 Traffic Lights

Welp, I think the title says pretty much everyting. Friday I worked on traffic lights and they work! I can easily change the time between each light, and therefore I hope it will help me create more sophisticated levels that will make players anticipate and take risks (players tend to like games that give emotions! :o).

Simple but adds some depth to the game

🚗 Win Menu

Very small addition to the win menu, there are now three different distinctions that rely on players' final score. Maybe it will motivate some players (I mean, who doesn't want that 'Excellent' reward??).


Also, now people are notified when they have set a new record. It's very simple (maybe too simple...), and I will undoubtedly rework this feedback sooner or later. This should be juicier

🚗 What's next?

Okay, so next week, I will finish non-playable cars with the pizza truck. Once I have all those components ready to be used, I will start to iterate on multiple levels designs and then do some quick playtests.

The thing is, I'm wondering if police cars, fire trucks and pizza trucks work well and add something to the game. But also, if randomness is really necessary. I mean, fire trucks and pizza trucks could work without random values. However, I feel like it will be too easy... but I can be wrong! This is why I wanna see how all of this fits together.

If things turn out to be okay, I will start to work on tutorials and new levels. Then, once I think I have enough (interesting) levels, I'll release a beta version to let people try Rushin' Delivery and get some feedbacks (yeah, hype!). Let's hope for the best. :D

samedi 16 juillet 2016

Rushin' Delivery: Devblog #1

🚗 Get back to work!

I have not written anything for a long a time, but now that I'm actively working on a new game, I think it's a great opportunity to practice my english writing skills (and also possibly to show you some of my works).

Summer holidays has started and thus I have more time to spend on personal projects. The development of Rushin' Delivery started a while ago (early May) but has been quite slow due to school, holidays, and my body needing some rest.  But since Monday, I'm happy to say that I'm making some good progress and a lot of things have changed (yey, smiley face!).

To keep me motivated, but also to "force" me to work on a regular basis (not that I dislike making video games, but there are too many distractions around me and some are very tempting), I have set myself the objective of writing an article every Sunday. Also, it will keep you up to date on this game.

That being said, I should tell you what Rushin' Delivery is about before going more into 'technical' details!

🚗 Game Concept

It's actually very easy to understand. You control the direction of an unstoppable delivery truck that needs to deliver its packages as fast as possible. That's it! Overtake other cars, run red lights, take one way streets in the opposite direction... do whatever you think is the best to make you save some time, but be careful not to crash your car. 

You can't accelerate nor decelerate. Just use left and right arrows to rotate your endlessly ridin' little yellow truck. I like to see this game as a modern version of snake (remember our good old Nokia 3310?).

🚗 DOTween

To begin the development part, this week full of changes for Rushin' Delivery started with the discovery of DOTween (thanks @Gib!), a "fast, efficient, fully type-safe object oriented animation engine for Unity", as stated on their website. In short, with this I was able to rework and improve some animations and feedbacks, in order to make things more juicy. 

For example, even if I started using DOTween mainly for UI, I tried the DOPunchScale function when cars were colliding, and the result is quite enjoyable. I think it works well with those cartoonish assets. So, if you are like me and you like to animate with code, you should take a look at this.


🚗 Level Selection Menu

Like I said before, I used DOTween A LOT to animate UI elements, and especially when I decided to improve my level selection menu. First of all, I wanted a better layout: more levels are shown (10 now compared with only 3 before), more informations given to the players and finally they can more easily see their progression but also how many levels remain (more content = happier players?). 

Then I started playing with tweens to make things more "responsive" and pleasant. You cannot (yet) play Rushin' Delivery, but I can guarantee you that the new menu feels much better and is way more enjoyable than the old one, at least on pc. For mobile users it will be another story, but this is a problem I will try to resolve later. 

On the left, the old version and on the right the new one (which one do you prefer?).

🚗 Fuel Limit

One of the biggest addition to the game was certainly the fuel limit system. Before this feature was implemented, players had unlimited time to finish a level. Admittedly, there's a rating system that rewards the fastest players, but the thing is, with some patience, everyone could finish a level simply by turning in circles and avoid cars at the right moment. It makes the game easier and I'd even say 'boring', because at the end, players avoid the main challenges. 

Now there's a fuel limit. I will not lie, it acts exactly the same as a countdown and once it reaches 0 you lose. Well, I lied (sorry!). You can actually win in some cases. Because I'm a nice guy, I made sure that, when its fuel tank is empty, the delivery truck 'slides' until its velocity is null. During this short slidin' phase, you have no control on the car but if it enters the objective, you win! 

THIS will make you salty

I'm sure this is a good addition to the game. It forces players to take risks and quickly find a way through all those obstacles instead of exploiting the lack of time limit. But it's possible that some players find this mechanic too restraining (and that's why we need playtests people!). We'll see how it goes.

🚗 AIs' Route 

Now, I will try to succintly explain how those blue cars (AI), but also other cars (police, firetruck, pizza truck, bus, etc...), work. For those who know what I'm talking about, no, they are not navmesh agents on a navmesh. They are simply going straight forward until they reach a 'turning waypoint' that I disposed in the level. And until yesterday, the route that those AIs took was defined on those turning waypoints, like this:

When a blue car passes over a waypoint, the latter checks a list of booleans and if the one at the current index is true, thus the car turns. Then the index value increases by 1 for the next car passing over the waypoint. And once all the list has been checked, we restart at the beginning of this list. This system was working, but with simple behaviors and with cars taking the same route over and over again. I wanted more complex behaviors, and therefore, this system needed improvements!  

So now, turning waypoints just give the direction (turn right or left), but they are indexed in a very specific way. The route that non-playable cars take is defined in their own script. It simply checks the waypoint's index, and if it is 'true', the car turns. Otherwise, it goes forwards. 


Of course, there are some exceptions that I need to deal with. For example, on the image above, if the car is coming from waypoint 7 and the script says the car has to turn once it reaches the 'turning right waypoint' 8 (element 8 is 'true') I will say 'no'. You can't see, but in lower left corner it's a one-way street from left to right, so, without this exception it would make the car took the street in the wrong direction.

Sorry, this is some very technical details, but the point here is that this new system allows me to implement more sophisticated behaviors. So this is good news and I'm happy!

🚗 New AI: Police car

Another huge addition to the game is the new AI. Like I just said, they are cops, and because of this, if they see you overspeeding they will chase you down until you crash. They act like a 'ghost system' in racing games. That means, once they saw you, they will follow your tracks but slightly faster than you. They're going to catch you up very quickly if you don't manage to get rid of them before!

The AI is not perfect, there's definitely room for improvements (and for AIs in general), but it's already powerful enough and could be very constraining for the players. I will use this behavior sparingly. But overall, they (AIs, cops or not) work as intended and do not need more sophisticated scripts. Maybe it will have to change later, but for now, as a beginner, I'm proud of what I was able to accomplish!

🚗 Final Words

To end this first devblog, I wish to say a few things.

I am not an expert game designer nor programmer. This is my first devblog and this is the first 'big' game I am making on my own (except for some assets, I am not an artist!). I am a student that wants to learn new things. I might do some mistakes, miss a few things or over-complicate others, but I think this should be a good exercice and I am open to constructive criticism. Things can only get better! 

Welp, see you next week I guess!

Useful links:
Kenney Assets
Simple Town Assets

lundi 7 juillet 2014

Coriolis : Le Carnet de Bord

Embarquez dans une aventure extraordinaire.

    Tout d'abord, commençons par rappeler le contexte. Coriolis est le nom d'un jeu de société qui a été réalisé par une équipe de quatre étudiants dans le cadre d'un projet de fin d'année à Supinfogame, une école de Game Design et Game Art. Deux game designers ainsi que deux game artists, travaillant ensemble dans le but de faire le meilleur jeu de plateau possible en quelques mois. 
    Cet article n'aura pas pour but de vous expliquer en large et en travers comment on joue à Coriolis, non. Pour cela, je vous invite à visiter le blog d'un membre de l'équipe qui résume très bien les règles mais aussi l'univers. Ce petit pavé aura plus pour vocation de vous expliquer l'envers du décor, mon point de vue sur cette expérience et les impressions qui en sont ressorties, après des heures passées à travailler d'arrache-pied sur ce jeu de société.

«La meilleure façon d'apprendre à nager, c'est en se jetant à l'eau.»

    Avant de rentrer dans cette école, je n'avais jamais vraiment conçu de jeu de société. Même, la simple idée d'en faire un ne m'avait pas traversé l'esprit. Cela vient sûrement du fait que je ne suis pas un grand fan de ce genre. Ceci étant dit, lorsque l'on vous annonce que votre projet de première année sera de réaliser un jeu de plateau et que vous n'y connaissez pas grand chose, vous appréhendez un peu. 

    Heureusement, vous n'êtes pas tout seul. Vous commencez à relativiser et vous vous dites que dans ce groupe doit bien se trouver quelqu'un d'un peu plus compétent que vous. Puis quand vous réalisez que tout le monde est à peu près dans le même cas, vous semblez perdus. Comment faire un jeu de société, jouable et agréable, alors qu'on n'y connait rien ? Et là, on vous sortira cette phrase : "La meilleure façon d'apprendre à nager, c'est en se jetant à l'eau."

    Certes, au début vous allez boire la tasse, croire que vous n'allez jamais y arriver, que vous ne remonterez jamais à la surface à temps et que vous allez y rester... Mais quand votre vie est en jeu, vous prenez votre courage à deux mains et vous faites tout pour vous y accrocher. Là, c'était à peu près pareil (j'exagère à peine). 

    En bon game designer que vous êtes, vous organisez un brainstorming avec votre groupe et commencez à lancer deux/trois idées autour d'une thématique. Si je vous dis "Pirate", vous me dites ? Bateaux, corsaires, voiles, pillages... ou informatique, hacker, binaire, abstrait ? Nous avons eu cette prétention de faire quelque chose d'original et peu commun. C'est vrai, un jeu de société sur les pirates informatiques, c'est rare. Mais il y a eu une explication simple à cela : ça ne marche pas forcément très bien, et c'est casse gueule. Imaginez en terme de représentation et d'ergonomie ce que cela pouvait représenter. On avait bu la tasse.

    C'est à ce moment-là qu'il faut commencer à s'inspirer. Ne pas copier, mais s'inspirer. Vous regardez des films de pirate, vous jouez à des jeux de pirate, puis au fur et à mesure que vous vous faites votre propre expérience des jeux ayant pour thématique l'âge d'or de la piraterie, vous cernez à peu près ce qui marche et ce qui ne marche pas. Et vous vous rappelez de ces scènes dans Pirate des Caraïbes 3 : le maelström et la carte qui tourne. Pourquoi ne pas faire un jeu avec un plateau circulaire et rotatif ?

«Tu ne veux pas venir playtester mon jeu ?»

    Evidemment, on était encore très loin de pouvoir s'en sortir, mais nous avions cette base solide. Une idée qui s'était transformée en mécanique principale de gameplay : des cercles rotatifs. Après la réalisation de quelques prototypes, on pouvait enfin tester notre jeu.

    Avoir un joli prototype fait avec trois bouts de carton, une punaise et de jolis dessins à la main, ne suffit pas. Si le jeu ne marche pas, votre jeu est mauvais. Beau mais mauvais. Tout le monde sait que l'aspect graphique ne fait pas tout le succès d'un jeu, et c'est encore plus vrai lorsqu'il s'agit de jeux de plateau. Mais comment savoir si notre prototype fonctionne ? Et bien, sauf si vous êtes un génie, vous allez devoir playtester, encore, encore et encore... Ne comptez pas créer de liens forts avec des personnes en leur répétant : "Tu ne veux pas venir playtester mon jeu ?". Ça ne marche pas.

    Faire tester son jeu est une chose, et c'est un bon début. Mais savoir bien faire tester son jeu en est une autre, et c'est encore mieux. Avant de lancer une partie, il est peut-être nécessaire de cibler des mécaniques de jeu à essayer, vérifier. Sûrement, vous ne jouerez pas toute une partie, vous vous rendrez compte d'un problème avant, et tant mieux. Vous gagnerez du temps qui vous sera précieux.

    Malgré ça, vous aurez peut-être la chance de trouver un ami qui acceptera de tester votre jeu à chaque fois — ami, si tu te reconnais, je te remercie, tout le groupe te remercie — et à chaque fois il en souffrira. Au fil de ces différents playtests, votre jeu va s'affiner et commencer à se régler. Mais il manquera toujours ce quelque chose...

«Quand on joue à votre jeu, on se fait chier.»
    Vous êtes quasiment à mi-chemin avant de devoir rendre votre prototype final au jury, et lors d'un ultime playtest on vous dit : "Quand on joue à votre jeu, on se fait chier.". Boum. On y croyait dur comme fer à notre jeu. Les cercles tournaient, le jeu fonctionnait, tout était réglé, mais c'était chiant. Avec le recul, le second game designer se joint à moi pour affirmer que notre principal erreur en tant que "réalisateur vidéoludique" a été de régler Coriolis avant même de vérifier qu'il était amusant. Toujours s'assurer que le jeu est "fun" et procure de vraies sensations avant de partir dans des réglages compliqués !

    Le temps presse et vous devez refaire la quasi-totalité de votre prototype. En tant que game designer, et surtout chef de projet — ce qui était mon rôle sur ce projet — vous devez prendre des décisions et faire des choix tranchés plus rapidement. Vous devez savoir, que dis-je, avoir ce don inné de pouvoir dire non à vos collègues, et peut-être amis. Un non ferme et puissant. Même si cela peut paraître simple, envoyer à la poubelle le résultat de nombreuses heures de travail d'un game artist en quelques secondes, ce n'est pas évident. Mais sachez qu'un gentil capitaine n'est pas forcément un bon capitaine.

    Dans ce genre de projet, il faut apprendre à se remettre en question et à recevoir des critiques. La phase de développement sert à se prendre tous les points négatifs dans la gueule, pour que le résultat final soit le meilleur possible. Si on ne nous avait pas dit que notre jeu était ennuyant, il le serait resté jusqu'à la fin. Si on ne nous avait pas dit que les pirates informatiques c'était casse-gueule, on se serait... cassés la gueule. Pour la plupart, nous ne sommes pas des génies, mais nous apprenons à s'en approcher le plus possible.

    Après des changements drastiques dans les mécaniques de gameplay de Coriolis et une refonte graphique exceptionnelle, notre prototype ressemblait enfin à un jeu de société. Je parle ici de mon groupe et de notre projet, mais il est important de préciser que la qualité des autres travaux est toute aussi bonne. C'est bon, on savait tous enfin nager.

«Il a été dur de ne pas vous juger comme des professionnels vu la qualité de vos jeux.»

    Ces mois furent intenses, mais aussi compliqués à gérer moralement. On a eu la chance de pouvoir profiter d'un certain dynamisme de groupe. Tout le monde répondait présent quand nous devions travailler, tout le monde se donnait comme il pouvait pour faire avancer le projet. Et même en dehors du travail, nous avons trouvé des moments pour resserrer les liens. Il est très important de prendre le temps de construire un groupe de gens qui se supportent, ou même mieux, qui s'apprécient.

    Je ne voudrais pas radoter, mais il est important pour moi d'appuyer ce dernier point. Même si notre jeu n'avait pas eu le succès qu'il a eu, j'aurais été fier du travail fourni par les membres du groupe. Ils ont tout donné : de leur temps, de leur sommeil, ils ont même négligé d'autres travaux importants pour se consacrer à Coriolis, et ça c'est beau. Nous avons été un groupe, et malgré les petites accroches — oui, il y en a eu quelques-unes, il en faut bien — je suis heureux d'avoir pu travailler avec ces gens.

    Après le prototype rendu, nous devions attendre quelques jours avant qu'il ne soit testé par le jury. Puis le lendemain nous devions soutenir notre jeu à l'oral, face aux différents membres du jury. Une étape forcément stressante, mais vous devez être convaincus de la qualité de votre jeu. Vous avez tout donné, merde ! Défendez-vous comme il se doit. Tout le monde mérite une bonne note à ce stade là.

  Quand l'invité d'honneur du jury, Thierry Lebourg, alias "Docteur Mops" — cofondateur du site Trictrac.net — vous annonce : "Il a été dur de ne pas vous juger comme des professionnels vu la qualité de vos jeux.", ça fait chaud au cœur. Tant d'heures de travail enfin reconnues et récompensées !

    Je ne m'attarderai pas sur les résultats finaux de tous les projets, ne trouvant pas ça pertinent, mais dans l'ensemble, nous avons tous réussi à convaincre le jury que nous étions capable de beaucoup. Même si je soutiens le fait que nous avons été lancés dans la conception de jeu de plateau sans véritable cours théorique auparavant, il est nécessaire de préciser que nous avons reçu l'aide régulière d'un intervenant, professionnel travaillant dans l'industrie des jeux de société depuis un moment. Après tout, nous sommes à l'école...

    En somme, cette expérience a été très enrichissante, aussi bien personnellement que professionnellement. Je n'ai jamais eu l'occasion de concrétiser à ce point une idée, un concept que j'avais en tête, et ce fut très intéressant d'enfin pouvoir le faire. On se rend compte à quel point il peut être difficile d'adapter une idée à la réalité, et de la rendre la plus attrayante et amusante possible pour les joueurs. L'encadrement du projet par un professionnel nous a permis d'être confrontés aux réalités du marché. Des réalités dont nous n'avons pas forcément conscience. Si c'était à refaire, je le referai, sans hésiter.


CORIOLIS - Fiche technique :

• Genre : Jeu de stratégie / parcours / récolte.
• Public : 8 ans et plus.
• Nombre : 2 à 4 joueurs.
• Durée : 60 minutes environ.

    « Dans Coriolis, vous emboîtez le pas d’Evan "Sly" Goldsmith, le Pirate le plus glorieux de ces dernières années et qui, avant de mourir, a décidé de dévoiler au grand public l’emplacement de toutes ses fortunes. Vous jetez donc l’ancre en direction de l’Archipel de Coriolis, dans laquelle vous devrez naviguer sur des eaux tourmentées, tout en essayant d’éviter les récifs et les navires adverses, afin de récolter un maximum de ressources, tout ça dans le but d’être le Pirate le plus riche. Vous aurez douze mois seulement pour mettre la main sur les trésors du Pirate défunt, éparpillés aux quatre coins de l’archipel, avant que les îles ne sombrent. Douze mois au cours desquels vous pourrez prétendre être le pirate le plus puissant et essayer de battre les Pirates de l’île légendaire afin de mettre la main sur le fameux butin d’Evan Goldsmith. »

Game Artists : Aurélie Bouquet, Victor Depardieu
Game Designers : Roman Ruiz, Nicolas Pankowiak