PUN Rally (multiplayer racing tutorial)

[Released Dec 16th, 2015] – Buy from the Unity’s Asset Store.

So, it’s been a while since the last post, and the reason is that we’ve been really busy with a different project: a complete project/tutorial for the Unity Asset Store.


We developed this nice multiplayer rally game, and it’s being released with source code, comments, and an awesome tutorial in PDF. The project uses Photon Unity Network (and Photon Cloud) to provide seamless network connectivity, and Photon has been gentle enough to close a publishing deal with us.

Here are some links, and the project description from the Asset Store:

Discuss the pack in the official forum thread.

free PDF Tutorial

Demos: Win, Mac, Linux


Project description:

PUN Rally is a complete base project for a multiplayer racing game using Photon, the most popular network platform for Unity.

Here’s the first video in the tutorial series:

The project includes all sources and a 30+ pages illustrated tutorial book (PDF) explaining its use of realistic physics, dead-reckoning, checkpoint-based positions, and several other important features of multiplayer games, such as lobby control, car-selection and server-synced race-start.


– Realistic physics based on standard colliders, wheel-colliders and rigidbody;
– Detailed suspension movement;
– Real-time race synchronization over the internet using PUN (Photon Unity Network);
– Dead-reckoning techniques to smoothly deal with latency;
– Server-synced start and grid spawns;
– Checkpoint-based race management (positions, laps, finish, etc);
– Custom car selection (prefabs based) for connected players;

The project is a foundation for a multiplayer racing game, but also serves as a comprehensive introduction to several multiplayer concepts with Photon:

– Dealing with lobbies, rooms creation and joining;
– Managing player connection and disconnection (both in menus and races);
– Using custom player properties;
– Remote Procedure Calls (RPCs);
– Server-based time/clock (for race start);
– The PhotonView component;
– Custom network synchronization of GameObjects;
– PUNBehavior and Photon.MonoBehavior classes;

Simple Unity Game for Free

Last post we showed how we created a MOBA in 24h using Unity, giving the project’s sources for free in the end. The day before we got into that project, we’ve also coded another game for a fast workshop we gave at that time, a very simple maze shooter intended to show how easy one can create a fun and challenging game. We called it Spooky:

Spooky init screen. Can you escape the maze?

Spooky init screen. Can you escape the maze?

We’re also giving this one for free for beginner game developers and programmers who are interested in using Unity for their 3D games.

The game binaries can be downloaded (Win, Mac, Linux), and the project sources can be found on our Github page.

The game was made without the use of any 3D model besides Unity’s basic cubes and a single texture (for bullets). The cubes were coloured and scaled to represent the player (blue), walls (gray) and different enemy types (yellow, orange and red), each one increasingly more difficult to defeat.

Our inspiration came from a youtube video that showed how you can make a fun game using very simple graphics. We made it much simpler than the one in the video, so inexperienced programmers can still understand the code. You can always try to improve it and make it as complex and challenging as the one in the video.

Player, enemies and walls are basic cubes. The player can shoot the enemies (and some enemies do it as well).

Player, enemies and walls are basic cubes. The player can shoot the enemies (and some enemies do it as well).

The game consists of a single level/maze, that is populated by many enemies. The yellow enemies are almost harmless, except if the player touches them, going back to the beginning of the level. The orange and red ones also shoot the player, while the later one includes a screen-shield (meaning it has to be shot twice to be defeated). The enemies are positioned in the maze in order to give an increasingly difficult challenge level for the player.

The maze: besides finding the exit, the player has to defeat increasingly more challenging enemies.

The maze: besides finding the exit, the player has to defeat increasingly more challenging enemies.

The game uses only a handful of different object types, which we stored into prefabs. There’s the player, two bullet types (only the color changes), three enemies and a particle system (bullet explosion/sparks);

Prefabs were used to store the object types of the game.

Prefabs were used to store the object types of the game.

We only needed to write 5 very simple scripts:

  • player movement input;
  • player gun control and input;
  • enemy AI (shared for both enemy types that shoot – orange and red);
  • bullet script (that triggers sparks and object destruction on hit);
  • A test to check for victory condition;
Only 5 scripts had to be written.

Only 5 scripts had to be written.

Besides being just a handful, we made sure the scripts are also very simple to understand, nor having many lines of code, neither using any fancy/magic stuff.

The scripts are very simple to understand, specially tailored for beginner programmers.

The scripts are very simple to understand, specially tailored for beginner programmers.

So, what are you waiting for? Go to our Github page and download Spooky’s project sources and modify it at will. We hope you find it useful.

How to create a MOBA in 24h

[New Moba Project]:

Take a look at our new free game demo M.O.B.A – Mech Online Battle Arena. It’s being developed as a complete project/tutorial pack for the Unity Asset Store (released planned for April 2016). Besides the demo, all documentation will be free at the time of release (PDFs and videos).

