Steady Drop – Log #11

 

Collecting game data for simple statistics

After the previous iteration I’ve done on graphic and UI improvements in the game I started to think about collecting some data from the game that comes from the player actions, in order to have a sort of statistics screen that the player can check from time to time to see his progress, and furthermore in this way the game can collect useful data to base some kind of achievements system in the future. For example there will be an achievement for falling through 100 game units (or meter if you want) or for playing 500 rounds. For the achievements system, I’m planning to integrate some native stuff for Android and iOS (Play Game Services for Android and Game Center for iOS), starting with Android, obviously.

 

Implementation of the statistic system

For the implementation, I chose to create a single class that handles all the requests to store and get the data collected. The data we want to collect are mostly integer numbers handled in different manners. For example, if I want to memorize the high score, I have to tell this entity that the data tagged as “high_score” has to be saved as MAX of the previous, and on every game over I have to memorize the current score. In this way, every time I memorize a new value, the entity keep the max between the previous and the current values. In a similar way, I can memorize a counter (like to count the rounds played). What I have to do is to memorize a value 1 every  game over.

This entity relies on the DataMgr to load and save the data. The DataMgr itself is an interface to read and write values from the physical memory of the device you run your Unity application. Here some snippets I took from the StatisticMgr.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
//Load and save data from the device
public void loadLocalData() {
    foreach(KeyValuePair<string, StatData> entry in dataBank) {
        string readData = DataMgr.readData(entry.Key);
        if(readData != null)
            entry.Value.setInitialValue(readData);
        else
            entry.Value.setInitialValue(0f);
    }
}

public void saveLocalData() {
    foreach(KeyValuePair<string, StatData> entry in dataBank) {
        DataMgr.writeData<double>(entry.Key, entry.Value.value);
    }  
}


//For store a new value in game
public void storeNewValue<T>(T _value) where T: IConvertible {
    Double dValue = Convert.ToDouble(_value); //numbers stored as double
    switch (mType) {
    case(StatDataType.PLAIN): //saved without logic
        value = dValue;
        break;
    case(StatDataType.SUM): //saved as increment
        value += dValue;
        break;
    case(StatDataType.MAX): //saved as max (if the current max is lower
        value = Math.Max(value, dValue);
        break;
    }
}

 

Where is the sound?

I’m still planning to make sound and music for the game but the sound iteration will take some more time. I could pay somebody to make music and sound for me, or take it from some Creative Commons site, but since I have a little knowledge of music theory in general and in the past I was into recording, DAWs, MIDI and stuff, I want to try to harness my past passions to make something out of it, before asking for external help. What I have in mind, though, is to record some real sounds and manipulate and combine it to create the sounds I need.

Stay tuned for future posts of the series, and if you are interested on other post series don’t forget to visit the blog main page 🙂

 

Game developer & designer. Unity 3D lover. Movie fanatic.

RaspberryBoy – BuildLog #6

Actual project state

I realized that I’m taking this project like a summer project and I rarely work on it on the other part of the year. Last summer I was planning to finish it, I wish I could. At least I was able to work on some of the components, and that gave me the material for some blog articles.

This summer, though, I started with new ideas and new components (which you’ll see in a minute) and I’ve almost finished, I’m planning to finish it by the end of this year.

I’ve also tried to find some circuit drawing program to better explain the wiring I do on each post but I found only boring schematics drawing programs. Since I like colors I think I have to draw them myself with some graphic program. I’m also planning to make something about four more posts on this project, in which I’ll explain what I’ve done in different macro areas of the parts, and in the end some final thoughts.

 

Change of direction: a new case

