Big Bad Robots is an indie game developer but we also do contract development. We have developed on all kinds of platforms (PC,Handheld,Consoles) but now primarily focus on iOS,Android and Unity. Contact us if you looking for developers with over 20 years experience in software and game development at biz -at- bigbadrobots.com

War Mongrel Gameplay Feedback

December 26, 2016terence

We are looking for Gameplay feedback on our game War Mongrel. It is a real-time tactical mech squad game for Tablets. Right now we have a version for iOS and Android.

Here is a video of the Gameplay:

Here is a quick start guide:

You can get updated on our Facebook page:

Here is the link to our Android APK:

For the iOS version, send and email to testwar@bigbadrobots with your Testflight email. We look forward to hearing from you.

Trying out Xamarin for some iOS and Cross Platform Development

October 28, 2013terence

Now that I am looking at developing an App rather than a game, I have been evaluating using something that allows me to go cross platform and still keep a common code base. I would also like to leverage on my C# since I do a lot of work in Unity but don’t want the Unity overheads. I have been trying Xamarin(www.xamarin.com) for a few weeks but I am finding many issues on the reliability of the development pipeline. Overall the idea is fairly simple, C# integrates through hooks and callbacks to native UI mostly through generated templates. Maybe it’s just because everything is in transition to iOS 7 but there are too many instances where the generated templates don’t work or when running in the simulator against XCode 5, it junks hangs up.

While still keen on getting it running, I may fall back to writing native for the first iteration of my prototype App. I’m going to re-install Xcode 4 and see if it ‘fixes’ anything.

Integrating C++ via the Android NDK.

November 16, 2009terence

I finally had enough time to look at developing on the Android platform and got my test integration of C++ code with the Android NDK working. The biggest hurdle proved to be familiarity with the Android development environment itself. The following tips apply to NDK 1.6r1:

1) You DO NOT have to have surround your functions with a various extern “C”‘s. Unlike what people are saying out there about having to do it you do not have to do it.

2) Check the names of the class to make sure the packages match your JNI interface. (i.e. if your class with the native interfaces are com.examples.HelloWorld…..your JNI class should be Java_com_examples_HelloWorld_<class>

3) Check your android.xml file for the proper package export. When you refactor/rename things in the Eclipse editor it will not update the package export. This will result in Android not being able to find your JNI interface and complain in logcat.

As of 1.6r1, the NDK is something still to play around with and not really ready for production development. That seems to be way the Google Android teams seems to like to run things. Although the OpenGL ES 1.0 libs are available, other supporting libraries are not (i.e. those to load png or jpg’s for texture. The audio libraries). My initial experiments on writing xPhone with Android has a initial platform would prove daunting to say the least.

Android NDK 1.6 release 1

October 6, 2009terence

I was checking the Google Android site and noticed that the Native Development Kit release 1 is out. The exciting part of this release, is that now we can natively write games in C++ with access to the OpenGL ES 1.1 api. This should mean that we can start looking at developing proper games on this platform. This will also mean, that I will need to figure out how to get xPhone to start compiling against the NDK. Unlike my research into Windows Mobile and it’s broken Graphics API support at this time,  this means working with a 3D API versus having to support Direct Draw.

Still need to poke around it more. The bad part will probably be working via Eclipse to get things done. I already have to use 2 other IDE’s (Visual Studio and Xcode) and so a third is fairly unproductive.