[Original post]:

Last week, some friends gave us a challenge: to develop a MOBA (Multiplayer Online Battle Arena, such as Dota, LoL and HoN) to show at a gamers event the day after, and release it for free, with source code included. We’re happy to inform that we completed the challenge, and here’s the promised demo and source code:


24h MiniMOBA. Hero and a creep wave following the middle lane.

24h MiniMOBA. Hero and a creep wave following the middle lane.

For the version we’re sharing, the above graphics (which are from another game of ours) were replaced with free ones, and this is the final result:

screen01 - initial screen
screen02 screen03 screen04 screen05


  • For the binaries: start a server with the desired number of players (1 for testing alone), and wait for the remaining players to connect. For the clients: type the IP of the server machine and hit “Connect as client”;

    Instructions for running the game

    Follow the instructions above to run the game

  • For the Unity sources: clone the repository and open as a Unity 3D project (must have Unity game engine installed). Hit Play to run the game (or create a build and share for running on client/server mode);
    PS.: Remember to add this to your local .gitignore:

We kindly acknowledge the following people who indirectly contributed to this result:

  • Carlos (Pazuzu) Henrique – he’s the composer of the awesome music that we’re including in the project;
  • Edmilson Frank – testing and basic balancing were possible because of him;
  • Jefferson Henrique – kindly helped testing in a saturday afternoon, and coded a random music player for us;
  • User xiaolianhuastudio in the Unity Asset Store – we used his Make Your Own Fantasy Game – LITE free asset pack in our shared project. He has another complete asset pack that is very good and affordable;

How it was done:

Given we’ve never developed an RTS game before, it was quite an accomplishment indeed. Immediately after accepting the challenge, two of us (programmer and designer) discussed an approach and started to work towards completing a demo with the following features:

  • Single Lane;
  • Creep waves with waypoint-based pathfinding an AI;
  • Towers and bases (ancients);
  • LAN play only (no internet);
  • Hero leveling (increasing damage and armor, but no items or abilities);

We started at 9:30pm, and finished at around 4:30pm the next day (so it was actually 17h only). We also kept a LOG of the development process, and here’s a detailed account of how we evolved from studying network code to the finished project:

9:32pm – Init

  • First things first: searching Google about how to develop a LAN multiplayer game in Unity;
  • Reviewing MOBA concepts, so we can choose the fundamental features better;
Searching for references

Searching for references

9:51pm – Announcement

  • Publicizing that we accepted the challenge by posting in our facebook page;
  • Decision about minimum features: single lane, simple animated graphics, one tower per team, creeps, single hero type with no abilities, but with leveling based on farming and denials;

10:03pm – Unity Project

  • Created a new Unity project, and started by following a networking tutorial on how to program a client/server game;
Creating a new Unity Project

Creating a new Unity Project

10:19pm – Basic client-server code running

  • Already moving a simple Cube in the server, and visualizing the movement in the client;
Basic client server

Basic client server

10:29pm – Client-server control objects

  • 10min later, we were experimenting with game object control modes (distributed vs. authoritative server – haven’t decided which one to use);

10:38pm – 15min Pause for a snack…

11:11pm – Authoritative server

  • We decided to have an authoritative server, client will send input for heros (clicks), all processing happens in the server, and then is sent back to all clients;
  • Creeps AI will run solely in the server as well;
  • Created a “level” with a simple map (a plane for start);

11:32pm – Waypoints

  • Basic creep code done, running server only (view at the clients);
  • Coded the basic waypoint system, so we don’t need a complete pathfinding solution;
  • Tested everything with proper client-sever status and physics extrapolation (dead reckoning);
Waypoints system

Waypoints system

0:21am – Clicks

  • Hero movement based on clicks and ray casting. Physics runs on server, clients only send the clicks. There’s still a bug and the client is not updating correctly;

0:27am – One more pause…

1:34pm – Prefabs and movement

  • Created prefabs for creeps and heros;
  • Corrected the movement bug in the hero code;
Creeps and heros

Creeps and heros

2:36am – Attack

  • Now creeps choose targets and attack;
  • And heros can click on targets as well (attacks have a configurable range);
  • Feeling very tired, and not sure if we’ll be able to finish everything in time;

2:52am – Basic GUI

  • Health bars, YEAH!
  • Now we believe it’s really working (synchronized health bars on both client and server);
Health bars

Health bars

4:22am – Scores, terrain and name

  • Keeping and showing the score;
  • Created a basic Unity terrain, with a “river” in he middle;
  • Some adjustments in the physics parameters;
  • Decided a name for the game: Mini MOBRHA (Multiplayer Online BrBr/HueHUe Arena);
Scores and a simple terrain

Scores and a simple terrain

4:38am – Pause for SLEEP…

9:22am – Back to work

  • Decided to make it fully multiplayer (not only two players);
Client server with almost all features on

Client server with almost all features on

