• Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

My journey to becoming an independent game developer

Entries in this blog

Day 39

Mirrored from my blog (en, pt-br).

Today I started making the projectile. In fact as I couldn't think of anything much different just following the same style.


Testing the projectile with the gun I saw that the tip of the gun was not cool with that kind of projectile actually what was strange was that the rayCast modify the angle of the emptyGameObject which is the origin point of the projectile. When the gun was aiming at something near the projectile did not follow parallel with the "clamps" of the gun. In the end I ended up modifying the gun.

After I modified the gun I started working on modifying the script that manages the speed and mass, as there was no need to change a lot was quite easy.

In the end I ended up doing an animation. I did an animation of the gun shooting into Blender. The animation was very simple and the process of importation and use of animation in Unity was very simple too.


Tomorrow I will continue doing the gun and I intend to add some feedback of selected projectile.

[size=2]PS: Sorry for the bad english.

Day 37

Mirrored from my blog (en, pt-br).

Today I kept doing the gun. I don't have much to say, so I'll show the prints in order of modification:







Tomorrow I may change something in modeling and will start modifying the script.

[size=2]PS: Sorry for the bad english.

Day 36

Mirrored from my blog (en, pt-br).

Today coming back from a break of three days I started to make a new weapon. I thought of a gun Sci-Fi very simple in model and texture, so far I'm liking the result.

Today missed very little to finish the model, actually what ended messing it was that the middle button of my mouse stopped working (orbit in Blender).

Tomorrow I'll look for some old mouse that I should have here, and I believe I end up the modeling then I do a simple animation that will have and begin to change the script.


[size=2]PS: Sorry for the bad english.

Day 32

Mirrored from my blog (en, pt-br).

Today I did the stand.

The stand consists of four columns, floor and three walls. In the columns I used self-illumin with the texture of the floor with a slight modification to have lighting in the creases. In the walls and floors I used a transparent shader with the color specify of each stand.





After doing the stand I did a organization in the project eliminating all unnecessary assets (those used in the prototype and testing).

[size=2]PS: Sorry for the bad english.

Day 31

Mirrored from my blog (en, pt-br).

Today I kept doing the cube. After losing almost 2.5 days doing this cube I could reach a satisfactory result and learned a a bit of photoshop. So worth it.

Yesterday I had already finished the texture and just did not like the lighting, I was using the shader self-illumin and by far ended up being bad to see.

(Yesterday cube)


I started doing some tests using point light. I really liked the result, but ended consuming a lot of processing. Each cube ended up with 18 point lights (one for each point where has light in the texture), I did a test with 4 cubes (72 point light) and when the camera focused on the 4 the result was:

  • 4 FPS Without GPU (i7 2670QM).
  • 16 FPS With GPU (GeForce GT 540M).




    Although I liked I had to find another solution.

    PS: As the radius of the points lights was intersecting they was annulling eachother, I believe it is some algorithm of Unity for performance. To solve this I had to set the render mode to important.

    I ended up going back to self-illumin and doing several tests with texture and light map. After a while I got a result that I liked.



    As I did the middle light of the cube specifically to inform if the cube is with gravity, without gravity or with gravity inverted, I modified the script that manages gravity to change the material based on the status of the cube.

    In the video below you can see how the middle light changes relative of the gravity of the cube.


    [size=2]PS: Sorry for the bad english.

Day 30

Mirrored from my blog (en, pt-br).

Today I finished watching the tutorial Creating a Sci-Fi Panel. It was time consuming and difficult to follow, because I did not know to use photoshop. I ended up not liking the result in Unity and decided to start again (and make a slightly different model).

First model following the tutorial.


The second model was better than the first, but still not good. The idea was to use the lights of the edges to indicate the color of the cube and the middle one to indicate if the cube is with, gravity, without gravity or gravity inverted. But inside the Unity was bad to see the lights from afar.





Tomorrow I will change the color of the lights in the texture, to see if it improves, if not help, I will change the color of texture of the cube itself.

[size=2]PS: Sorry for the bad english.

Day 27

Mirrored from my blog (en, pt-br).

Today I started fixing a logic error in the winning script. The fix was simple and quick.

