5 A Side Legends!

Last week I was fortunate enough to finally release my very own football manager app! 5 A Side Legends.

Download for free on IOS & Android

More details can be found on our website.

Advertisements

We Can Build It!

Another Successful App Launch with Dubit,

Bob the Builder: Build City. Released on Amazon, Google Play and IOS.

With my work on the prototype and some feature/bug fixes, the whole experience working on this app was amazing. A brand and client as big as Bob the Builder doesn’t just happen by mistake. The whole team here at Dubit worked our socks off for this one, good job everyone!

It was a great journey to be a part of, it was my first project when I started at Dubit and it’s great to see the final product out in the world. Some great stats/data coming out from the stores and users about the app. Long may it continue and hopefully we get to make some updates!

AFL Bounce

Bounce Icon

At Dubit I helped release another application to mobile market, AFL Bounce. The application has been released on IOS and Android stores.

Made over the period of 8 months or so, it was a great joy to be a part of. I was tasked with:

  • Creating the Polls content type
  • Front end API requests
  • Code optimization and improvements
  • Favourites
  • Skinning
  • Video Thumbnails
  • Bug Fixing

Great work by all the team at Dubit.

 

Car Mat Demo

Good day,

Recently at Dubit Limited I got the chance to demo a product for a client. The prototype was a 3D city navigated via draggable vehicles. A player could interact with the world, complete objectives and play in the car mat demo scene with 10+ vehicles. Great fun to make and lots of different problems to overcome. Made in Unity 5.1 and below is a video made from that prototype.

Enjoy.

Automation

Hello,

Today’s topic is about how to automate your development process. At Dubit there are strict coding standards, large development teams/structures and constant development of products. My old development style would have not kept up to the pace that Dubit expects. I had to change my process and one way of doing this was via automation.

When I write automation I mean making computers do tasks you shouldn’t be doing as it wastes time. I am going to pick on three things: Building, Code Standards and Asset Editing/Unity Tools.

Building

I like to walk but going over to the office development mac and creating an IOS build was becoming a chore. Not the walking itself (which is at the other end of the office) but why all the hassle of creating a build manually.  After doing an IOS build then the android build and a PC build thats roughly 30 mins of wasted loading bar watching and walking. The solution is to have someone else build my projects and let me know when it’s done.

Unfortunately I cannot afford to pay an assistant to sit at the PC and wait for my signal, I settled for using the Unity Cloud Building Service. It was easy to set up and free. It can do the builds I need as I work on my projects without having any interact with me during. I get a email letting me know what has built and the change log to go with it.

While it does remove the much hated waiting for builds issue the biggest issue it removes is me. To clarify it removes me as a dependency for the project. The project can swap me for another developer and the build process is the same and no human error because I’m no longer there. What’s great is currently on my way home I can get a build email on the bus, install and test the latest version on my way home and so can everyone else on the project.  Free Quality Assurance/Testing.

Coding Standards

I spoke in my last post about code reviews and this process can eat up loads of time. It eats up time on both ends the reviewer checking everything and the publisher fixing issues. I wanted to remove as much reviewing time as I could on both sides as a reviewer and as a publisher. One way I came to was to have something check the code for the strict code standards for me. This is achieved via StyleCop an editor extension for Visual Studio.

It will scan code for any rules that are broken which I have defined prior. This helps reviewing code by opening the project in Visual Studio and scanning it for any code standard issues. Then on the publishing side I know my code is adhering to those standards via the scan performed on my own project. Before I publish my code for review one quick scan and I can stop the reviewers picking up on small tiny problems in the future.

This is just one developer solution though, a more comprehensive solution is to use pre-commit hooks to check code before pushing to the repository which makes every developer adhere to the standards.

Unity Tools

This is more conceptual and not a specific tool like the last two. I currently work in Unity and many Unity developers will know the engine allows access to a wide range of editor functionality. I have found these to be of great use in the past. For example we had a large game with hundreds of audio files in the project then we were required to edit all of the audio files (compression settings etc). Manually this would have taken days if not weeks and we would have most likely missed some or done some incorrect. A quick search online and I find out how to change the settings of an audio file via a window in Unity then another quick search for how to get all files of a particular type in Unity.

After combining the two and making a nice little window of the tool we have a automated audio settings editing tool built in our engine. Was fun to make and a great learning experience as well. Any number of tools like this can be made to help your game development from behind the scenes and stops you wasting valuable time.

Conclusion

These three automated tasks have reduced human error, time and dependency which in turn improves the project as a whole. The more tasks a computer can do the more time I can spend perfecting the code base, structuring and code development.  I highly recommend trying to automate more jobs you might do a daily basis as the fun in making a tool might also teach you something and help you in the long run.

Thanks for reading!

Joining Dubit

Good day Reader,

I have left my last company (Route One Games), which was a great experience and I wish the team we had there the best of luck in the future. I joined Dubit Limited in May of this year and it has been amazing so far. Dubit have helped me develop my coding skills and learn some new things while working on some interesting products. I am hoping to update my blog with some interesting knowledge gained from my work here at Dubit and to kick it off I thought I would start with the biggest change I have encountered to my workflow.

The Devil You Know – Code Reviews

My biggest fear for a long time is people looking at my code and for good reason. Past projects haven’t had code reviews and most of the time the only person to look at my code is myself.  So coming to Dubit was interesting when I found out there was standards and strict code quality that all developers follow. Dubit keeps these standards adhered to via the use of code reviews.

This leap into a (virtual) room full of people looking/commenting on my code has been the best thing to happen to my development. It has helped me see where my coding standards should be better and not just in performance or structure but general coding we take for granted sometimes.

I have enjoyed code reviews and I really enjoy reviewing other people’s code to learn why they choose particular methods. I would encourage other developers out there to try it sometime even if it’s with just your peers, everyone here at Dubit help no matter what skill level you are at. It can sometimes bring your morale down when you have missed some things you thought were fine but it boosts your confidence for the future knowing when people use/look at your code it is understandable, readable and efficient.

To finish off this section off some useful tips I have for doing/experiencing code reviews:

  • TODO. Keep a task list of comments, even the ones that require no code changes but may warrant a response. Bit bucket has a task system built-in. My advice here is to make the list first then do the actions, don’t reply to a comment straight away because the same comment might appear further down and a different task may then arise.
  • You are a reviewer as well. When you publish code the first reviewer should be you. Review it before you publish your code for review or after but be a part of the reviewers. It’s your code and you should be proud to show it to people.
  • Names can mean a lot. Naming things is something I struggle with all the time, variables, class names, method names etc. My tip is if it is hard to give it a name is it doing too much or is it not defined enough in the first place.
  • Consistency is key. So you always use brackets for if statements and other code style standards. Don’t then for laziness then change that and write an if statement with no brackets because it was easier, stick to a style.
  • Schedule it. Schedule when you will do a review and when you will do the tasks from one you have published. Don’t wait for the code review to be filled with comments before moving onto another part of the project. It should be fluid, publish code-next feature-review comments-make changes-repeat. I set an hour a day to reviewing my pull requests and creating task lists.
  • It’s a discussion. Someone says they don’t like something, have them explain why and discuss their issue with it. You either agree or not but don’t take it to heart, they are trying to help, be open and honest.

I hope this helps you towards doing code reviews or given you some ideas for next time. I hope to also have some videos/pictures of my work from Dubit up here soon but we shall see. Thanks for reading!