What day is it with Unity?

May 18, 2013   admin

Time has been slipping away what with setting up the new Mac and going through my old Linux Mint hard drive to bring everything across. Everything, that wasn’t trashed when the old Linux PC slid off the desk onto the floor while I was trying to make space for the iMac… at least I’d backed up most of the stuff on the old PC before I started moving stuff around.

One of the things that caught me out about Unity is the use of reserved file and folder names. A few days ago, I created a new script file, after which I tried to compile the project. This resulted in a load of errors appearing from nowhere, with messages like “The name ‘Editor’ does not denote a valid type (‘not found’)”. Because this was immediately following the migration from the MacBook to the iMac, I spent some time checking the code to make sure everything had come across properly.

Eventually, I figured out that it was actually the name of the new script that was the problem: “ShapeEditor”. “Editor” is a reserved word which Unity uses to identify editor extensions, and any class that has the word in it’s name has to reside under a folder called “Editor”. Renaming the script file fixed all the compilation errors, but it’s an easy mistake to make, and the error messages it produces aren’t exactly obvious.

There’s other similar reserved words, such as the folder name “Resources” which Unity will look in whenever you call a function such as Resources.Load to instantiate an object at runtime.

Yet more plugins

Progress has been slow on my game because I’m continually backtracking and re-doing bits as I learn more about Unity. I’m not trying to make perfect code, what I am trying to do is to find the most efficient way of writing code for Unity so that the next project will be faster and easier to write.

For instance, I decided that I wanted to add a grid to the level editor so that I could get an accurate view of the where all the objects are placed on the 2D game area. Unity’s line drawing functionality doesn’t seem to be particularly useful – In fact, it’s much like Shiva, the only line drawing calls are used for debugging, and don’t show up in final code.

The logical solution is to create lines using vectors as part of  an object. I started off by constructing a grid from an array of lines in Inkscape, then imported it as an SVG spline to bypass having to figure out how to create an object from scratch with Unity. By messing around with the scale I was able to get the grid to match the size of the blocks on the 2D game area, and then I implemented drag and drop, with the ability to paint new objects into the scene from a palette of pre-defined splines imported from Inkscape. This turned out to be a lot of work because of the calculations involved in lining everything up and have it all at the same scale.

The result was several hundred lines of code spread across a number of files.

Once I had it working, I realised that I needed to alter the size of the grid slightly to account for the relatively narrow screen aspect ratio of some iOS devices. My fiendish plans unravelled due to the difficulty of adjusting the lines on the grid, and then applying the same changes to all the objects in the scene. While Googling for solutions, I came across yet another Unity plugin called “Grid Framework”. It wasn’t free, but for $20, I was able to implement a much better solution that allows me to control the size of everything in the game world from one line of code. The plugin also halved the amount of code that was needed to run the editor… if only I’d thought of looking for a grid plugin before I’d started…

Speaking of purchases, I have just bought a license for creating iOS apps with Unity, in addition to the Android one I already have.

The only outstanding compiler now is the Blackberry one, which I hope will become available soon, and I also hope is compatibile with all the plugins I’ve purchased… I still haven’t heard if Blackberry still has plans to upgrade the old Playbook to BB10 – it would be silly for them not to do it because they need all the goodwill they can get when facing off against Android and iOS.

Read More

Thoughts on the 27″ late 2012/13 Apple iMac

May 08, 2013   admin   No comments

appleimac27

For the past few years, I’ve not been a particularly happy PC user.

Although my PC was cheap, I’m fed up with a large do-it-yourself box of hot, noisy components that breed dust bunnies.

I’m a programmer, not a system builder.

Unfortunately, finding a replacement PC that has decent performance, is cool, quiet and hopefully smaller, has been a challenge. I use Linux Mint (a fantastic OS, by the way), and a docked laptop is probably the closest match to what I’m looking for.

The problem is that the majority of Windows compatible laptops that I could use just don’t meet my requirements. They’re either anaemically underpowered, or are stuffed to the gills with hardware that causes them to be hot and noisy.

Good luck trying to find a model that can output at 1440p for my Dell Ultrasharp monitor.

Due to circumstances beyond my control, last month I was forced to start using a low-end MacBook Pro as my daily driver, leaving my desktop PC to gather dust, which is something it’s good at.

After some time using it, I’ve decided that although it has an underpowered Intel HD3000 GPU, the CPU is more than adequate for the work I do, and it meets my cool and quiet requirements. If I could just buy a version of it with a better GPU that can output at 1440p, it would perfect…