As I now have the mechanics working (minus the bugs that I did not find) I decided to start to refine the graph, leaving it the way I want, and leave the level design further forward.

I think a sci-fi theme fits well in the game so I started looking textures. I found a texture to the floor and found a very good program that makes space skybox, the Spacescape. Some of the examples that comes into it:



Then I started looking for the cube texture and ended up finding a very good tutorial, Creating a Sci-Fi Panel. I recommend.

Today I couldn't finish watching, neither tomorrow. So I'll just return on Monday.

Floor, skybox and the cube (the cube will look like, but that's not what I did).


[size=2]PS: Sorry for the bad english.

Day 26

Mirrored from my blog (en, pt-br).

Today I started refactoring the internal mechanics of winning leaving it much more flexible than it was before. Now when I do the level design will be much easier.

In the winning script I ended up using the singleton (design pattern [or !design pattern]). The singleton is basically a class that is structured in a way that can only be instantiated once. The class has a private constructor and a public get that returns a reference to the object (if not created yet it creates and then returns).

In winning script itself I added the maximum time to complete a level. If the player reaches that time he loses.

After this refactoring I created a script to remove the forces of the cubes (velocity and angular velocity) when pressed Ctrl. All cubes are affected simultaneously. This provides another strategic point, but the player has to know when to use, if he use to save a cube that will leave the level can end up affecting others who are in good trajectories.

Finally I created the script to remove and invert the gravity of the cubes. To remove the gravity the player selects the projectile corresponding and hits the cube with it, if hit again the gravity returns. To invert the gravity the process is the same. The two are independent, that is, if the player invert the gravity and then removing the gravity, and after that return to gravity it will be inverted.


[size=2]PS: Sorry for the bad english.

Day 25

Mirrored from my blog (en, pt-br).

Today I started fixing the bug of the rayCast of yesterday, it was taking in the triggers of the stands causing the crosshair misaligns up with the projectile. I added the layerMask and passed as argument to the rayCast to ignore the triggers, it was pretty easy to solve.

After that I continued the logic of winning. Now when the player put all the cubes in the stands is calculate the time, the penalty and the total time in seconds.

I'm thinking of changing the mechanics to have the maximum time to complete the level and maximum cubes that can throw out.

Another thing I added was the ability of the projectile to be destroyed after colliding with a cube or not. This increases the level of strategy, because you can use the projectile to reach more than one cube.

The most interesting thing today was the modification of internal time manager. At first that each object had to stop in time had its own variable saying if the time was stopped or not, and also had its own toggle that changed the value of this variable. Now it has a central script that has a static variable and its toggle. It also has a static event that notifies when the time toggle. To make the event I used the internal event system's C#.

Today has a playable demo.

  • Controls

    • WASD.
    • Scroll - Velocity
    • Ctrl + Scroll - Mass.
    • Shift - Toggle time.
    • Q e E - Toggle between min and max of velocity and mass.
    • K - Toggle between the projectile be destroyed at the time of collision with the cube or not.
    • Goal

      • Place the cubes of each color in the stand matching color with the shortest time possible.
      • Penalty for cube thrown out: 0.4s.

        PS1: Note1: In WebPlayer I put Screen.lockCursor = true. I don't know why it is not working.
        PS2: As I haven't studied anything about level design this demo aims to show only the mechanics.

Day 24

Mirrored from my blog (en, pt-br).

Today I started making a change in the look of sync, as I want to focus on the mechanics at the time I did everything a chess texture. I was pleased, because became standardized and acceptable.


Then I started to build a level of one of the possible modes of play. The goal will be to put cubes of each color to its respective place (call stand) with the shortest time possible. The count will be progressive with precision of hundredths of seconds.

Here comes one of the main mechanics of the game, stop time.If the player press Shift the time stops, "Freezing" all the movements of the cubes and projectiles in the scene. When the player shoot with the time stopped the projectile will be stopped and will come be to its trajectory when the time starts flowing again.

Using the stop time the player will be able to better analyze and give shots synchronized, which will make, strategy and calculation of the force of the projectile (mass x speed), be a major factor in the total time of the level. When a cube is thrown out the level time will be added to the total time as a penalty.

In this video you can see how this game mode is. (In the video doesn't have the time yet).


Doing the logic of game winning I found two bugs that was difficult to resolve.

The first was more a lack of my attention. After putting a Trigger in the level the cubes began to move in strange ways (video below).


At the end had nothing to do with the Trigger. What happened is that sometime before I added the DontGoThroughThings in the cube for it not pass the walls of the stand, but I ended up using the same layer that the cube is (In the script DontGoThroughThings the object using the script cannot be in the same layer that it will check the collisions). And as I was only testing after I added the Trigger I was thinking that the problem was with it, it was difficult to find the real problem.

To resolve this, as an object cannot have two layers, I had to use a workaround I found on the internet. Duplicated the object, removed the Mesh Renderer and placed as a son of the duplicate. Put a different layer in the duplicate. I didn't like this solution, but for prototype work, so I'll leave to search for a better solution later on.

The second bug, which was easier, but it also took a while was that at certain points the gun was becoming unaligned with the projectile, it happened because of some Triggers that was inside of the stand and took them rayCast. To solve this just use layerMask and pass as argument in the rayCast that it ignores this layer. But I'll leave it to do tomorrow.

[size=2]PS: Sorry for the bad english.

Day 23

Mirrored from my blog (en, pt-br).

Today I did some things in sync:

  • Color of the mass panel changed to red.
  • Q e E keys to toggle between min and max.
  • Change projectile mass with Ctrl + Scroll.
  • Projectile gravity removed.
  • Cube created.
  • Crosshair add.
  • Align between the crosshair and the projectile.
  • Apply the script DontGoThroughThings.

    Panel + Crosshair + Cube:


    Testing the prototype when it increased the speed of the projectile I realized that it was past the cubes to the point of not collide with any cube. Actually what was happening is that as the projectile was too fast, it not collided with the cube, if you go frame by frame you can see it. I researched and found the script DontGoThroughThings that solved this problem. Just put the script on the object that will move very fast and all the other objects that you want it to collide inside a layer and pass this layer to the script.

    Check out the results:

    • Without DontGoThroughThings (Online).
    • With DontGoThroughThings (Online).

      [size=2]PS: Sorry for the bad english.

Day 22 - [SinC]

Mirrored from my blog (en, pt-br).

On day 22 I did the GODD of the SinC, the CustomPlayer, and the gun shoot.

The first thing I did today was the GOD of Sync (Shooting Into Cubes [name that thought for now]). I will not explain how the GOD is, it is easier to see:

1. Executive
[indent=1]1.1. Game Type
The game will be a first person shooter puzzle.

[indent=1]1.2. Name
The name of the game will be for now SinC (Shooting Into Cubes).

2. Game Elements
[indent=1]2.1. Gameplay
The goal of the game is shooting into cubes in order to take them to certain areas. To do so the player will have a weapon capable of:

  • Change the projectile velocity.
  • Change the projectile mass.
  • Change the projectile impact.

    • Directional.
    • Blast.
    • Gravitational.
    • Remove gravitational force of the cubes.
    • Remove forces of the cubes.Invert gravitational force of the cubes.

      [indent=1]In addition to this weapon the player will also have the ability to stop time to prepare and plot the best strategy. While stopped in time the player can shoot projectiles, which also froze and returned to their trajectory when the time flow is restored.

[indent=1]2.2. Game Pacing
As the mechanics of the game will be very repetitive the game will aim to be casual, where the player doesn't need to follow stories and other elements.

[indent=1]2.3. Target Audience
The game will target audience of players who enjoy first person shooter and puzzle without age restrictions, because the game doesn't contain any violence or situations that may cause discrimination.

3. Story Elements
[indent=1]3.1. Synopsis
Not applicable.

[indent=1]3.2. Setting
Not applicable.

[indent=1]3.3. Player role
Not applicable.

4. Interface
[indent=1]4.1. Perspective
First Person Shooter.

[indent=1]4.2. Mechanics
Basically the game will feature a main menu and one where the player will be able to choose the level you wish to play.

[indent=1]4.3. Control