The last week has been pretty busy at home but I still managed to get a reasonable amount done on Bubblision:
- Player bubble burst particles
- Player bubble burst and reinstate
- Instantiate NPC bubbles at run time
- Detect touch position based on game area and not pixel dimensions
- Did a test Android build and checked tap detection
Other things I did:
- It’s the end of the F1 season so I did a number of things to prepare RF1 for the “off season”
- Looked at migrating RF1 to Django 1.6
- Finished the main part of Casual Revolution (although I’m still reading the appendices)
- Player bubble burst and re-instantiate
- Instantiate NPC bubbles at runtime
- Set collisions between NPC bubbles and the player bubble
Two weeks (ending 02/12/2013)
Well, I have to say that I didn’t think I’d complete all the tasks I’d allocated to this sprint. The tasks themselves were a bit tricky and on top of that a combination of people visiting us, the kids having colds and me having to do some unexpected work on another project meant I didn’t have much time to devote to this sprint.
That said, I managed to complete the tasks and I’m pleased with progress. Although you could argue that completing the tasks despite not having much time to work on the project suggests I underestimated what I’d be able to get done in the first place.
The tasks I completed on Bubblision were:
- NPC bubble bursting and removal
- Created artwork for the spikes at the bottom of the playing area
- Particles for the NPC burst
- Created the player bubble asset and randomised the colour
- Launched the player bubble on tap
Aside from all the tasks listed I’ve also created another progress video. This time I did it on a different Windows machine using VLC and it’s turned out ok (albeit with no sound yet). I tried to use Jing on the same machine but the results were as dismal as before so I’m putting this down to the software now and not hardware (as I had before). I won’t attempt to use it again.
- Upgraded the Glossary to CakePHP 2.4.2 (again!)
- Moved an entire website (3,000 files and five databases) to a new host (in less than 24hrs) due to a hardware failure
- Wrote a blog post about the move
- Sweated over whether I got some DNS changes correct, I had 😉
- Read more of Casual Revolution
Part of the reason why I’ve not achieved as much as I’d hoped this week is that the web server that hosts another project I look after had a hardware failure. It’s shared hosting with Dreamhost and they attempted to recover the site from their backups.
This is really frustrating for a number of reasons:
- Their backups are three days old and I’ve got daily backups so mine are much newer (they tell users not to rely on their backups… so I didn’t).
- Their backups are incomplete… sigh. When setting up their backups someone obviously decided it would be a good idea to exclude any files found in a directory called ‘tmp’. However, some web frameworks, such as CakePHP, store logs and cache files in a ‘tmp’ directory within the app. The result is that when the host recovers the files from their backups the apps won’t run as they are missing the directory structure they expect in ‘tmp’.
- In order to copy the backed up files over to the new server and still serve the sites in the mean time they mount the backup file system across the network. Not only do you get network latency but the restore process is pretty heavy. Since the restore process started the load on the server hasn’t been below 250 and is often up at 500! The result is a site that’s partially broken (see 2) and, when it can serve content, the content is out-of-date and takes 20-30s to be served due to the load.
- When they came to use the backup server they found it to be “degraded” so the recovery process is taking even longer. It’s currently been running for four days!!! (Update, still running 12 days later.)
I understand the host’s reason for what they’re doing (they can’t rely on everyone to take backups and this is the least hassle recovery path) but they haven’t offered those customers that have good backups an opportunity to get their sites up quickly. I raised a ticket asking to be moved to another server and, although they replied to the ticket, they just referred me to the current “update” message which apologised for the load on the server and mentioned the “degraded” backup (which I’d already seen). They even had the cheek to suggest one way out of the current predicament was for me to buy one of their Virtual Private Servers! As if, following four days of downtime and with them unable to give an ETA for the end of the recovery, I’d spend money on a VPS with them?
The whole episode has left me wondering what the point of my backups were when I couldn’t use them to recover my site with Dreahost? So I decided to make use of them, I signed up for some new hosting and moved the site using my backups. This wasn’t a quick or easy process (we’re talking five databases and a mixture of Perl and PHP code and some 5,000+ files) and it took about seven hours work (although this wasn’t continuous) to get things set up and tested. There’s also the time it takes for the DNS to propagate but Dreamhost’s recovery process is so slow that I think the seven hours I spent and the time to propagate (even if it’s 48hrs) have not been lost. There are a couple of bonuses with the new host but the main one is speed, the site zips along faster than it ever has… so, the whole process has been a bit of a pain but not necessarily a bad outcome. The move also prompted me to complete the site documentation I’d been writing so that’s good too.
I still think it’s a massive shame that I’ve had this experience with Dreamhost. They still represent good value for money and offer a lot of flexibility. It’s unfortunate that the flexibility didn’t extend to the recovery process and effectively forced me to move one of my accounts.
UPDATE – After more than two weeks the server was still struggling under high load and the messages in the customer panel were giving no new information. This meant I was right to move the site when I did although I still feel a little sad that the situation led me to have to do that in the first place.
For a variety of reasons I’ve not had as much time to devote to my game project as I’d hoped this week. As a result I’m a bit behind where I’d like to be in terms of the current sprint. That said, I still managed to complete a couple of tasks:
- The non-player bubbles now burst (albeit the particles still needing a lot of work) and are removed from the game area if they reach a certain point
- Created art work for the spikes at the bottom of the playing area although on import the texture loses some quality so I need to investigate that issue
Part of the reason why I’ve not achieved as much as I’d hoped this week is that the web server that hosts another project I look after had a hardware failure. Getting the site sorted out has been a frustrating process (despite me having full backups). I plan to write a separate post about that sorry episode so won’t go into it here.
Other things I did over the last week:
- Migrated the Glossary to CakePHP 2.4 – only to have that work lost through no fault of my own. Thankfully my code is all in Git so no big deal.
- Migrated RF1 to Django 1.5.5
- Read a tiny bit more of Casual Revolution
- Listened to a few more talks form Casual Connect
- Create NPC bubble burst particles
- NPC bubbles burst and remove
- Create spikes at the bottom of the playing area
- Create player bubble
- Launch player bubble on tap
Two weeks (ending 17/11/2013)
It’s the end of Sprint 2 for Bubblision and I’ve completed all the tasks and fixed a few early bugs. One of the major tasks this time was to do the first Android build and seeing the first dev build on my phone (even though it’s not playable) was a big milestone.
- Set up Pivotal Tracker
- Adjusted game area
- NPC bubble collisions
- Background art work
- First Android build
- Stop NPC bubbles getting stuck at the ede of the playing area
- Made sure the Android back button (to quit) was supported
- Looked at screen capture
- Uploaded a first development video
Of all the tasks, the most frustrating was setting up screen capture for recording game play. I tried VLC and Jing under Windows but both resulted in very choppy play back. I think this was due to the low spec Windows machine I’m having to use at present rather than Jing or VLC – given how good VLC is at most things to do with video I’m sure it can’t be at fault here. Jing seemed ok and I liked being able to pick an area of the screen to capture but having to sign up for a TechSmith account before I could even try it out was frustrating – this was made worse as they reject email addresses that contain a plus sign despite the fact that these are perfectly valid (sigh).
In the end I did a Linux build in Unity, copied the files to my Linux box and did the screen capture there using SimpleScreenRecorder. Job done.
Anyway, here’s the first development video (no sound and a bit basic but it’s progress):
Other than the remaining sprint tasks, this week, I also…
- Created a pixel art logo for ‘Mucky Creature’ (the working title for the name under which I’ll publish my games)
- Did a bit of research on mobile Ad networks and also on game publishers
- Listened to a few talks from Casual Connect
- Played a bit of GTA 5 😉