Last summer I worked and modified a transparent-green game boy case to house all the components. After finishing the modification I wasn’t happy with the results so I decided to take a new case and modify it from the beginning. I’ve found on Ebay a kit for the “GameBoyZero project” which also has  a screen protector and a modified (and clean) breadboard for the controls. With this kit, it will be much more easier handling the controls. I’m not regretting having modified (and ruined) the transparent green case, but I didn’t like it, and I wanted an opaque one. Modding this case was a lot easier this time because I’ve already done it several times, and if something is scratched on the inside, it is invisible on the outside. So the case is ready (for the second time).

System configuration

For the system configuration I found an interesting tool (GitHub repository) that can convert GPIO inputs from the Raspberry in keyboard events, which is exactly what I was looking for.

In other projects I’ve seen people  using an external unit (Tinsy-board) that handles the controls and it’s connected via USB to the Raspberry, but I don’t like this solution because it brings more complexity to the wiring.

After installing correctly the operating system (RetroPie), I installed this utility. The configuration is very easy and it’s all inside one text file. I founded a very explicative tutorial on Adafruit (linked in the repository).

As you can see, the configuration file is very simple: every input is related to a physical pin on the Raspberry, it’s only matter of connection.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Sample configuration file for retrogame.
# Really minimal syntax, typically two elements per line w/space delimiter:
# 1) a key name (from keyTable.h; shortened from /usr/include/linux/input.h).
# 2) a GPIO pin number; when grounded, will simulate corresponding keypress.
# Uses Broadcom pin numbers for GPIO.
# If first element is GND, the corresponding pin (or pins, multiple can be
# given) is a LOW-level output; an extra ground pin for connecting buttons.
# A '#' character indicates a comment to end-of-line.
# File can be edited "live," no need to restart retrogame!

# Here's a pin configuration for the PiGRRL 2 project:

LEFT 4 # Joypad left
RIGHT 19 # Joypad right
UP 16 # Joypad up
DOWN 26 # Joypad down
LEFTCTRL 14 # 'A' button
LEFTALT 15 # 'B' button
Z 20 # 'X' button
X 18 # 'Y' button
SPACE 5 # 'Select' button
ENTER 6 # 'Start' button
A 12 # Left shoulder button
S 13 # Right shoulder button
ESC 17 # Exit ROM; PiTFT Button 1
1 22 # PiTFT Button 2
2 23 # PiTFT Button 3
3 27 # PiTFT Button 4

# For configurations with few buttons (e.g. Cupcade), a key can be followed
# by multiple pin numbers. When those pins are all held for a few seconds,
# this will generate the corresponding keypress (e.g. ESC to exit ROM).
# Only ONE such combo is supported within the file though; later entries
# will override earlier.

 

 

 

 

Assembling the parts

This time was easy, because I took one cable from the control board for every control in it and soldered to the specific pin in the Raspberry, as specified in the configuration file, even if in the photo you can’t see the Raspberry connected to the cables yet. Then I attached 2 more cables for R and L buttons that I will put on the back of the case. At this point, it seems like there are a lot of cables but they can be managed very easily. After finishing soldering I tested the controls with the operating system and they all works smoothly (as expected).

In this last photo I’ve mounted the screen (taken from the green case) and the screen protector in place. I have few more major topic to discuss for the mounting which I will cover in the next posts of the series. Stay tuned 🙂

Game developer & designer. Unity 3D lover. Movie fanatic.

Isometric Camera with Unity

 
I like real time cameras subject so much that I already made a post on real time cameras (here) specifically on third person cameras. This time I will show you how I set up a simple isometric camera for a game prototype I made in Unity.

 

The isometric camera

Basically an isometric camera has an isometric view in which the perspectives are avoided, it’s like having a “zero-point” perspective instead of the three-point perspective you normally have on a classic first or third person camera. As you can see, there are no perspective deformations on what the camera sees, for example, with isometric view, all the edges of the cube are parallel. Technically, by having a an isometric view, the camera is already isometric, but on top of that, in games this view is classically used used with a 45° degree rotation.

