End of the summer internship – the Legend of José

End of the summer internship – the Legend of José

This is the second and final post in a series that looks back at the Mimicry 2017 summer internships. You can read the 1st part right here.




Mimicry 2017 Summer Internship Postmortem

By José Vieira


My main goal with coming to Mimicry for this summer internship was to acquire some experience in game development in an actual game development company. Improving my portfolio was also great, as I’ve worked on a project that will be on the market later this year.

Mimicry Summer Internship Jose

I also wanted to see first hand how things are done at an indie studio.
More generally speaking, I wanted to experience the difference between university and work environment, and how I can improve to get ready for that difference.

What went right


I did a multiplayer game in a past game jam, but since it was my first multiplayer game, things like security or even optimization weren’t taken into account. This is not the case when you’re developing a commercial game, so server security needed to be handled very carefully, and it needed to answer fast. Getting this right was quite the challenge, but as development went forward, so did my network knowledge, and although the multiplayer aspect is not perfect, it’s way better than some weeks ago. I tried only using the server when it needed to be used and optimized the server calls as much as I could, so things like animations are never synchronized as each client takes care of the animations locally (except if the animation has a major impact on the gameplay), but when a cat eats sushi, the score calculations are handled by the server. I also learned a lot about network in games, so I’m very happy to take this knowledge with me and apply it in the future!

Early prototype screenshot
Ganbatte early prototype screenshot

Spectator cameras

Regarding spectator cameras, there are some games that have them, but I’ve only seen it on single player games. In multiplayer you can’t really use the same tricks you would use in a single player game due to numerous reasons. When I was starting to think how I would do that, Epic released Unreal Engine v4.17, and one of the new features was spectator view. I was super happy because I thought implementing that would take a huge amount of time, but Epic came to the rescue with a new way to do that, so I just read the new documentation and in about no time we got that feature implemented! Perfect!

VR development

Before the internship I had never developed anything VR related, and I was definitely curious about this technology, but I didn’t know if I was going to like developing for it. I was so wrong that now it’s the complete opposite. Playing some VR games and developing Ganbatte sparked my interest in VR development. I’ve also learned useful techniques to face certain VR design problems (user interface, user-world interaction, motion sickness) and how to build functional and fun gameplay with this new way of interaction.


Even though we’ve never worked together, the team adapted pretty quickly. We had regular meetings, especially in the beginning to talk about game design and to make decisions, so that we could start working. When things were decided, prototyping quickly began. Everyone was happy to help if I was stuck on something, and many problems were solved by just talking and exchanging ideas.

Mimicry Team

Experience itself

The internship was an excellent experience as a whole! Developing a game during 3 months made me realize/rethink some game development aspects. First of all, I realized polishment takes a very long time, sometimes even longer that implementing the feature that is being polished. In second comes prioritization, and this may sound obvious, but since I was also working with artists and not only programmers, priorities can change so that everything fits together at the right time for the team and not specifically for you. Third, when you have a deadline to deliver a build, bug fixing can become much more important than feature implementation. If you’re going to do some playtest with people, it’s better that you have some things missing but they all work well, than having a lot of stuff but most of it is broken.

What went wrong


It’s hard to test in VR. You have to put the headset on, test and finally take it out. I even use glasses, so I need to take them off and put them on again. If we’re going for a multiplayer game, it’s even worse! Testing inside the editor works for some basic stuff, but if you need to test certain aspects in which you need input from the client side, you can’t test inside the editor. The best workflow I’ve found was to package the game, send it over the LAN network to another computer, start the game in my computer (that would play as the server) and start on the other PC as the client. This continuous process wasted a lot of time, especially in the beginning since I needed to test every little multiplayer detail. For example, it could take 5 minutes to test if a client could grab a plate, and if that wasn’t working, I would try to fix it, and proceed to the same test flow again.


One of the objectives of this internship was to publish the game in the final 2 weeks, so that I could experience some post development process. Although I was optimistic, we quickly began to realize that that would simply not happen. The project grew in functionalities, we added metagame aspects, we used some of the time coming up with a dedicated server solution, underestimated the time some mechanics would take to implement, and bugs happen, which takes away time to developing new mechanics.
We definitely underestimated what we had to do, and since we wanted to do everything right, more time was needed. Basically, we were complexifying the problem each day.


One of our ideas was to have cats covered with fur. Since we didn’t have the time to code a fur shader, we had to rely on third party plugins. This can easily become a problem if there’s little to no support from the original creators. After going from version 4.16 to 4.17 (because of the spectator cameras) we found that the plugin wasn’t ready for the new version. Since we had already done a lot on the new version, going back to 4.16 would require at least 3 days of work to redo everything on the old version. We even started doing that, but quickly realized that was not the way to go, as we would be stuck on this version and would need to remove the spectator camera mechanic (which I think it’s pretty cool)! So we just continued with the new version, but without fur. We spent too much time trying to find an alternative to have fur, and in the end we decided to abandon it, wasting some precious development time.

Perforce as version control

Having tried git and svn, I though using Perforce would go smoothly, but that was not always the case, and some mistakes were made with this version control system, especially in the beginning. When it was time to push/pull to/from the repository, my heartbeat was bombing! Sometimes after pulling the new changes, the project wouldn’t even open, and I had no idea what went wrong. As development advanced, in order to fix some committing errors, I created a new workspace just so that I could start with a clean pending changelist. Right now I think I’ve got the hang of it, but it was definitely a challenge during the first few weeks.

Knowing when to stop

This is a hard thing to do, seriously. Almost every day I worked extra hours, not because I was told to, but because I wanted to. The usual stuff like “just fix that bug” or “just finish this mechanic” or even “just test this”. I genuinely loved what I was doing and I really liked programming all day/night, the problem was that sometimes I would get too tired when I got home. That can have a lot of impact in certain things, be that productivity or even my mood. I usually don’t notice/feel that, but I’m sure the impact is there.

Jose Dance Rift
Proof that José never stops dancing in VR


I’m very happy for the opportunity I had to be part of the Ganbatte development team. It ignited my interest for VR, provided game development experience in a company and taught me a lot. I’m sure this knowledge will help me in the future, and I intend to make the best use of it!
It was a great 3 months journey, and may the best cat win!




What’s next for Pedro and José?

After reading the postmortems you might be wondering “what’s next for Pedro and José?”. We’re happy to announce that we’ve offered both Pedro as well as José a position at Mimicry – and both have accepted! Both of them are super talented and they’ve proven their worth by working hard and having an incredible drive and passion. Starting October 1st, Pedro will officially join us in the role of Game Artist and José will officially join us in the role of Software Engineer, Games and Virtual Reality. Of course both of them will be wearing a ton of other hats, so their actual role is a lot more broader. We are thrilled to have them on the team!

Do you have any remarks, or questions that you want to ask Pedro and José about the internship, their future perspective, or do you need any advice/tips from the team? Join the conversation and write your message down below in the comments.

Thanks for reading!


Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: