2D Movement Framework

I some time ago tried to do a 2D platforming game. Kind of like Mario, except that it would include all other features like double jump, wall jump, sliding, one-way platforms, rail-like ramps, gliding etc.

The problem is that you usually want a very specific and precise movement for this kind of games, so it could not be physics-driven.

What I ended up doing is an easy to extend framework for that kind of movement. You can take a look at my github page (Bear in mind, though, that it is a little out dated right now).

It’s core element is the CharacterController2D component, which is my own version of the built-in CharacterController just for 2D and made with raycasting. That component is then used by the PlayerMovement abstract class to control the movement.

PlayerMovement is abstract because you usually will want to override its default behaviour to implement your own. In the code is an example of a movement type for a character named JoanaMovement.

Joana, for instance, does not get accelerated when falling, that is, she always falls at the same speed. She can also dash infinitelly and, after jumping twice (her maximum amount of jumps) she can glide to fall even slower.

Joana is only an example of the wide variaty of combinations and behaviours available with the Framework.

The Framework is still not finished, as I would like to add more features, but it now covers the basics.

Hack and slash

Some time ago I wanted to experiment with a wave system. I mean wave in terms of enemies incomming in a succession of waves, kind of like rounds. These waves would compound a level.

So, in short, I wanted every level to be a succession of waves. Every wave would have a list of enemies and the amount to spawn of that type, so, every fixed amount of time, a new random enemy would be spawn. Once that wave has no enemies left to spawn, the next wave would commence. FInally, I also wanted every type of enemy to spawn in a specific location.

Here is a screenshot of the Level component:

Note: A custom editor would be helpful, I know, sorry for the hard to read content.

Every enemy will only spawn in one of those locations, randomly.

Every wave or “Round” has a specific amount of each enemy to spawn.

Finally, in order to test it, I made a little hask and slash game with hit and run mechanics. You can download the .apk here (To start the waves, you have to push -attack- that button on the upper right part of the level). The game asks for read phone state and internet connectivity permissions. It’s a known Unity 5 bug, so sorry about that.

Symbolic Links

Unlike Linux, which, as far as I know, has it built-in and uses it as a core functionality; Windows does not have a propper way to make symbolic links.

As a programmer, I find symlinks to be an essential tool for code reusability; and so I looked for a way to achieving it in Windows.

The first thing I did was creating my own tool. With it, I could make a symbolic link of any folder. However, the procedure was a little slow and not as fluent as I would like, so I searched for an alternative.

And so I found Link Shell Extension. A Windows shell extension that ads  a “Pick Source Link” option to the right click contextual menu. You can later use that link to create a symlink wherever you want.

With that, I can easily have my own repository for commonly (and usually indispensable) used scripts, tools and extensions among all my Unity projects.

My own Repository

Untitled Card Game Update 4

Current Situation

We have now been extending game mechanics for over two weeks: We have been adding buffs and abilities to the game. These new mechanics have deepened and widened the core gameplay and, more importantly, have added endogenous gameplay.

With these additions, and though we still have a bunch of new features on the roadmap, we think it is sufficient for the game to keep expanding and so we decided to focus on other things. The main think we want to focus on is playtesting. Now, testing the game means that we need to have a playable environment to run the game, and that means we first need to prepare that environment. What do I mean, you ask?

WebGL

We want the game to be playable mostly in the web through WebGL. That would be a real environment.

We started making the networking system using mono/net sockets as it was the only thing we knew. We didn’t look for info about whether we could use those sockets on a WebGL environment, but why would we? Be are still noobs in the vast field of networking, so why would we think there could be any problem? Shame on us. For security reasons, WebGL doens’t support standard mono/net socket connectivity; so we had to look for a workaround.

Fortunately, we found WebSocketSharp, and we are now implementing it. It was a headache at the beggining because the lack of good documentation, specially for the server-side; but once you get to know how it works, it really is amazing.

We have got it almost working now, so maybe by tonight it will be fully implemented.

The Web

In order to be able to launch the WebGL client, we first need to have some kind of webpage. So that it the second step, working on the webpage. In the beggining, we won’t be doing any user registration or implementing the lobby I described in a previous post; but we will need to later on.

The Client