10:36am – Leveling

  • Our friend Edmilson joined the party and helped a lot with some basic balancing ideas and numbers;
  • Leveling, damage, all working now… YEAH!

11:05am – Towers

  • Towers working, with same creep AI, but no movement (added damage and range);
  • We’re almost there (in terms of code);


11:46am – Annoying bugs

  • Suffering with stupid bugs (becoming tired);
  • Started more frequent gameplay tests (builds put in local network file-sharing, so friends can independently take care of the testing);

12:27pm – No more bugs

  • Solved all bugs: auto-kill hero not happening anymore, involuntary movements, etc;
  • Better range handling;
  • Bases added (same code as towers and creeps, but with no movement or attack);

12:40pm – Pause for lunch…

2:42pm – Characters

  • Received the animated character prefabs from the designer (he was adapting them from another of our games);
  • Walk, idle, hit cicles, etc;
  • Blood particle system (with prefab and network instantiation);
Fancy character models from our Cangaço RPG game

Fancy character models from our Cangaço RPG game

4:36pm – Shots

  • Line renderer for shots;
  • Better detailed terrain;
  • Tested multiplayer (more than 2 – we tested with up to 4 clients)

4:47pm – Scenery

  • Props, towers, shadows, etc;
  • Random Music Player script by Jefferson Henrique (another programmer at Sertão Games);
  • All done (in less than 24h actually);
Finished game (17h work)

Finished game (17h work)

We hope you all can make good use of this free project. We kindly ask you to let us know if our code is being used in one of your projects (we’d love to showcase your work here as well).

Isometric Tilesets from 3D Modeling (with Blender and Photoshop)


For our now game, Fields of Gore, we are going to create loads of isometric (actually dimetric, that gives you perfect 2×1 clear diagonal lines) tilesets for the several battleground settings the game will include. This is a challenge in terms of art production efficiency, and we decided to use the pre-rendered-3D-models approach because this allows us to easily modify and recreate all the assets from the original 3D models.

For a start, this great tutorial from Clint Bellanger (part 1part 2) will teach you some of the basics, including setting up Blender to correctly render your 3D models as isometric tiles. The goal of our tutorial is to complement Clint’s by showing more details of how you can create seamless isometric tiles with this approach (tiles that go well side by side, and can be combined in different ways).

We also put a great deal of effort on automating, so after the initial setup is done, the whole process of generating individual tile images and combining them into one tileset can be done in a couple of clicks.

You can download the original tutorial source files, so you can follow each step.
For this tutorial, you’ll need Adobe Photoshop for automating the combination of tiles into a tileset (but you can also do it with free software, such as Gimp); Blender for 3D modeling and isometric tiles generation (we’re using version 2.6); and the Tiled map editor for trying out your own tiles.

01 – Setting up Blender

Most of the steps shown in this first part are already covered in Clint Bellanger’s tutorial, but we’re going through them so you don’t forget to check if everything is in place. We chose to use a tile-size of 128×128 pixels, because we want to have some detail and support small vertical structures in a single tile (elevated ground, etc).

Basic render properties: 128x128, 100% resolution

Basic render properties: 128×128, 100% resolution

Now select the camera object and bring up its properties by pressing ‘N’. Place it in a ‘diagonal’ position from the scene origin (I use X = 10, Y = -10). You’ll need to setup the Z value according to Clint’s tutorial (for the tile style and size we’re using, we ended up with 8.1625). The angles MUST be 60 degrees for X, 0 for Y, and 45 degrees for Z. This will transform the grid squares into perfect 2×1 diamond shapes.

Camera object properties: position and angles.

Camera object properties: position and angles.

You also need to change the camera properties (camera tab) to orthographic, and setup the scale. For our settings, 1.4 worked well.

03 - camera-properties

Camera tab properties: orthographic and scale

02 – 3D Modeling

For a basic sandy ground, we wanted to have nice slopes with all the possible types of corners. The only way to achieve this is to start with a seamless ground texture, and create the ground block around it. In the picture bellow, you can see the basic block that will make 9 different tiles (the center ground-only block, 4 ‘outside’ corners, and 4 side-slopes). Notice that the quads that form the basic ground tile are selected. We’ll separate these 9 parts later on.

05 - 3d modeling

Basic 3d block for the sloped ground tiles

We chose to have the unitary grid unit to represent the ‘virtual block’ on our isometric tileset, so we place the quad that makes the center ground-tile exactly above the first grid square (this will make the camera setup easier, even when you have elevated tiles such as this):

06 - positioning

Align tile with grid

07 - camera view

Camera view: not a clear tile yet

At this time, the camera view still doesn’t give as a clear perspective of our tile. Now we need to separate the different parts (later we’ll use Blender’s animation features to automatically reposition the tiles and render them). For this setup, separating each tile by a blank grid square is enough to clear the camera from picking undesirable parts from other tiles.