Browsing through Apple’s website, I found the device I was looking for: A 27″ iMac with a quad core i5 CPU, a 1440p display, and a fast GTX675MX GPU.

Although not cheap, there really is no option for me. The closest Windows device that I could find is a 27″ Dell XPS One, which has faster CPU for less money, but the most important component, the graphics card, is a lot slower.

I’d always thought of Apple computers as overpriced, but in this particular case, the high-end 27″ iMac is reasonable compared to the alternative.

Rather than go through yet-another-boring-review, I’ve decided that I’ll just list the things I like or dislike about it, from the point of view of someone who’s relatively new to Apple computers.

Things I like

  • The look.
  • The screen. I was using a Dell Ultrasharp 1440p monitor, and this is just as good, so I’m very happy. It’s a shame I can’t fit them next to each other on the desk…
  • The lack of noise. No more deafening silence when I finish work for the day.
  • The low operating temperature. My old PC could heat the room if the door was shut.
  • The GPU. It’s very capable, though it will date over time because it can’t be upgraded.
  • One cable. It’s so nice to be rid of the bundle on the floor where the dust bunnies nested. The robot can now get under the desk to keep it clean.
  • Timemachine. There’s nothing as easy to use for backups on Linux Mint, which resulted in not backing up as regularly as I should have.
  • Sleep mode. It often doesn’t work properly on Linux because the hardware manufacturers will try to tkeep power management systems secret.

Things that I’m not impressed by

  • Where’s the “cut” option when right mousing on a file? I move files more than I copy them and I shouldn’t have to fumble with the keyboard to do it.
  • Finder regularly misbehaving. Sometimes clicking on the icon does nothing. I then have to right mouse on the icon to open the context menu to bring a window to the front. A reboot fixes it, which is inconvenient.
  • The Magic Mouse. It looks nice, and it works, except when it occasionally scrolls itself without touching it, or when I accidentally brush my palm against the back of it, or when it goes berserk in some games.
  • The wireless keyboard. It looks like a toy in front of such a large screen. A numeric keypad would have been handy, and it’s not like the keyboard would have had to be much larger to fit a couple of extra keys 0n.
  • The “on” button. It’s almost hidden at the back, on the opposite side to where the IO ports are.
  • Open source software. I use a fair number of open source packages, and the Mac really isn’t user friendly for them. Some are native, but don’t work quite right, some require jumping through hoops, such as installing X11.

Things I don’t like

  • Glue. They glued it together, so what happens if dust builds up inside and it needs to be cleaned out?
  • Thinness. Apple have made a big deal about how thin it is, but it’s really just an illusion that makes it photogenic for marketing purposes. I’d be indifferent to this, if it hadn’t pushed the USB ports to the back where they are more awkward to get to.
  • Installing MacOS apps. Some do it though the app store, some manually, some have to be dragged to the left, some to the right, and updates have to be done manually sometimes as well. I’ve been spoiled by Linux Mint where it’s so easy to install software and keep it up to date.

Overall, it’s a great machine, and I can recommend the 27″ models for anyone looking for a no-fuss desktop computer that’s easier to live with than a laptop. Although pricey, it’s not excessive considering the hardware inside.

I’m not so keen on the 21.5″ models though. When compared to the larger ones, the specs on the smaller iMacs are significantly weaker, yet the price is fairly high. If you are set on an all-in-one iMac, and were looking at the 21.5″ models, I’d definitely try to scrape up a little more cash.

Read More

Day 9 with Unity: RageSpline + Inkscape

May 04, 2013   admin   No comments

This project is going to be a simple game in which the player positions a selection of objects around the screen, then lets the physics simulation take over to see what happens. Because I’ve largely completed the GUI part of the app, today was the first chance I’ve had to actually work on the actual game bit, which means I had to figure out how to the graphics into Unity.

I’ve decided to use Rage Spline for my sprites, so the graphics need to be created in a vector drawing tool such as Inkscape (free on all platforms) or Adobe Illustrator (expensive and on few platforms).

The version of Rage Spline I purchased is called Rage Suite, which isn’t available on the Unity asset store. It includes tools to import SVG files created by Inkscape, which I’ll be using because I live in Australia, a country where it’s cheaper to fly to the US to buy high-end Adobe products in person than it is to buy them locally.