This type of camera was used a lot in the past (especially on the 16-bit era) in games like Q Bert, this first Diablo, the first Fallout and Age of Empires, mainly to give more sense of three dimensional space with a minimal computational effort. Lately it is used for nostalgic reasons and for specific artistic or design choices in games like Monument Valley.

 

The camera script

The only thing you have to do it in order to use my simple isometric camera is to add this script to a Gameobject. Since the script require a Camera, it will add it for you. When the script starts, it creates all the things needed to run an isometric camera, which essentially are a target to look to and some other Gameobjects used for camera movements (which I will show you in a minute).

Then the most important part is camera settings and rotation. The camera has (obviously) to be orthographic otherwise we have perspective involved and we don’t want it. For the rotation of the camera, I chose to make the camera a child of the target and to rotate the target instead of rotating the camera itself, just because it seems more logical to me to apply the further movements and rotations.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
void Awake()
{
    //Objects creation
    GameObject target = new GameObject("Camera Target");
    GameObject movableRef = new GameObject("ISO Camera Movement");
    movableRef.transform.localEulerAngles = new Vector3(0, 0, 0);
    m_IsoMov = movableRef.AddComponent<IsoMovementController>();
    m_IsoMov.init(speed, limits, invertedXAxis, invertedYAxis);

    //Camera settings
    m_Camera = GetComponent<Camera>();
    m_Camera.orthographic = true;
    m_Camera.tag = "MainCamera";
    m_Camera.orthographicSize = 20f;
    m_Camera.backgroundColor = new Color(.3f, .3f, .3f);

    //Camera positioning and objects parenting
    GetComponent<Camera>().transform.position = new Vector3(0f, 0f, -50);
    GetComponent<Camera>().transform.parent = target.transform;
    target.transform.parent = movableRef.transform;
    target.transform.localEulerAngles = new Vector3(45, 45, 0);
}

 

Camera motion

While creating this camera, I wanted to add a little bit of movements and even a rotation. To do this, I created a second script and attached to the parent of the camera target, the controller. In this way the controller rotates and moves the target (in real time), and the target has rotated (and keeps the rotation of) the camera. That’s the reason of all of those objects in camera creation.

Movements

For the movements I just taken the vertical and horizontal axis and translate accordingly but within a certain limits (setted in the inspector), in this way we can’t get outside of a certain scene or environment.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
void FixedUpdate ()
{
    float h = Input.GetAxis("Horizontal");
    float v = Input.GetAxis("Vertical");

    if(!h.Equals(0f) || !v.Equals(0f))
    {  
        Vector3 trans = new Vector3(h*.5f + v*.5f, 0, v*.5f - h*.5f);
        transform.Translate(trans * speed *  Time.deltaTime, transform);

        Vector3 pos = transform.position;
        pos.x = Mathf.Clamp(pos.x, -limits.max_X, limits.max_X);
        pos.y = Mathf.Clamp(pos.y, -limits.max_Y, limits.max_Y);
        pos.z = Mathf.Clamp(pos.z, -limits.max_Z, limits.max_Z);
        transform.position = pos;
    }
}

 

Rotation

As a reference for the rotations I took the camera from the game Anno 2070, which can rotate towards the target (on the horizontal plane) of a certain angle. I wanted something similar but more defined: I wanted the rotation step to be 90°. In this way when the camera has finished rotating, you are still in a isometric view but you are looking at another side of the scene. This concept of having a rotation step I saw it on Fez, which is a 2D game, where you can rotate the camera, 90° degree at the time. It is actually a 3D game. Here’s the code for the rotations.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
void FixedUpdate ()
{
    if (Input.GetButtonDown("Jump"))
    {
       
        if (!m_IsRotating)
        {
            float c_rot = Input.GetAxis("Jump");
            Debug.Log(c_rot);

            m_IsRotating = true;
            m_DesiredRot = transform.rotation;
            m_DesiredRot *= Quaternion.Euler(0, 90*Math.Sign(c_rot), 0);
        }
    }
}