Yes, the client. For a while now, we have focused our eddorts on the server, implementing all the new features and logic. That, however, is not mirrored in the client, where the player sees the action. We need to implement a lot of things in the client, specially propper representation of cards and creatures, and their actions and abilities. Also, a lot of work about client prediction needs to be done.

Basically, we need to reflect everythings that happens in the server on the client if we want to simulate a real environment.

Editor

Finally, a real play environment means a real deck of cards, and, for that we need to make a better card’s editor.

We already have one, but, honestly, it kinda sucks; and it’s only a little better to make cards on the editor than it is on the .dat files. I need to make a far better editor

So, once we are done with these four points, we will be good to playtest =)

Untitled Card Game Update 3

A Glimpse Over the Gameply
Card games are usually turn based games, and this is no exception. The turn is structured, cronologically, as follows:

Start Phase: In this phase, the active player and his/her creatures get their actions count reset. It is at this point, too, when effects that trigger at the beggining of turn apply; including vitals regeneration.
Draw Phase: After the start phase, if still alive, the player draws up to two cards from the deck. He or she then puts one of those cards in his hand and the other at the bottom of the deck.
Main Phase: It is at this point that the active player can interactuate with his or her hand, spells, and creatures. I will explain this step more in depth in the next section.
End Phase: When the time runs out or the player voluntarily end the turn, this phase starts; triggering all end-of-turn effects. Also, all buffs’ turn count are decreased by 1. After that, the active turn is passes to the opponent.

And then, each player has the following core elements:

Vitals: Vitals are needed in order to survive, and are shown next to each player’s avatar. The red one is the health, when it reaches 0, it’s game over. Blue represents mana, which is used to play cards. And orange is meant for Fury, which is what you need in order to use a creature action.
Deck: The deck contains all of your available cards. If you run out of cards, you won’t be able to do much.
Hand: Your hand holds all the cards avilable for you to play. For now, there is no maximum.
Spells and Objects: Every card learnt through a golden card is displayed next to your avatar and under your vitals. These are actions that the player can play without any cost during his or her turn.
Field: The field is actually diveded in two sides, yours and enemy’s. Each side is divided in three lines, each containing a different number of cells (this is what we call the formation. Formation is meant to be customizable through the lobby in the future. For now, we test with a 3-5-3 formation, from front lane to back lane).

Main Phase
Here is where the action takes places. During this phase, the player can play cards, as long as he has mana, and use some of his spells or objects.
When playing a summon card, the creature can only be summoned on the back or middle lane, on an empty cell. Usually, creatures cannot perform any action on the same turn they are summoned.
On the contrary, if the player plays an action card, an action is executed. An action can be applied only to certain targets within a certain range, which are determined by the action itself. The action, when used, applies an effect to the target.
There is a wide range of effects available, and they form the core gameplay of the game. Effects range from varying a vital’s value (that is, draining mana, healing a creature or doing damage etc.) to moving a creature or applying buffs/debuffs.
Morover, the player can also play some of his/her creature’s actions, as long as that creature still has some moves left. To do so, though, the player has to have enough fury, but actions are then executed in the exact same way as explained above. Some of the actions a creature can have are moving, attacking or healing.

Each player has an amount of time to complete the turn, if the time runs out, his or her turn is atomatically skipped.

Untitled Card Game Update 2

Graphics
Our next step into development was to create some sort of graphical interface that would help us develop and test faster and better. That interface would also probably be very similar to the one we wanted our players to play with, so we basically created the graphics and the inputs for the game.

Here is one of the first versions:

And here is the current version:

Note: Altough the current version is notably better than the first one, I have to admit it is far from perfect or even decent. Having said that, I also have to say that I am no artist (not even a stickman artist), hence the placeholder graphics (that cat from the internet and the back of the Hearthstone cards). For now, this is more than enough to let our tests and development proceed.

Cards
Regarding the graphics of the cards, which are created procedurally, we have made several concepts, but none of those have been implemented in Unity yet. In the picture above, those black rectangled with white letters on it are the cards. They suck, I know, but I am proud of them :)

Up until then, we had been hand-crafting our cards manually through a text file, and that probably is the reason why we only had two differents cards (one action and one summon). In order to progress through both development and testing we had to figure out a way to make cards faster, and so we decided to make a card editor.