There are a few rules that have to be followed if you want your vector drawings to export cleanly from Inkscape. Rage doesn’t support all the features of the SVG specification.

First of all, ensure Inkscape is set to optimise transforms. Open Inkscape, click on the File menu, choose Inkscape Preferences, select Transforms, and choose optimised from Store Transformation. This will “suggest” to Inkscape that it shouldn’t write out transform() instructions as part of the SVG file. It’ll still write out transform() under certain circumstances though.

When creating your image, keep it simple:

  • Radial gradients will be converted to linear gradients when they are imported into Unity
  • Only the first two colour stops of a linear gradient will make it into Unity.
  • Effects like as blur will be ignored.
  • Primitives such as rectangles or circles will import, but they will be messed up. All objects need to be converted into paths.
  • If you move, scale, rotate or transform an object using Inkscape’s transform menu, it has a high chance of screwing up that object so that you’ll never be able to get it to import correctly into Unity.

There’s more to it than just keeping it simple though. Once you are happy with your image, it’s time to export. You’ll need to completely ungroup every object in the image because groups that have been moved always have a transform() applied. Ungrouping them will remove them and the transform.

It’s also a good idea to manually examine the XML for every object to make sure there are no hidden transform(). You can open the XML editor from the Edit menu. If you find any transform(), the stupidly easy fix is to move the object slightly – ie. press the left, then right cursor key to nudge it left, then put it back where it was, forcing Inkscape to get rid of the transform.

Once you’ve checked everything, you can regroup the image parts if you want. Just make sure that you don’t move anything, or Inkscape will put a transform() onto the group and you’ll have to ungroup again to get rid of it.

A lot of work, but as I understand it, the same restrictions apply to Illustrator.

Anyway, I created a marble in Inkscape, imported it, and now I’ve got the application auto-creating the marble object in a scene when the user hits play. Not much to look at, but there’s a lot that’s been completed behind the scenes.

Screen Shot 2013-05-04 at 9.15.11 PM

Using Inkscape on a Mac

I should point out for future reference, that Inkscape on a Mac is a bit of a pain because it’s needs X11, which Apple removed from Mac OS last year. There’s plenty of guides online for setting it up using something like MacPorts (apt-get is so much easier on Linux).

There aren’t however many references to a bug in Inkscape that breaks Python, which Inkscape uses for it’s filters and extensions. Attempting to run something in Inkscape that uses Python will give you an error like:

The fantastic lxml wrapper for libxml2 is required by inkex.py and therefore this extension

Although annoying, it’s pretty easy to fix if you are lucky enough to stumble across reply #7 on this page.

Auto-saving and Unity

I made a silly typo this afternoon, which created a recursive loop in some code I was testing, and Unity got stuck in it. Unfortunately, Unity doesn’t have a proper auto-save feature, so when I force closed it, I lost about four hours of work because I’d forgotten to hit manually save since lunch time.

This reminds me of a similar annoying bug that Blender devs also won’t fix  (yes, it’s a bug, not a feature), which lets you accidentally hit the shortcut key combination for Quit, resulting in the exiting suddenly, losing any work you’ve done since the last save.

Like Blender, Unity also has a sort of work around: Every time the project runs, a temporary save file is created called “__EditModeScene”. If you want to recover your work, you’re going to have to remember it’s there before you re-start Unity, or it will be erased.

I worked with ShiVa for over two years. It would crash on a regular basis because I was running it in a Windows VM on a Linux machine, but during the last 18 months, despite hundreds of crashes, I never lost any work. In the last two weeks, I’ve repeatedly been caught out by this Unity’s lack of auto-save, and I know I will continue to be caught out at random intervals because I will continue to forget to hit save when I’m in “the zone”.

Computers are supposed to automate repetitive tasks.

Read More

Day 6 – 8 with Unity: XML

May 03, 2013   admin   No comments

It turns out that there’s one thing in Unity that doesn’t have an adequate 3rd party plugin for, and that’s reading and writing XML files.

Based on what information I could find, there’s probably two main reasons why there’s no “silver bullet” for XML. First, the XML library adds significantly (500KB) to the size of an application, so devs often “roll their own” XML parser. Secondly, the Unity Web player used to have some sort of issue the XML library, I’m not sure what was wrong, perhaps it wasn’t implemented. The second problem seems to have been solved, and 500KB on a 20MB+ app doesn’t seem like that much of a problem these days , so I’ve decided just to use the standard XML library.