[...]

void Update()
{
    if (m_IsRotating)
    {
        m_RotationData.rot_value = Mathf.Lerp(m_RotationData.rot_value, m_RotationData.rot_sp_max, Time.deltaTime);
        transform.rotation = Quaternion.Slerp(transform.rotation, m_DesiredRot, Time.deltaTime * m_RotationData.rot_value);
        if((m_DesiredRot.eulerAngles - transform.rotation.eulerAngles).sqrMagnitude < 0.1)
        {
            m_RotationData.reset();
            transform.rotation = m_DesiredRot;
            m_IsRotating = false;
        }
    }
}

 

Final results

This camera works great (with some adjustments), for example for infinite runners or strategic games that need to have a top view of the “game board”. In order to work properly, however, the 3D models you put in the scene have to be created for an isometric view.

You can find the full Unity project right here (with a beautiful voxel model I made) feel free to use it and modify it.

Unity Project

Game developer & designer. Unity 3D lover. Movie fanatic.

Steady Drop – Log #10

Deadline changes

I had the milestone to complete the next development iteration of Steady Drop at the end of march 2017, but for the lack of time and for the efforts put in other projects (like the game I made for the Global Game Jam 2017) I’m forced to postpone this milestone and to go a little bit further with the deadlines. The project is still growing, it’s just I had little drawbacks, that’s it. I’m still adding improvements here and there, most graphical ones, and I have some “big” features I want to add before the next deadline. Like I said, I fixed most of the bugs I received from the alpha-testing phase and I’m still integrating some improvements based on the feedback I had. Goos news after all!

Visual improvements

I reviewed the color palette of the entire game, so I changed every color a little bit to make it more glued together (I used a palette generator) and to give more sense to the overall experience. But I completely changed the enemy colors: they was very similar to the avatar of the player but now, as you can see, they have their own color, and it’s more clear to the player that’s this shapes are not something related to the avatar he’s guiding down.


Another two visual improvement I’ve added are the trail behind the falling avatar and a particles generator on the bottom of the screen, they both give more sense of movement.And last but not least I’ve added a dynamic gradient un the background. So here you can see the differences between how it looked like and how it looks like now.

 

Next steps

One of the things I want to do next is to add some visual feedbacks when you lose health (or zero-gravity time) and to make some enemies a little bit more alive with some scale animations. I’m also planning to rewrite part of the UI system and replace the UI of the main menu, because I made the current placement just for the prototype, which has limited menu choices.
Next I will have to modify the tutorial (again) because I don’t like the current one, and to work on some game balance parameters like the score multiplier…a lot of magic numbers 🙂 After that, I will start to research how to integrate and produce sounds and music. It will be fun!

Just a reminder, if you want to play the alpha, just download and install this file. Steady-Drop-Alpha

Game developer & designer. Unity 3D lover. Movie fanatic.

6 ways for improving your game design

 

In this post I would like to give you some basic game design concepts to create better games and videogames. This are some of the notes and lesson I’ve learned watching talks and, more importantly, creating my own games. Coming from a programming background I tend to not give the proper importance to game design, so I’ve decided to give it the right importance and to try training myself to use game design concepts more easily, studying and going on depth in more and more aspects.

 

1 – Expand your background

The first advice I can give you is to expand your background, I mean your general knowledge. Since game design involves a creative process, the more things you know, have seen, have touched, have experienced, the more you can pop out ideas. Starting doing new experiences is a good way to start. You can start watching more films you haven’t watched yet, read more books, visit some art expositions, ect…Game design is creative but is also ruled by some essential rules and best practice, so to understand it more you can play different videogames and try to learn from them, for example how the thing works on the same genre of games, how the controls works, progression and so on…

 

2 – Try to give more, not just gameplay