08 - 3d split

Separating the different tiles in 3D

This is how the end result should look like from the top view (7 on numpad):

09 - end result top

03 – Automating tile rendering

Now we have a clear render of our center tile from the camera view, but we need to render all different tiles (9 in this picture). We’ll use Blender’s animation feature for this. What we need to do is to create a keyframe for each tile that needs to be rendered, moving the tiles to the front of the camera (or the camera itself on X and Y), each at a time. You can create a keyframe by pressing ‘i’ (remember to choose ‘location’ as the recorded attributes for the keyframe).

10 - end result camera

First keyframe: a clear render of our center tile

Remeber to move the animation cursor to the next frame on the timeline before creating a new key frame. You can also automate this process by pressing the ‘record’ button on the timeline. Here we can see the next rendered frame (since each tile is separated by a blank grid square, we move the objects by 2 units on either X and/or Y for each new keyframe – this EXACT movement is mandatory, or you’ll end up with tiles that don’t fit together).

11 - moving objects

Moving the objects and creating the keyframes

When you press ‘animation’ at the Render tab, Blender will create a nice PNG file for each keyframe (the output folder and file format can be chosen in the same tab):

12 - PNG frames

05 – Automating the tileset composition

There are other tools to do this, but here we show how you can combine all the tiles into a single tileset by using photoshop’s automation features. We’ll show a step by step process, but you can make it work with a single click by ‘recording’ these steps into a ‘action-batch’.

Firstly, you need to load all tile images as layers into a single image. You can do this by using the option File -> Scripts -> Load Files Into Stack. Choose all tiles, as shown bellow, and they will be loaded into layers.

13 - photoshop layer stack

PS’s ‘Load files into stack’ feature

14 - tiles loaded in layers

Tiles loaded as layers

To align the layers side by side, we included a photoshop script in the project source files. Just go on File -> Scripts -> Browse, and load the script:

15 - open script

This script will resize the canvas and perfectly align the tiles into a tileset. You can modify the number of columns by editing the script itself.

16 - tileset ready

A nice tileset as the result

You can now use your newly rendered tiles to create isometric maps with Tiled. With our setup, you must create a map with a tile-size of 128×64 (2×1), and load the tileset as 128×128 (because of the vertical clearance):

17 - map editing with Tiled

Using the tileset

We hope we’ve liked this tutorial. The graphics included are based on free stock images from the internet, and will not be part of our final game. You can use the material anyway you want.

Tilemap Loader for HTML5 Canvas (EaselJS)

For the new game we’re working on, we developed a TMX tilemap loader and renderer to HTML5/Canvas (using the awesome EaselJS, from the CreateJS suite). Now we decided to share it with you (download link), since we haven’t found a similar one online.

Tilemap being edited on Tiled

Tilemap being edited on Tiled.

Disclaimer: Tilset by “Yar” (image found at OpenGameArt.Org)

We use the popular Tiled map editor (mapeditor.org), and the loader currently works for tile layers only, supports a single tileset (but it is easy to extend it to multiple ones). You just have to export the tilemap in JSON format (export -> json on Tiled). In the source code, we  included the JSON mapData at the end of the Javascript file, but you can easily load the map-files asynchronously as well.

Here’s the result on HTML5 Canvas:

HTML5/Canvas Tilemap loader

HTML5/Canvas Tilemap loader

The loader is free to use and modify. You can download the full source code for the sample above and have a go. If you want to say thanks, just include this in the credits:

  • Original tilemap load and rendering code by Erick Passos (CTO at Sertão Games)

Porque Nós Jogamos

Por Donald Wilburn

Todo mundo joga. De seu chefe até sua avó, do jogador casual de ‘Angry Birds’ até o viciado hardcore de ‘Call of Duty’, desde quando uma criança começa a raciocinar, todo mundo joga. A questão é por quê? Por que jogar é a única característica, além das básicas e necessárias para sustentar a vida (respirar, comer, dormir, etc), que nós membros da raça humana compartilhamos? Também é possível argumentar que o jogo não se limita à raça humana, e que até mesmo animais jogam. Pense nisso. E se alguém chegasse à conclusão disso ser verdade, então também poderíamos dizer que o conceito de jogo nasceu antes mesmo da era dos homens. Você pode puxar os cabelos e dizer que “games” e “jogar” (no sentido de se divertir, do inglês “to play”) não são a mesma coisa, porque os animais não usam um conjunto de regras definidas quando “jogam”, o que é mais aceito como a definição conceitual de um jogo. Mas … eu não estou aqui para discutir isso. Ainda.