One of the benefits of using the standard XML library is that it’s possible to read and write an XML file without writing much code. If the class follows a standard structure, then the XML library will be able to figure which properties of the class match up to attributes and values in the XML file.

Unfortunately, I encountered a bit of a problem with this process. It seems that the XML library can only handle nested arrays down to about three levels. Beyond that, it seems to complain.Meanwhile, back in the present, I followed an example for creating an XML file. This seemed to work quite well, until I tried nesting my XML structures more than two levels deep, at which point Unity spat out errors. I’ve investigated this as far as I care to, and it appears that nesting XML structures to three or more levels just doesn’t work.

An alternative that I found was to use TinyXML, a custom script, but it is pretty limited, doesn’t support attributes on elements, and I’d have to come up with a method for writing out correctly formatted xml myself… not too difficult, but I’d rather use built in functionality than “rolling my own” because I’m interested in how fast I can write code, not how beautiful it is.

Rethinking my design allowed me to come up with a new structure. If I broke each page of levels into a separate file, then I could have a structure where I manually read and wrote the top most level, but used Unity’s built in serializer to handle the arrays that are part of each level.

Once I’d implemented reading, writing became trivial, with the only difficulty finding out how to format the output so that it was clean and included line breaks, because I wanted to be able to easily read the output from the save routine, in case the level editor produced weird output.

With XML reading and writing finished, I then went back to the GUI and added in a very basic paging system for showing levels: an array of 12 buttons arranged in square layout. Each page represents a level data file, so there’s only a maximum of 12 levels in each file.

At this point, I’m pretty much hardcoding everything. As I mentioned, I’m not interested in “reusability”: It’s a nice concept, but for games, with the exception of games that have a long shelf life, or massive projects, there’s not much use to continually going back over the code and refactoring every time something gets adjusted. For smaller projects, it’s a huge time waster, and easy trap to fall into if you enjoy coding. 90% of the my app’s code reusability will come from the plugins I’ve purchased, and I’ll leave it up to those developers to maintain their part of my app’s code.

Read More

Day 5 with Unity

April 23, 2013   admin   No comments

Four days down and I’m making some good progress with Unity.

I decided the best way to tackle learning Unity was to build a complete game from scratch, starting with the UI, and incorporating the plugins I purchased as I went along, to minimise the amount of work I’d have to do.

Starting on day one, I created a new project, added NGUI to it and dragged a few buttons into the scene to act as a main menu. To keep things simple, I wanted to avoid creating a different scene for each menu, and instead created all the menu panels in the one scene.

This presented a challenge because of the way Unity handles inactive objects. Once an object is disabled, it can no longer be found using Unity’s search functions. The developer has to store a pointer to the object in order to find it again, or it can’t be reactivated.

Based on my Googling, Unity developers have been complaining about this problem for many years. As I understand it, the built in functions for locating objects are considered to be very slow, so it’s recommended not to use them anyway. The workaround was to create a singleton class (also frowned upon by some, but it works) that held pointers to all of the important objects in the menu system, such as the menus themselves and specific controls on the menus.

With my global class in place, it was very easy to extend it to include user preferences such as sound or music volume settings, using the Easy Save 2 plugin.

I wanted to build localisation in from day one, so the next step was to add a language selection page to the menu and add Localizer Package. This is quite a clever solution as it uses Google Docs to store a spreadsheet that uses Google Translate to provide translations for key/value pairs in the first two columns on the sheet. Obviously, since it’s machine translation, the result aren’t always the best, but it’s better than nothing.

The easy languages to translate are Spanish, German, French, Italian and English, because they largely use the same character set.  To this I added Portugese which is quite a common language online and fairly similar to the others in structure. Russian is also popular, so I created a new version of my font to include the Cyrillic character set.

Beyond these European languages, things start to get a bit more difficult. Arabic and Indian both have a basic alphabet, so they aren’t too different to the others to work with, but finding a suitable font with the characters can be difficult.

The other major online languages, Korean, Chinese and Japanese are composed of thousands of characters, and because Unity stores characters as bitmaps on mobile devices, it’s nearly impossible to translate on the fly. The recommended solution is to “bake” phrases into bitmaps and use those, instead of text. For now, I’m just going to stick with simpler languages because I don’t want to have to limit the amount of text I have in my app.

At this point, I have to say that things are going quite well. I now undersand Unity’s internal structure, I’ve successfully implemented PlayMaker, Localizer Package, Easy Save 2 and NGUI into the application, and it’s definitely saved me time. I’ve even managed to build an Android version of the app and try it out on my tablet, and it works just like it does on my Mac.