Once you have a good mechanic and your game is fun to play, try to give more than that by creating a world to put the player in, work on immersivity and flow and give the player the right space to breath. The player has to acquire the will to play your game, once again to feel new sensations every time he plays. Giving more than a clear and guided goal but a more complex and variegated set of goals or purpose, can help to create the feel of an infinite play.

 

3 – Remember all types of players

When designing a game, keep in mind to visualize all possible scenario about the type of operation you allow and what the players can do with it. On this matter it is useful to remember yourself all the type of players. There are a lot of different types of players and some famous game designers categorized them in different ways, but the way I like the most is “The four types of players” (link). Try to design a progression that is suitable not for only one genre of player.

 

4 -Tune carefully your challenges

The progression of the players is one of the most important things that are not visible but are there, and the player can feel it very well. I mean the progression can be felt but not directly seen. Its sensation property makes the progression a crucial thing, and for this reason you have to carefully design the player progression, with the right challenges at the right time, and the gathered skills have to keep the mind flow of the player active. And remember this: easy to learn, difficult to master.

 

5 – Social Games

When designing a social game, think at all the tools you give to become social. Probably all of them are communication tools. Every communication tool lets the player use the tool in different ways. If you give too much space, you probably have to face problems of misuse of the tool. In the first place, you have to find the right tool for communication that can avoid misuses and secondly, think a proper way to both punish the misuse and reward the right use, in a fair way.

 

6 – Decide: game or market

A game can be a pure expression of art and technical skills or can be a mere selling product that has to satisfy the market in some specific ways. For me both sides are a little risky to make and they have both pros and cons, but I think that the truth is in the middle, as they say. A good game designer should find a good compromise between art and selling purposes.

 

Game developer & designer. Unity 3D lover. Movie fanatic.

RaspberryBoy – BuildLog #5

 

Here we are again on this slow (but constant) process of building my RaspberryBoy. For those who don’t know what it is, it’s a retro console, made using parts of an original Game Boy and a Raspberry Zero (explained here).

This time let’s talk about the audio circuit. Like said (here) I bought an audio amplifier from Adafruit and like most of the tutorials on the matter recommend, I connected the red cable and the brown cable (I didn’t have a black one) to power the amp, I took the power directly from the Raspberry Zero. I wired the green and orange cables to an audio jack just to test it with an audio source. In the final version these two cables will take audio source from the Raspberry, but I’m not ready yet for this.

Eventually the white and blue cables had to connect the output jack and the speaker in a way that if some headphones are plugged in the speaker it will automatically disable itself.

The wiring is still rough and the audio is a little bit noisy but I will replace the wires with some thicker ones and be more careful with the soldering. To complete this audio step, I will have to connect the external audio card to the Raspberry and I will have to enable it as the main audio source, for that I think I will have to use some commands from the operating system. I will put this step on a future post, maybe regarding the system configuration.

While writing this post I realized that this buildlogs could be more useful if I included some wiring diagram especially while talking about wiring matters. In the future post I will make diagrams when needed and I will update the previous ones and add the diagrams. In the next step I will modify the input board for input controls. Stay tuned 🙂

Game developer & designer. Unity 3D lover. Movie fanatic.

Create a movie barcode with Python

 

I’ve recently discovered this curious blog called movie barcode (link). The image on this blog are basically created from the frame colors of a movie or a video and maybe there are some post-processing on the image to make it more artistic. When I discovered it, I really liked the idea and I started to gather information on the possible algorithm to analyse and create (from code) similar images. This is when I discovered some articles (this one, and this one) on the matter and I started to play around with the code given. Most of it was in Python so I continued to use it for this project. My idea was to analyse video source frame by frame, then find the main color for that frame and to create an image that has a vertical line (of a certain width) of that color. I know this is a different approach from the ones on the blog , but I wanted to start easy and then to expand or change the algorithms. The link of the script is at the end of this article 🙂

 

Take a video source