Embora devamos logicamente supor que jogos escritos, como o Jogo da Velha (ou variações), foram os primeiros a existir, o primeiro jogo feito pelo homem de que se tem registros apareceu por volta de 3500 AC no Egito e era conhecido como “Senat” ou “o jogo do passando”. Logo a seguir surgiram jogos (ou variações) como damas, xadrez e jogos de cartas. Mesmo o tão amado Nintendo de muitas das nossas infâncias começou como uma empresa de jogos de cartas. Inclua esportes em algum lugar nessa mistura e é novamente evidente que não somente todos jogam, mas fazemos isso desde a aurora dos tempos. A próxima evolução em jogos viria a ocorrer na década de 1940, com um simulador de vôo grosseiro, usado para treinar pilotos de caça durante a Segunda Guerra Mundial, conhecido como o “Cathode Ray Amusement Device” (dispositivo de raios catódicos para passar o tempo), o que nos traz até a Era Moderna dos Jogos Eletrônicos.

Mas a questão ainda permanece: Porque Nós Jogamos? A resposta é tão variada e complexa como a sua história, não obstante o meu resumo de um parágrafo. Inúmeros livros e artigos têm sido escritos sobre o assunto, mas como o parágrafo anterior, vou tentar resumir ao bater os pontos mais relativos. Sendo quatro:

Entretenimento. Esta é a razão mais óbvia. O cérebro humano precisa tanto de distrações das pressões do dia-a-dia como se precisa do sono para continuar funcionando em um nível saudável. Quer seja a caça ao javali ou cuidar das crianças, a mente precisa escapar da monotonia, da responsabilidade. Isso também se enquadra nas categorias “diversão” e “escapismo” que, obviamente, incluem de tudo, de filmes até livros e outros hobbies pessoais, não apenas jogos.

Competição. Este é outro grande motivo. Nosso desejo inato de ser melhor do que o próximo homem (ou mulher). A definição básica para qualquer jogo é que deve haver um vencedor definido e um perdedor. Semelhante à adrenalina que um jogador sente, nós amamos colocar os nossos egos em risco. Quer se trate de esportes, jogos de tabuleiro, ou single player vídeo games, ou jogos de cartas, há sempre algo a perder, ou melhor, vencer. Isso alimenta o nosso senso de auto-estima e aprovação. No entanto, esta é muito específica em video games, por ser um dos poucos mecanismos onde se pode competir sozinho. Quando o jogador não está tentando ser melhor do que o homem ao lado, e sim ser melhor do que ele mesmo, ou você poderia dizer, um programador.

Companheirismo. Outra necessidade comum entre os humanos é a necessidade de interação com os outros. Pode-se argumentar que a companhia não é uma necessidade tão comum como era no passado, já que as pessoas parecem estar se distanciando dos outros cada vez mais nesta era da internet. Eu, porém, discordo. Embora seja verdade que as pessoas estão se tornando menos sociáveis no sentido tradicional, é importante lembrar a definição da palavra “internet” – conexão. Joãozinho pode passar 3 dias sem sair de seu quarto, mas ele provavelmente já falou, ou pelo menos interagiu, com muitas pessoas de alguma maneira, sem realmente ter dito uma palavra. Jogos, na sua forma pura, são outra forma de interação social. Novamente, como com a competição, pode ocorrer consigo mesmo ou com os amigos, de qualquer forma que nos permita se relacionar com os outros em algum nível.

Controle. Outro ponto que se aplica a todos os jogos, mas é muito emblemático em video games é a necessidade de controle. Ainda mais especificamente, os homens têm necessidade de controlar o seu ambiente. Isso pode até chamar de volta para nossos instintos animais e dá-nos ideia de porque animais jogam. É bem conhecido que homens valorizam o controle mais do que as mulheres. Isso explicaria o porquê dos jogos, seja esportes, jogos de tabuleiro, ou video games, parecerem ser mais populares entre os machos do que fêmeas. Isto aplica-se especialmente também ao elemento competição, como mencionado anteriormente. Um homem ser melhor do que o outro. Um sentimento de validação de sua auto-estima. Quando o mundo parece caótico e aleatório, que melhor maneira de receber de volta esse senso de controle do que apertar o botão ON, pegar um joystick, e derrotar Koopa pela 156ª vez?

Então, aqui estão, sem se aprofundar demais, os principais motivos de por que nós jogamos. Novamente, essas razões podem ser contestadas, discutidas e debatidas incessantemente. Como eu afirmei, livros inteiros foram escritos sobre o assunto. Mas a sua natureza central é fundamental para responder a essa pergunta: Por que nós jogamos? Por que todo mundo joga? Porque precisamos. Porque temos que jogar. Porque estamos vivos. Porque nós somos.

Claro, isso é apenas minha opinião, e eu posso estar errado. Até a próxima gamers…

Wargames e o advento dos RPGs

By Marcus Quixabeira (English)

Difícil falar em RPG e não lembrar da série japonesa Final Fantasy, sobretudo se você nasceu antes no inicio da década de 1990. A história de série começou em 1987 quando o também japonês Hironobu Sakaguchi, em uma tentativa FINAL de salvar a Square – que atravessava uma grave crise financeira – concebeu aquilo que mais tarde se tornaria o maior sucesso da produtora por todo o globo.