The next step is to create the actual game part of the project, which is probably going to take another five to seven days, just to get it to the functional prototype stage.

Meanwhile, Stonetrip are still keeping secrets about what’s going on with Shiva. Presumably, they are working behind the scenes to emerge from receivership and open shop in Estonia, but who knows? Unfortunately, none of the users do, and it’s all too little, too late for me. I’ve already made the switch to Unity, and there’s no looking back now.

Read More

Unity3D vs Shiva3D

April 17, 2013   admin   No comments

In the hours following the news of Shiva’s (temporary?) demise, I purchased a copy of the Indie version of the Android compiler for Unity. I already knew that it would be suitable for what I wanted to do, so it wasn’t really a leap of faith. The only real concern I had was how long it would take me to get up to speed.

It did take a few hours to wrap my head around the way scripting works in Unity, and although it does work, I find it a bit untidy. Because of Unity’s strict object-oriented design, everything in a scene is derived from a basic object, which then has numerous scripts attached to it, to grant it the properties and methods that define it. Shiva’s approach is to uniquely define the properties of every type of game object, and then provide a collection of functions to manipulate it.

While I find the structure messy, I can see the benefits of doing it Unity’s way – in particular, with 3rd party plugins. The standard objects that Unity provides can easily be enhanced simply by attaching scripts defining new methods and properties.

Speaking of plugins, Unity has lots of them, and many are high quality. Shiva belatedly acquired an asset store late last year, but due to the smaller community there hasn’t been many plugins added, and potentially useful plugins are largely API wrappers for iOS.

Besides the smaller user base, I suspect Shiva’s biggest issue is that the plugin structure isn’t very flexible. It’s not straightforward to integrate with Shiva’s API, especially trying to call back to the game API from a plugin. Plugins also have to be written in native code, not Shiva’s scripting language, which makes it hard for anyone who only knows Lua.

I started off browsing through Unity’s asset store, and despite tremendous willpower, my cart was repeatedly loaded up with the following add-ons:

  • NGUI: like Shiva, Unity’s default GUI needs some love. I’d written an elaborate GUI layout tool that used XML files for my Shiva apps and I didn’t want to go through that again. I’ve read that Unity will be getting an improved UI system, but since it’s not happening this week (or on any specific date), I’m going with NGUI. I doubt learning it will be wasted time, because Unity’s solution should be similar as they are both being created by the same developer.
  • Playmaker: Increased productivity through code avoidance. I had a bit of play with it today, and I can see that it could be very useful in many situations, especially prototyping.
  • Easy Touch 2.5: A package to handle touch gestures. It was only $20 and included a joystick which was a pain to setup in Shiva the first time I did it. I may still buy FingerGestures though, because it supports Playmaker, assuming I become a Playmaker disciple like so many others. One day perhaps, Unity might be considered an essential add-on for Playmaker?
  • Localization Package: An efficiently titled, simple method for handling basic app localisation. I’d actually written something similar to this for Shiva too.
  • Multi-platform Toolkit: Very important, and yet again, something I’d crudely implemented into my Shiva apps.
  • 2D Toolkit: Sprites! Another module I’d written for Shiva. I gave up on my sprites because Shiva hasn’t yet been given the ability to directly call functions in one script from another. Everything has to go through events, which are slow. This meant that in order to implement sprites, I’d either have had to write a plugin in native code, or copy all the sprite functions into the scripts that needed access to them, resulting in code duplication and maintenance issues. Couldn’t be bothered.
  • Rage Suite: After I’d bought 2D toolkit, I found out about this gem. 2D vector sprites, similar in style to Flash. I ended up buying the full pack, including Rage Spline and its add-ons, because I wanted the SVG importer which is going to save me a lot of messing around.
  • Edy’s Vehicle Physics: I bought this out of curiosity. The last thing I’d played with on Shiva was the vehicle physics demo that is supplied in the samples. Shiva’s version works, but would need a lot of work to bring it up to the standard of Edy’s, which also runs surprisingly well on mobile devices.

I started writing this as a comparison of Unity and Shiva, and it’s turned into a quick review of some of Unity’s 3rd party plugins.

At the end of the day, both Shiva and Unity do the same job. A Unity game might look more professional because of its shader support, but Shiva is easier for a novice programmer to learn, and it has better cross-platform support.