The first step is to take a video source and for that you can choose to take a video on a specific path of your pc or you can download it. I used this library (link) to download a video from Youtube (very easy to use). Once we have a video we can analyse it. I tested my script mostly with mp4, avi and mkv videos, I don’t know if can works with all video codecs or compression. (it’s not the purpose of my script 🙂 )

 

Analyse frame by frame

Now the fun part: find the main color of a frame. To do that I massively inspired my work on this articles (link) from Alan Zucconi, where he uses a K-mean algorithm to analyse an image and explains very well how this algorithm works. Fortunately, there are some good Python libraries to do that (details on the script) and they are easy to use, so why not. This algorithm is pretty heavy but after few seconds we have the RGB components of the main color for that video frame and after doing this process for every frame of the video, we have a list of colors. Since I choosed to make the result images of a certain maximum size, in the script I analyse only a certain number of frames. If the number of frames are more than this number I simple analyse one frames and skip N frames.

 

Creating the final image

Now what we have to do is to create an image that have a vertical line for every color of our list of colors. To do this, I used another Python library to create images, graphs and color manipulation stuff, which is a pretty powerful library that can do various things as create an image of a certain size from a list (a matrix) of colors. Here is how the matrix is created.

 

Final results

I’m pretty happy with the results so far, so I started to analyse some Youtube videos and some films with this results:

 

It’s only a matter of install the right libraries and run this script with a video and you’ll have a nice barcode. I will definitely improve this code and try to make it more artistic. Maybe in the future there will be another post on this subject.

 

Movie barcode on my Gist

Game developer & designer. Unity 3D lover. Movie fanatic.

Steady Drop – Log #9

Alpha released

 

I released the alpha of Steady Drop! It was a silent release (sadly I’m not a marketing guy :-P), which I’ve done only for people I know and for members of some Facebook groups I’m in, but It was the right time for a first slot of tests.

Right after releasing the alpha version, I started to receive a lots of useful feedbacks by the “alpha testers”. I gave them the possibility to leave a feedback in a traceable way (with a Google Form) or in a more direct and fast way. One of the last changes I’ve done right before the release was to add a button to leave a feedback on a form I made just for them. With this form I tried to gather all the informations I needed in order to progress the development in the right direction and make Steady Drop more playable and easy to use.

After all, seeing my game from another person’s perspective is the best way to find out some flaws which are invisible to me and just view the experience from another angle I didn’t considered before. Seeing what another person sees while playing your game is invaluable, and the more you have the possibility to let this happens, the more your game can improve. The only (little) drawback is that it’s required to filter in some way and extract the right signal from a feedback.

Thanks to all of the feedbacks, I listed a number of fixes, improvements and just some things I wanted to try, that I added to the task list I want to develop for the next step, which is a release of a beta version. I will also try to remove the sense of prototype while playing the game…it will be a hard one.

Right now I’m not putting so much effort on new features or bugfix, because I have other little projects I want to finish and publish (like this one). Right after finishing these little projects I will spend more time on this project and I will bring the development forward. If you want to try the alpha version of Steady Drop contact me 🙂

Game developer & designer. Unity 3D lover. Movie fanatic.

GGJ 2017 Post Mortem

 

Once again I’m going to describe and share my experience at the Global Game Jam in Milan, that was the world’s fourth site in terms of participants in this edition, even if in Italy there was almost 10 sites around the country. I have to renew my thanks to the organization crew of the event that did a really good job for both organization and security matters.

This was my second participation (last postmortem here) and this time I felt to be more prepared than the first time. Logistically I already knew the venue and how the event is structured, so my organization for the event was all ok and smooth. On the site I’ve found a lot of good friends and passionate people  about videogames, willing to share their games and thought about game development, some of them were also very skilled and professional people. Like said, I’m going to analyze my experience on this GGJ, instead of focusing on the game we made.

 

The jam experience