Dez anos mais tarde, em 1997, A série Final Fantasy atingiu seu apogeu com o lançamento do muito bem criticado Final Fantasy VII para a plataforma Sony PlayStation. Essa edição trazia tudo aquilo característico das edições anteriores: inúmeros personagens, cada um com suas próprias histórias, habilidades e conflitos; um mundo vivo, repleto de aventuras e perigos; excelente trilha sonora e mais algumas características que somente a tecnologia da época tornaria possível de se realizar, tais como, personagens totalmente poligonais movimentando-se em ambientes pré-renderizados e vários minutos de cenas em animação gráfica de qualidade estonteante para sua época, algo inovador e de extrema ajuda para o desenrolar da  belíssima história e suas reviravoltas. Não bastasse isso, FF VII apresentou inúmeras inovações para o sistema de batalhas, que apesar de ainda serem em turnos, agora eram apresentadas totalmente em 3D, com personagens e monstros super bem modelados, animados e capazes de encher as telas com explosões e cores de suas magias super bem ambientadas e condizentes com o universo FF. Todas essas características juntas fizeram do FF VII um divisor de águas e um marco no gênero de RPG eletrônico.

Final Fantasy VII (http://www.gamershell.com)

Final Fantasy VII (http://www.gamershell.com)

Certo, mas e agora eu lhe pergunto: Como e quando esse tal RPG surgiu? Se você já sabe, ótimo, é possível que você já tenha se aventurado por aí com um grupo de amigos, derrotando orcs e kobolds saqueadores em alguma masmorra abandonada, ou salvando uma donzela indefesa de um mago insano e seus capangas enfeitiçados. Se não, ótimo também, pois você agora vai conhecer um pouco mais sobre esse jogo, hoje tido como um gênero e com quase quarenta anos de existência.

Antes de tudo é necessário saber que RPG não surgiu com Final Fantasy. RPG ou Role Playing Game, que ao pé da letra significa jogo de interpretação de papeis ou personagens, é um jogo de mesa e surgiu oficialmente em meados da década de 70, bem antes dá excelente série eletrônica FF. Os primeiros RPGs foram baseados em historias e mundos fantásticos como os de J.R.R. Tolkien e criados a partir de outro tipo de jogo também de mesa bastante comum, os Wargames. Em um wargame, os jogadores controlam exércitos que são miniaturas ou outros marcadores, por uma região repleta de inimigos, comumente um tabuleiro quadriculado, a fim de cumprir uma determinada missão utilizando-se de bastante estratégia, alguma sorte nos dados e combates massivos. Alguém aí se lembrou do famoso War? Pois bem, é um excelente exemplo de wargame e o nome diz tudo.

 De uma forma bastante resumida, os criadores do RPG (Gary Gygax e Dave Arneson) alteraram e expandiram os wargames – que tem sua essência restrita ao combate e à estratégia – adicionando a ele um conjunto de regras que iriam permitir que os jogadores criassem seus próprios personagens, os interpretassem e agissem como quisessem, viajando, aventurando-se e combatendo monstros terríveis nos mais variados tipos de ambientes, dentro de um mundo e de uma história contada e criada pelos próprios jogadores. Tudo acontecendo em suas imaginações.

Foi com o advento dos wargames e posteriormente com o surgimento dos RPGs que surgiram os inúmeros conjuntos de sistemas, regras e termos bastante conhecidos nos jogos eletrônicos de hoje tais como batalha em turnos, health ou hit points, classe, raça e tantos outros termos bastante corriqueiros. Esses dois tipos de jogos influenciaram e ainda influenciam muitos jogos eletrônicos produzidos atualmente, gerarando no decorrer dos anos inúmeros gêneros variantes – como os jogos de Estratégia em Tempo Real, os Tower Defense (plants vs. zombies, pessoal) e os RPGs de Estratégia – e arrebatando milhões de fãs por todo o mundo.

Os Wargames eletrônicos (e também RPGs de Estratégia) ou os de mesa são ideais para aqueles jogadores que procuram um jogo onde sejam necessários o uso de bastante estratégia, gerenciamento minucioso de recursos, ação em turnos e muito desafio. Vai encarar?

Wargames and the birth of the RPG (translated by: Erick Passos)

It is difficult to talk about RPGs and forget about the japanese series Final Fantasy, especially if you were born before the early 90s. The series´ history began in 1987, when Horinobu Sakaguchi, in a FINAL attempt to save Saquare – then in a severe financial crysis – has conceived the game that would later become the publisher´s largest success.

10 years later, in 1997, the Final Fantasy series reached its apogee with the release of the righly regarded FF VII for Playstation. That instalation brought everything that made the series what it was: lots of interesting characters, an alive world, full of dangers and adventures, an excelent sound track, and the most impressive rendered CG of the time. Besides all that, FF VII brought innovations in the battle system, that were still done in turns, were fully presented in 3D, with lots of explosions, colors and details. All those features made FF unique in the electronic RPG genre.

Well, but now I ask you: how and when were this RPG genre born? If you already know, great, it is possible that you´ve already adventured around with a group of friends, killing orcs and raiding kobolds in an abandoned dungeon, or maybe saving an innocent lady from an insane wizard and his enchanted bandits. If you´ve not, it is also great, now you´ll get to know more about this type of game, now almost 40 years old already.

To summarize, the creators of the RPG (Gary Gygax e Dave Arneson)  changes and expanded wargames – which are restricted to strategy and combat – adding a set of rules to enable the players to create their own characters, to role play them at will, traveling, adventuring and challenging menacing monsters in a world and story that is also created by the players themselves. All depends on your imagination.

First of all, Final Fantasy was not the birth of the RPG. Role Playing Games are board games that were born in the midle 70s, long before their electronic counterparts. The first RPGs were based on fantasy stories such as those of J.R.R. Tolkien, and derived from other type of board game, the Wargames. In a wargame, the player controls armies or groups of soldiers, often represented by miniature figures, normally in a regular cell-board (square cells, such as chess; or hexagonal). Wargames rely on lots of strategy, and sometimes some luck on dice. Does anybody remember the boardgame war? That is one of the most famous wargames ever created, but there are many many more.

With the advent of wargames, and later theRPGs, that the countless systems and sets of rules of today were born. Terms such as turn based combat, health and hit points, class, race, and many others. These two genres are very influential to many nowadays electronic games, producing many derivative genres such as real-time strategy (RTS), tower defenses (plants vs. zombies everyone), gathering milions of fans all around the world.

Electronic wargames (and also strategic RPGs) are ideal to gamers who want to stress their brains on strategy, resource management, turn based action and lots of challenges. Are you ready?

How to Create a Board Game in 48h

Sertão Games recently participated in the Virada Geek event, where a lot of people got together to spend all night long playing games, surfing the internet and discussing nerd stuff. Taking part in the event was not part of a plan, but we were offered the opportunity to have a booth on site and grabbed it.

The event was 3 days ahead of us, and we started our popular brainstorming section to discuss what to do during the event. The first idea was to move our “office” there and create some assets for one of our upcoming games on site, showing the crowd how our development process works.

But then, on the following day (48h ahead of the event), our lead designer Wan suggested we could assemble a board prototype of our most beloved project: a turn-based strategy game, set in the Sertão (hinderlands) region of Brazil, during the Cangaço movement, when several armed groups dominated the region, until the formal government managed to put an end to it around the late 1930’s.

We decided it was a good idea and set to work immediately. We had an early 3D prototype with turn-based path-finding and movement implemented, plus part of the game design already set, such as character’s attributes and some balancing numbers, but nothing ready for a gameplay section yet. To create a paper-based board prototype, we had to divide the team into the following tasks:

  • Drawing sketches for the characters, obstacles and scene objects (such as wells, rocks, houses, cactuses, etc);
  • Scanning, image-processing, aligning and printing the sketches in thick paper sheets;
  • Hand-painting, glueing, cutting and assembling the paper pieces;
  • Writing the game rules;
  • Ordering Sertão Games-branded T-shirts, putting a poll-form together, organizing the schedule, plus sharing stuff on social networks to create a buzz prior to the event.

Here’s a picture where part of the team is working on some of these tasks:

Sertão Games team working on the board game prototype

Sertão Games team working on the board game prototype. The hexagonal game map can be spotted in the middle of the table.

The paper pieces (part 1 – sketches)

We had a very important decision to do the sketches by hand (instead of using Adobe Illustrator), so we could have them finished faster. Of course we wanted to have a nicely crafted prototype, but it didn’t have to be an art piece just yet, so this is how the sketches  for the props looked like, just after scanning:

Cactus and well sketches

Cactus and well sketches

Other objects. All sketches were hand-drawn.

Other objects. All sketches were hand-drawn.

For the characters, Wan worked on a base model and used variations to create the 3 types of unit we wanted. We decided that the two teams would share the same unit types for the prototype, and a different color would differentiate them. Having only three different characters made it easier to finish the sketches on photoshop, such as the following image shows:

The "snipper" cangaceiro after being cleaned up in photoshop

The "snipper" cangaceiro after being cleaned up in photoshop

The paper pieces (part 2 – coloring and assembling)

In the end, the sheets contained mirrored printings of 12 characters and 15 doubled-sided objects, plus 20 flat figures for terrain modifiers, totaling 74 figures to paint by hand with color pencils! It took two people and 10 hours of work to finish all the coloring. The results, however, would payoff during the play-test sections. This is how the sheets looked like during the coloring process:

Character Sheets after all coloring is done, by hand... Hard work!

Character Sheets after all coloring is done, by hand... Hard work!

Colored sheet with other props. My wife Cintia helped with some of the coloring here.

Colored sheet with other props. My wife Cintia helped with some of the coloring here.

Given that no one can really trust a printer tray, assembling the vertical pieces meant the mirrored figures had to be aligned by hand against a strong light source (thick paper, remember), and glued together. Since we only had one set of colored sheets, this was a very delicate part of the process.

After being glued, the sheets were put to dry under some books, in order to keep them flat. We decided that some of the figures would have miniature buckets in their bases to keep small colored pebbles, representing health, resources and other attributes. The now cut vertical pieces were glued to cardboard hexagons, together with the mini-buckets were needed:

Cactus and other props assembled and positioned on the hexagonal game board

Cactus and other props assembled and positioned on the hexagonal game board

The complete board, with some of the characters in place

The complete board, with some of the characters in place

The game rules (not the rules themselves, but how I wrote them)

The team had already discussed some early game design for this particular game, but it was far from done, and we haven’t even implemented a prototype of it before, so the ideas weren’t tested yet. During the brainstorming two days before the event, we decided for very simple rules for two players, involving three game modes, one resource (water), two terrain modifiers (elevations and water courses), movement and attack (with reaction).

But even these very simple rule system took 6 pages, and we were a little afraid the gameplay was too complex for a crowded place, with loud music and several other distractions. To make it worse, the mini-buckets were very nice, but it meant that all attack interactions involved counting pebbles, emptying the bucket and filling it again. We were really not expecting this to be a first time hit.

I was assigned with the writing (plus a lot of other stuff), and the rules were done in about 1 hour, since I had already studied several similar games and the set of rules was more or less set in my mind before starting to type. It seems the basic set of rules are good, given that we only had to do two minor balancing modifications to the character attribute table after the first matches to make the game more fluid.

The reception

We got to the event early, and our booth was set before anybody could get in. This was a nice move from our part, and many of the early attendants showed up to check out what was that board game assembled in the middle of a PC-infected arena. The design of the pieces also caught the attention of the public, and showing pictures of those who were playing our game in the projector was also nice:

This is how the play sections looked like.

This is how the play sections looked like.

People having fun...

People having fun...

The feedback was AWESOME, and we’d like to thank to the organizers and the player who gave a lot of nice suggestions. A couple of game modes and features that were experimented with were evidently fun and we really plan to include them in the final game.

Board prototyping "roolz"...

Board prototyping "roolz"...

The board prototyping was a complete success (and yes, the paper pieces survived intact – we’ll keep this particular prototype for ourselves now) and we strongly recommend this type of experience. We even managed to finish most of the work the night before the event, giving some time for extra polish and preparation.

We’re so excited about this that we’re even thinking in releasing a board version of the game. If it proves not feasible for a commercial release, we promise to make the game rules public, together with the paper sheets in PDF, so anybody can set up a board. Of course we’ll also have the 3D version of this game, and it will be even more awesome.

As mentioned in the previous post, we’re also working on an bug-themed game for tablet devices, and we’ll be giving updates on these two. Stay tunned.

Sertão Games Team (from left to right): Erick, Jader, Wan, Diogo and Alan.

Sertão Games Team (from left to right): Erick, Jader, Wan, Diogo and Alan.

See you soon…

New games on the way

This post is full of news… We’ll briefly talk about two brand new games that are currently under development at our studio: Bugs and Cangaço.

Mr. Ladybug

Your friend Mr. Ladybug

Bugs… Lots of bugs in your iPad screen… But you won’t smash them this time. They’re your friends, you’ll help them collect food for surviving the incoming winter.

This is the new game we from Sertão Games are working on. There’ll be line drawing, strategy and tower defense mechanics all in one.

Bugs is in one word: FUN! Check our friends’ first reaction to a very early prototype of only one of the mechanics:

They seem to be having fun...

They seem to be having fun...

Bugs is based on new game mechanics and balance and is being developed with all our passion. In the following posts, we’ll share our progress as we go. But this is not the only news we have:

Cangaço is becoming a reality. Cangaço is the working title of a brand new game that tells the story of the almighty cangaceiros, the rulers of this remote region, that gives its name to our studio, during nearly half a century. Cangaço will be the first 3D game from Sertão Games and will be released simultaneously for PC, Mac, iOS and Android. Stay tunned for the next announcements.


Ready to take control of your team of cangaceiros?

Blog series: my gaming history (part 2 – Jader)

My True Game Story

“The ways that game design meaningfully connects to the many experiences in your own life…”

Jesse Schell, in The Art of Game Design

This post was written as a kickstart for my personal blog and replicated here at the Sertão Games website. I’ll talk about my personal experiences as a gamer and tell a little bit of this new journey as a game developer, which just begins to play its magic in me. Continue reading