What really sets these apart are the 3rd party plugins, of which Unity has far more of far higher quality, thanks to the way it’s implemented and the larger user base.

In total, I’ve probably spent $500 over the past few days of testing. For that money, based on my experience, I’m convinced that I’m going to save myself many, many months of my time, which is incredibly important because the software industry moves so fast and I’m just a team of one.

Read More

Goodbye Shiva, hello Unity

April 15, 2013   admin   No comments

Beginning in early March, I have been unable to build any apps for Blackberry Playbook devices. This is either a bug in the Shiva3D build process, or a change that was made in the latest Playbook update. Either way, new builds of old Shiva apps won’t work – they install, but crash instantly.

It’s probably a simple thing to fix, and although I’ve reported it to Stonetrip, I’ve not been able to get a response from Shiva’s normally responsive support staff.

A couple of days ago, I finally found out why: Stonetrip went into administration sometime in Decmber, and is now in liquidation.

Based in France, this doesn’t necessarily mean that Stonetrip is finished. The rumor is that under local business rules, a company can use the liquidation process to restructure and  then resume trading. Further industry rumors report that Stonetrip could be trying to relocate to a country with more favourable business rules.

I can understand that there must be legal issues which are keeping Stonetrip from publicly announcing the situation, but as a developer who is trying to run a business, it’s disconcerting to discover that your primary tool provider has gone broke from rumors.

I’ve had a feeling that something hasn’t been right for some time. Stonetrip has kept up a furious pace releasing updates to the old 1.9 series of their software, while the big 2.0 release that we’ve been promised for  years has failed to materialise.

While it’s been great for me, since I’ve gotten more than my money’s worth for the 1.9 license I purchased so long ago, it’s also meant that Stonetrip hasn’t had a viable income stream from existing developers, yet they’ve had the expense of providing support.

I can imagine it’s been an uphill battle. Constant work on the old release, constantly adding new platforms, all the while trying to squeeze in a few hours here and there to get 2.0 out the door.

When I first began looking into mobile development, Shiva3D beat out Unity3D because it was cheap, supported the devices I wanted to target, offered most of the same technical features as Unity, and ran in a VM on my Linux PC. Since then, Unity3D has caught up. It can now be used to produce apps for many of Shiva’s main platforms, and the price is more palatable. I also happen to have a MacBook sitting idle, so I can use that instead of having to buy a Windows PC.

The best news for me is that Unity will be supporting the Blackberry 10 OS in the next few months.

I’ve decided that the time has come to move on. I’ve played with Unity for the last day or two, and it’s all pretty similar to Shiva3d; I know what Unity should be capable of, so it’s just been a case of figuring out the particular command or button press to do it. I also already know Javascript and C#, so I won’t have a problem there.

I really hope Stonetrip can recover from this setback, but I don’t have the time to wait and see what will happen. My fear is that they’ll start up in another country, have insufficient funding and the same lack of focus in trying to support too many platforms, then end up in a similar situation in 12 months time.

Read More

Solar Explorer: Black screen of doom

February 20, 2013   admin   No comments

Occasionally, despite the best of intentions, things can go wrong.

I released an update to Solar Explorer for all markets on the weekend, both paid and free versions.

As a special bonus, it came free with a limited edition bug that that basically caused the app to start up with a black screen and do nothing, except burn CPU cycles.

It was a really simple error – a file the app expected to exist, had accidentally been dragged and dropped into a sub-folder between the test builds and the final release.

To top it off, my mail server had crashed from a spam overload the day before the release, so although people were sending me a big “WTF?”, I wasn’t receiving any messages.

It was 24 hours before I realised there was a problem, and I released a quick fix, but it took me a further three days to notice that I wasn’t getting any email from my apps account.

I’ve now reactivated my email, so thanks to anyone who posted a query here, or sent me an email.

I’ll have to have a stern chat with the quality control department!

Blackberry Apps

Meanwhile, I’m still waiting for Blackberry to get around to testing the apps I submitted to the final port-a-thon, so long ago.

I’ve been busy submitting updates for all of them, and they’ve just been piling up – one app has actually got three versions waiting for release.

underreview

Unfortunately, Blackberry don’t provide a way for me to delete the obsolete versions, so I hope they notice the higher release numbers and don’t waste time on them. It could explain why they are so slow, if they have to slowly make their way through obsolete versions, while even more are piling up.