This year I decided to go on the venue in the afternoon. The morning conferences are very interesting but since I had to travel for 3 hours from Trento to Milan, I decided to skip the morning session and rest a little more. Once arrived and registered, I started to walk around and look at some of the games from the guys of the Politecnico. Like the first time, the team building was very random: while walking around, after refusing some interesting offers using Unreal Engine (I don’t use Unreal and I think it’s not a good choice to learn how to use it on a jam), I found a game designer who was searching for a team. Ok, we were in the same situation and we started to search for an artist, and the search was literally 2 seconds long. Then the artist found some sound designers. At that point we needed another programmer and we found one programmer and another one with a game designer badge who joined our team. Our team was good to go and we went to the theme revelation conference (like always, one of the best moment of the jam) and then jumped into the development for the following 48 hours. I have to admit that the spirit and the mood of your jam can drastically change along with the components of your team 🙂

 

What went right

Self wisdom: that was my second GGJ and my third game jam, so I faced all the phases of the development with some extra wisdom, avoiding the common mistakes and the mistakes I’ve done in the past jams, and the fact that I was the only member of my team who already done a game jam, was pretty vital.

Right Idea, very fast: we found some decent ideas for the game pretty fast, with a well-ordered brainstorming. We had the right inputs from the others members, using different phases of brainstorming, and with the right time for each phase we didn’t loose much time or find stucked.

Good rest: This time I decided to schedule the rest during the jam in a proper way. I worked every day to 2am and rest until 7am. Five hours are a good compromise to me, and I didn’t felt exhausted at all.

 

What went wrong

Bad task assignment: As the only one who have already participated to a jam, I had the “privilege” to coordinate and assign tasks to the other two programmers. I started with the first things that came to my mind and assigned them, but on second thought I should have thought to the big picture and assigned tasks for a certain aspect instead of some braided tasks that have almost compromised the project.

Engine issues: In the middle of the jam we encountered a little problem with Unity (the causes are still unknown). There are some project files corrupted that they forced us to waste a lot of time in redoing some tasks. Fortunately they weren’t dramatic, and we solved pretty fast.

 

Tips for the future

My personal tips for future jams are:

  • (again) give more meaningful choices to the player.
  • Think more to different game genres that are suitable for a jam
  • Explore more games from the previous jams to get the feel of them

 

Final result

The final result of all the efforts is Make Babushka Proud (lots of infos here). We are currently working on it to resolve some bugs and maybe publish the game for Android in the Play Store. I leave the time lapse of the “making of” and link for downloading the game on itch.io

Game developer & designer. Unity 3D lover. Movie fanatic.

RaspberryBoy – BuildLog #4

The screen and the case

Firstly I have to apologize but I’m not working so much on this project and the articles are posted rarely. Anyway, my idea is to proceed component by component and talk about how I managed the issue of fitting all the stuff in the case and making it work. In case you didn’t read the previous posts, here they areThis post is about how I’ve prepared the screen and the case.

 

The screen

My choice for the screen was similar to this one (link), apparently used for car parking as monitor for not bumping obstacles. This type of screen is often used in projects like this because it’s very small, compact and cheap, but some of them need some electronic modification to run the screen to a different voltage, but fortunately was not my case. I started to unmount the screen to take only the panel, and it was pretty easy, I have to admit. After replacing its cable with thicker ones, I’ve placed some black tape to cover the metal to avoid unwanted contacts. I try and tested the screen with the Raspberry with temporary soldering and it worked! It’s just a little bit noisy but I think it depends on the quality of the fast soldering I’ve done.

The case

To modify the case, I used a rotary tool with different heads, and following the tutorial of wermy on sudomod(link) I cut out all the unneeded parts  for this build. This processes are probably the most difficult of the project, and after finishing the work I was not really happy with the results. I will change the case in the future maybe.

 

The next post will be on audio and how I will settle the audio components in order to work. Stay tuned 🙂

 

 

Game developer & designer. Unity 3D lover. Movie fanatic.