Card Editor
In the end, info about cards is stored in the database, so the editor would need to fetch data from and to the database, but we also wanted to be able to make cards from anywhere, even if the database was not present. So we decided to keep those text (.dat) files we had been using as a protocol: A third program would convert all the info about cards stored in the database to a .dat file, which would be read and overwritten by the cards editor, only to be then converted back again into the database.

This is how the cards editor looks. And, please, again, note that even if it looks ugly, this is not to be seen by the final player, so little more visual improvements will be made to this.

Untitled Card Game Update 1

I think it could be a good idea if I paused for a second and explained a little about the general architecture of the game instead of jumping right into the action.

What is it gonna be?
The player is going to represent a Summoner Master whose knowledge can no longer be extended and whose fame can no longer be grown by combat feats, only through the recognition of his or her apprentices. Each apprentice is viewed as a character, and thus can have a name, a sex, an avatar, a job specialization (here, the job specialization will only dictate the starting set of cards for that apprentice, and not further advantages or limitations), a deck and a set of Golden Cards. Academies can be created by the alliance of many Masters (aka Guilds), and apprentices can level up by duelling, thus gaining access to better Cards.

How is it gonna be?
We are going to have our players play through the web on two levels. The first level, called the lobby and built with html; and the second level, called the client and built with Unity to run on WebGL.

On the lobby, the player can manage apprentices, their decks, access the shop, manage his or her friends, view ranking, join or create guilds, challenge other players etc. Once the player has chosen an apprentice to fight in his or her behalf, the second level starts and the Unity client is launched to play on WebGL on both players and a server instance is executed to manager their particular match. When the game ends, the server fetches the information to the database, then the Unity client closes and the player is then returned to the end game screen, where detailed information about the match is shown.

For now, we are focusing on the Unity client, leaving the lobby and the web aside.

Why is it gonna be that way?
As mentioned in the previous post, we have already failed before, and we are not willing to risk it all again, that is why we are trying to keep everything as simple as possible. And by having the lobby management done in html instead of a part of the Unity client too is because it’s easier to access the database through the web; and we need to canstantly be fed with information from the database as it is where player, characters and cards info is stored.

Now, the reason why we have decided to store every card information on the database is, mainly, because updates done to cards (be it adding new cards, removing or editing them because of balance or whatever) are not directly reflected in the necessity to update the client. When the player plays a card, info about that card is fectched from the server and the card is build procedurally, thus not needing an update.

Regarding cards special effects, images or models and the alike, those are all downloaded at runtime via asset bundles, thus removing, once again, the necessity to constantly update the client or having very big server downtimes due to updates.

Untitled Card Game

Few months ago a friend of mine and I decided to make an online card game, some sort of TCG or CCG, similar to Magic The Gathering or Hearthstone:

The Game
The final versionof the game would feature a battle between two summoners (guided by the player) in a field devided in 6 lanes. Each player would have 3 lanes, and summoned creatures would move around those lanes and attack the enemy. Thus, the battle would consist in a rain of spells casted by the summoner on a battlefield full of creatures. The first summoner to kill the opponent would win.

Prior experience
We decided to make the game on Unity and the networking system on Mono/C#. A pair of years earlier we worked together on a multiplayer version of Pang: We planned on having the Master Server work only as a matches placeholder and let the in-game networking be handled by the creator of the match (aka Server) through UDP puncholing, with up to 8 player playing simultaneously with physics prediction and packet loss management and whatnot. We worked really hard and got pretty far (considering it was my first contact with any kind of networking system), but the project failed because the scope was too vast.

So we started this card game with prior experience in the field, even if little, but with the intention of finishing it, if only we managed the temptation of over-designing it…

Progress
In a matter of 3-4 weeks of hard-working, we had a simple yet effective interface for a TCP networking system implemented in the first playable version of our game: A server instance would run, two different game clients would connect and the server would manage their communication. The game would start and both players would be able to kill each other’s avatar.

Up until then we had dedicated all of our time, effort and attention to the networking; so we basically played and tested the game by running commands on a DevConsole I made time ago as an Asset for Unity.

Here is a screenshot of the firts versions of the game. No input, no interface, only the console. In the image, the black window is the server, the two upper windows are the clients.