Because of this, I have bothered to submit the latest Solar Explorer update yet, because it’ll just slow them further. I’ll release it once they’ve cleared the backlog.

At this point, I’ve technically had only one app accepted or the $100 port-a-thon payout. I hope they don’t just ignore the other four apps because they haven’t had time to test them. Admittedly, they were rejected the first time because of screen orientation issues on the new BB phones, but that was beyond my control because hardware for testing wasn’t available at the time.

Read More

AVG for Android: antivirus gone bad

February 11, 2013   admin   No comments

I’ve been  getting sporadic reports from users that some of my Android apps have spontaneously become viruses or malware.

The one thing they have in common is that they are all using AVG Anti Virus for Android, and they all updated it recently.

Looking at AVG’s page, it’s apparently something they’ve done. Sifting through the recent comments reveals a number of people with similar, strange malware reports.

And it really sucks when the malware is apparently built into your phone’s ROM.

Thankfully, it’s been fixed, so I won’t bother reporting it myself.

It’s no doubt affected a lot more people than those that left comments, but they probably think that AVG saved them from a sudden flood of viruses.

Other developers are suffering too.

One of my apps has collected a comment warning others not to install it. This sort of thing can be deadly for a small developer, but thanks to Google requiring Google+ accounts, I can at least contact the commenter and let him know that AVG was wrong.

Hopefully, everyone using AVG will update and the problem will go away… at least until the next time AVG doesn’t test their software properly…

Read More

Impulse – an updated Thrust

January 27, 2013   admin   1 Comment

Impulse is my interpretation of Thrust, a gravity game from the early 1980′s.

I started the project, over a year ago, as a Shiva3D learning exercise, inspired by a clone of Thrust I’d found on Android Market. The biggest complaint from users of the clone was that the touch screen version had controls which made it unplayable. I decided to fix it.

At about 70% of the way through the project, I’d learned what I could and decided to shelve it.  The game was largely playable, but it had no UI, needed more graphics and also required some serious polishing. All of this is very time consuming and I couldn’t see any commercial viability at the time.

Recently, I’ve decided to move forward with my plan to release a number of smaller, good quality game projects, using the “shotgun” approach to get  noticed and hopefully help support Solar and Exoplanet Explorer. Finding time to implement the plan was the main issue, which sort of resolved itself when Blackberry announced their final Portathon. That gave me enough incentive to dust off a few of my old projects and quickly finish them off. Impulse was one of these.

Design

I’ve decided to implement the first 12 levels of the game, which featured six distinct level designs played in two different modes. I never managed to complete the game, because I found the third and fourth modes, which featured invisible walls, impossible. The game was renowned for it’s difficulty level, but I’d rather make the game a bit more accessible. People who enjoy cutting their lawn with a pair of nail clippers can always fire up an emulator and play the original.

The levels mimic the layout of the original game as does the ship design. Everything else is up for grabs though, and I’ve made some significant changes to the controls because a touch screen doesn’t really lend itself to button/keyboard layout that the original used.

The problem with touchscreens is that there’s no tactile feedback, so if you have too many buttons to press, it’s easy to end up losing your place. With this in mind, I’ve decided to get rid of the shield button, and just make it automatic. This change also requires the limpets (enemy turrets) to shoot more often and be more accurate to make up for the distraction they used to cause. Each hit causes the shield to briefly flash, followed by a significant decline in fuel reserves. Unlike the original, running out of fuel isn’t game over, but it does lose you a life.

Although I wanted to keep it to two buttons, there is a third that’s used to activate the tractor beam, which is semi-automatic. When you get close to something that can be grappled, the tractor beam button lights up. Tapping it will activate the beam, which will remain engaged until you’ve either filled your ship’s fuel tanks, or latched on to the pod.

Oh, and the plot is different too. I can’t really recall the original story, so I’ve decided not to refresh my memory and just make up my own.

Thrust

A shot of the first level from the original Thrust

Impulse

A shot of the same first level from Impulse

Blackberry update

Well, RIM seem to be getting through their app submissions from the last Portathon. So far, I’ve had all of mine rejected due to technical issues on the BB10 platform, and additionally, Impulse because the enemies don’t shoot in the version I submitted.

Yay!

OK, I had a feeling Impulse would be rejected because I’d had to work flat-out for 36 hours getting my five apps ready for submission. There were bugs in it, but I’ve spent the past few days fixing everything. It should be ready to re-submit in the next day or two.

Read More
« Older posts