Saturday, 25 May 2013 is now up and running!

Hey all :D

I got my website uploaded and running! Yay! Check it out at!

I know the layout is pretty basic. But Rome wasn't built in a day (and they had slave labour!)

Please note that this site was made with Firefox in mind but runs real nice on Google Chrome. If  you use Internet Explorer however I'm afraid you're gonna have a bad time!

It's one of the many quirks of web development I learnt. You're all "Ah this looks pretty swanky...I wonder what it looks like in IE.... OH GOD WHAT IS THAT? WHY? WHYYY? D:"

So yea, don't use IE until I fix my site for it.

Most important note of all is you can now play my Runes game on it :D

I'm working on setting up an email for feedback, so hopefully that'll be available soon so I can have the internet insult me Youtube comment style.

Have fun!

Thursday, 23 May 2013

Little steps, little stumbles

Hey everyone,

Well since my Runes game is as done as it's going to get I thought I'd make a quick post to cover what I'm currently working on.

It is strange how, while you're working on a game, you just want to keep adding to it. You feel the need to improve on it more and more. There are a few minor bugs left in my Runes game. And there are a ton of features I wanted to put in. But I feel that I need to use my time working on something new, to learn new things and to try and apply the things I learnt thus far.

Today and yesterday I spend working on my website, which I'm hoping to host soon enough. It'll allow everyone to actually play my games rather than just read about them!

The site is pretty much done and I have my Runes game running in a web browser just fine. It took me a while to make the site and get it all running properly. I found that I hate web developement. There is no writing code in web developement. Only trying to match colours and get boxes to go where you want them to go! Uurgh!!

But I did a pretty ok job I think, seeing as how I was using Notepad and don't have that much experience. I know that somewhere in the near future I'm doing to have to convert some of the HTML into HTML5 compatible stuffs. And I know lots of web developers out there will laugh at all my Framesets. But screw it I have games to develop!

Other than that, since the Unity3D guys have been awesome and released their mobile licenses for free I have been messing about with that. I have got the android SDK up and running and made my first hello world app. Testing it on the emulator and its working :) I'm working on improving it now - just working through all the SDK tutorials.

After that I'm hoping to hit up the Unity3D mobile tutorials and get a game on mobile! :D Andriod preferably since I can test on that phone.

I am also designing two games at the moment. One a mobile app that I want to develop once I get more XML savvy and refresh on Java a lot. And also wrap my head around how the mobile developement pipeline works. So much to learn and so little time!

The other game is going to be a stand-alone PC game. I was planning on making this an HTML5 based game and perhaps linking it to Facebook with the Facebook API but the game I have in mind wouldn't work on a browser. I wanted it to be single player anyhow. But I'm still designing the actual game and padding things out.

One big thing I learnt thus far is the importance of design so I'm not skimping on it this time around!

Anyhow, I think I'll play a game for a bit before heading to bed. All work and no play something something ...

Tuesday, 21 May 2013

Runes: Songs of the Gods - Version 1.3

For this I mostly added polish issues that were annoying me during development. I also got two very skilled people (testing is what they do for a living! :D) to check out my little game and make suggestions.

All of these things lead to the following issues being addressed.

  • Improved the runes after three were done being selected. To make newer ones spawn faster so the player isn’t left waiting too long.
  • I did this by calling the GetNewRune(); function immediately after the three runes were reset
  • Tweaked my light fade in / fade out function that I was quite proud of. Made it so it doesn’t blind the player completely.
  • Cleant up the introduction audio so the wind didn’t start until the whispering voice was done. This meant that you could now hear the voice and not just sense a mumble :D I did it by adding a check to see if the voice audio was done - if(!IntroTalk.isPlaying).
  • Made the bonus score more interesting. It now adds your score at certain thresholds rather than a simple + 10 points. This means that you’ll get around +50 then +100 then + 150/200 as you reach the bonus thresholds. BUT I made it work like a killing spree works in other games. 
  • This means that when you reach a threshold and mess up somewhere along the line the bonus score is completely lost. So it’s a lot trickier because you either have to take your time (and waste game time) or risk it and try and click that one lingering rune a split second before it changes.
  • Made it so that runes were now de-selectable as long as only 1 or 2 runes were active. The new AddToArray functionality made this super easy :D It adds a little more pace to the game. 
  • This was a very good suggestion from feedback I got and also allowed missclickes to be corrected!
I found that people playing the game were seeing things that I never noticed and felt the game played in different ways. They had different points of view about what the game was lacking or needed to improve on.

I really started seeing the benefit of having people play unfinished versions of my game and I wish I had done this sooner. I will make a note to get people to play earlier versions on my future games as often as possible!

Runes: Songs of the Gods - Version 1.0-1.2

Version 1.0 - 1.2 - Fixing the Match-Making

I'm going to try and make this post less wordy. Now that we can at max select three runes I worked on the next major bugs.

In this build I fix:
  • Matchmaking not working corretly when runes are missmatched.
  • Matchmaking not working correctly when runes are matched.
These bugs happened quite often and as very noticable so I went about fixing it. It's worth noting that most of this stuff I write down in my little notebook. So I am hoping all these posts don't sound to chaotic.

When a fail state was reached it would still count a score point if the following was true:

Rune 1 = Val_x
Rune 2 = Val_y
Rune 3 = Val_x

This was due to the code I had at the time, which I was super proud of because I thought it was fancy. Obviously I was being too fancy for my own good!

    void CheckArray(){
        string tempStr;
        tempStr = RuneSet[0];

        for(int i = 0; i < 3; i++){
            Debug.Log("RuneSet[i] is: " + RuneSet[i]);
            if(tempStr == RuneSet[i]){
                isMatch = true;
                isMatch = false;
                MakeGodLight = false;
            CheckArrayToggle = false;

Because RuneSet[0] would always be equal to tempStr it would always be a match (isMatch = true). The next rune Rune[1] could be true or false so here isMatch could be set to either true or false. After this Rune[2] could be true or false which meant that here isMatch would be set to true or false depending on if it matched Rune[1]. This meant that the little algorithm above never really cared for Rune[1]. It didn’t matter if it matched or didn’t. It only took Rune[2] into account as that was the last value reached in the loop.

My fix was much simpler. Occam’s razor I guess.

        string tempStr;
        tempStr = RuneSet[0];

        if(RuneSet[0] == tempStr & RuneSet[1] == tempStr & RuneSet[2] == tempStr){
            isMatch = true;
            isMatch = false;
            MakeGodLight = false;
            BonusScore = 0;

This was fixed and I rejoiced and felt cautiously optimistic that I fixed my final major bug. Even though, at times, when matching three of the same rune the IsMatch would not toggle to true. I was hoping that this was “somehow” caused by the above code and that I fixed it. But obviously that’s not the way code works and hoping is not the same as thinking things through.

While testing I found that even though the miss-matched rune bug was now fixed, the three matched runes bug wasn’t. I started debugging by hitting different combinations of runes and using crazy amounts of console output.

The bug was tied to the game objects (the runes) name and the how the Instantiate function works. The game object was being created as I mentioned in a previous post. But it wasn’t making a new game object from scratch – it was cloning the previous one. I didn’t know this until I started looking into the (clone) functionality and what Instantiate actually did.

This meant that I could at times have something like the following:

Rune1 = Stone1
Rune2 = Stone1(clone)(clone)
Rune3 = Stone1

Because I was using the game objects name (the runes name) the “(clone)” was added to the array. And obviously this meant that Array[0] != Array[1]. So I had to find a way to get rid of those pesky (clone)s!

As a sidenote, my girlfriend actualy mentioned that the (clone) name might be causing issues when she first checked out my little game in very early builds. Guess she can say "Told you so" now :D

I searched the interwebs and the best solution to my problem seemed to be renaming the game object. By now it was late and I was not thinking straight so I did dumb things like:

case 2:
RuneType = 2;
    Instantiate(Rune2, transform.position, transform.rotation); = "Stone222";
    Debug.Log(" " +;

This didn’t work at all and I wasn’t thinking through my problem at that time. What I had to do was rename the object on creation. Before it was added to the array. That meant not naming the rune in its “parent” rune as that one was destroyed. I had to add the rename code to the clone runes Start() method!

Fixing it:

I knew the only part of the Runes name I had to keep was the number as all runes were called Stone#, with the # being a number 1 to 9. So I got the number part of the rune I needed and used it in the runes new name.

Converting from char to string:

string RuneType;
RuneType =[5].ToString();

Put in own method:

void SetRuneName(){
    RuneType =[5].ToString(); = "Stone" + RuneType;
    Debug.Log(" " +;

BAM! This fixed it and all runes appeared as Stone# in the array. Bug squashed :D

Runes: Songs of the Gods - Version 0.9

Version 9 – Making new sexy runes, fixing the more-than-three selection bug (partially)

In this build I decided to destroy one of the two bugs that were really starting to get on my nerves. The fix was not perfect and thanks to my girlfriend testing the build I found out it was still broken after this build. It’s amazing how you can overlook things when you are swamped with details.

I take a look at the following in this build:
  • Remodel my rune assets with blender and reimport them (fixes the cubed runes collision bugs)
  • I work on debugging code, which slowly drives me insane

I took some deep breaths and opened up Blender again. I can never remember the shortcuts in that program so I spend more time fiddling with controls than actualy modelling. I managed to replace my cube models with a nicer looking rune model. I remade the UVmap and made sure the textures were right.

These new runes would fix the old bug where cubed runes would fall over, fly off the board or clip into each other.

I also added a new aura effect and made it look more frosty then shiny to add to the windy “up in the air” theme. After this I spent the rest of my time on this build debugging and trying to fix my rune selection code.

First fixing the array desync bug

This is how it was supposed to go. The goal was to be able to select at most 3 runes. Once the 3 runes were selected, they were locked in place as the compare code ran. The problem lied in what happens after. The way runes were being reset was after x amount of seconds for each rune individually. For example:

Rune 1 selected -> Rune 2 selected -> Rune 3 selected

Compare runs

Rune 1 deselected -> Rune 2 deselected -> Rune 3 deselected

This would be fine if the array mirrored the rune selection functionality but it didn’t at all. What happened in the array was much simpler. The array would be reset back to an empty state after a comparison was run.

The first bug that I worked out here was caused by the above design. After a comparison was run, and the array was reset the runes would start deselecting themselves one at a time. This would mean that even though two runes were still in a selected state, due to the array being empty the player would be able to select three more runes to be active. This would mean that the two runes would be added to the comparison’s selection effects even though they would not be in the array.

This made it possible for the player to select more than three runes. If the player continued on this track, due to the array being out of sync the player could eventually select all runes on the board and have them enter a selected state.

All Runes selected bug

To fix this issue I came up with the following possible solution. Either have the array mirror the runes or have the runes mirror the array. The easier option in terms of my code was to mirror the runes functionality.

I played around in my code for quite a few hours over the next few days to work out how to accomplish this. The final solution I managed was to change how the Runes reset themselves from the select state back into the unselected state.

How the select state was set:

The select / deselect state was called as part of a co-routine OnMouseDown() function. If the player clicked on a rune, the OnMouseDown() method would start the selected state. This would include freezing the rune in the place so it didn’t change, making the rune vibrate and activating the rune aura effects. It would then wait for a certain amount of seconds then deactivate again.

As each rune has their own states and own OnMouseDown co-routines, they were not working in sync. They were simply carrying out their select / deselect code after their respective timers were done. To get them to work in sync I realised I had to have them communicate with each other in some way.

How I solved the problem:

Once I realised this I started thinking about how the best way would be to go about making the runes communicate with each other. I knew I had all the pieces there, I just had to put them together. I looked to my runesaver code as that was the object I used to store all the runes that were selected.  I read through my runesaver code and came to the conclusion that the best way to get this communication done was to use the array. Since this was the one thing all three runes had in common. It was the one place they all met up accessing and sending data.

Now that I had a basic idea figured out I thought about what needed to be communicated. The runes could be selected separately whenever but had to deselect at the same time. The runes had to be deselected simultaneously – that was the communication required here. And they had to deselect as the array was reset.

I now knew that I had to use the selection functionality in the runes. I wanted them to reset their select state after three runes were selected and matched. Meaning that if the rune was clicked and there were three runes stored and the array. The array checked to see if they were a match and the runes would have to call the select / deselect functionality located in the OnMouseDown() co-routine. However the OnMouseDown() co-routine only works … well… on mouse down. This meant I had to restructure some of my rune code.

I had to check the array or listen to when the array was full. I knew then that the array was full meaning three runes were selected. The way I went about “listening” to the array was by making use of the Update() function.

The Update() function, which is a standard function in the Unity3D engine, fires off every frame. This means it is constantly (pretty much) running whatever code in inside it. I figured this was the perfect place to add a check to see if the array was full. I added the code to check if a rune was clicked and that the array[3] entry was not null. If this was the case I wanted to fire off the OnMouseDown()s code to deselect the runes. I copied out the deselect code and put it into a new function called DeactivateRunes(). I then called this function in the Update():

if(Isclicked == true && runesaver.getRuneThreeValue() != null){
transform.Translate(0,Random.Range(-2 * Time.deltaTime, 2 * Time.deltaTime),0); //wobble

This worked but not amazingly well. Actually it worked to well. It was doing exactly as instructed. Once the array was full these functions all fired off multiple times in quick succession until the array was reset. Update was firing off the functions every frame. This was ok for the other functions as I put in Boolean toggles to prevent them from running amok but DeactivateRunes() did not have these. This resulted in the ActivateAura(); being called hundreds of times and this resulted in the selected runes having their auras being activated/deactivated over and over once per frame.

This looked like a really cool electricity effect but it wasn’t by intent. I quickly added in some Boolean toggles to ensure that DeactivateRunes() was only run once per check.

void DeactivateRunes(){
Freeze = false;
    Isclicked = false; //Added 18/04/2013
    IsStored = false;
    if(quicktoggle == true){
        quicktoggle = false;
This resulted in the runes being instantly deselected once the array was full. This made my heart leap, as they were in sync! But I didn’t think about leaving enough time for the graphic effects and sound effects to play through!

I forgot that I made OnMouseDown() an IEnumerator with a wait yield. I knew I needed to have the same wait yield functionality for my DeactivateRunes() but couldn’t figure out how to combine the IEnumerator with the engines built in Update(). Simply adding one in resulted in the DeactivateRunes() never being called as the Update would redo the wait command every frame. I read up on so many different IEnumerators solutions and facts. I even converted the example CoUpdate() function example on the Unity3D site from javascript into C# and just couldn’t get it to work for me the way they said it should.  It compiled fine but I was missing something.

I’d like to say I solved this problem quickly but I stumbled about in my code for the rest of the day before frustratingly calling it quits.

The next day I shut myself off from the human world and spent a few more hours trying to solve the problem in very complicated ways. Often getting my brain stuck in a logic loop. The main problem I was running into was trying to control the flow of my code in Update() and thinking of the different parts running independently on their own timers (of which there were two; the OnMouseDown() and the DeactivateRunes()) along with the Update() which ran per frame.

 I got fed up again and went out to grab a coffee; on my walk back I solved the problem and implemented it in under 5 minutes:

void Update(){
        if(Isclicked == true && runesaver.getRuneThreeValue() != null){
            transform.Translate(0,Random.Range(-2 * Time.deltaTime, 2 * Time.deltaTime),0);

IEnumerator DeactivateRunes(){
        yield return new WaitForSeconds(4F);
        Freeze = false;
        Isclicked = false; //Added 18/04/2013
        IsStored = false;
        if(quicktoggle == true){
            quicktoggle = false;
            runesaver. RemoveFromArray ();

The solution was so simple I had to laugh at myself. Rather than call void DeactivateRunes() in Update() and trying to make Update() wait before continuing I could instead just keep Update() as it is. Instead I use it to initialise the co-routine, which uses its own timer. That way Update() can be on its merry way processing frames while my DeactivateRunes() does its thing!

This did cause another bug though, if less than three runes were selected then they would remain that way and not be deselected. Since the OnMouseDown() was responsible for also deselecting the runes, which I now removed into DeactivateRunes().
OnMouseDown() -> Selected -> waitXSeconds -> Deselect

I tried fixing this by keeping OnMouseDown() as an IEnumerator and simply calling the DeactivateRunes() after waiting x amount of seconds in OnMouseDown(). This was silly because DeactivateRunes() was an IEnumerator itself which meant I had to wait for both OnMouseDown() and DeactivateRunes() to yield.

I fixed this by adding deactivate code into the OnMouseDown(). A pretty hacky solution but one that got things working finally.

if(runesaver.getRuneThreeValue() == null){
Freeze = false;
    Isclicked = false; //Added 18/04/2013
    IsStored = false;
    if(quicktoggle == true){
        quicktoggle = false;
        //runesaver.RemoveFromArray(); //Resets Array - name is misleading

So now I had runes that worked in sync with each other. Plus they would have their individual deselect states should they need to be reset after x amount of seconds. Everything seemed fixed. I made a build and tested it. Huzzah! It worked now! The bug was fixed! Or so I thought.

Another Desync issue

Dealing with the three different timers and getting everything to work at the right place at the right time kept me so busy I forgot one important fact. The reset array functionality, stupidly named RemoveFromArray(), worked as follows:

public void RemoveFromArray(){
for(int i = 0; i < 3; i++){
        RuneSet[i] = null;
        count = 0; //**NEW on 09/04/2013
        isMatch = false; //Added on 18/04/2013
        CheckArrayToggle = false;

As you can see, it didn’t Remove any one thing from the array it reset the whole damn thing. So calling it RemoveFromArray only lead to me misunderstanding what it was doing. Lesson learnt there.

The bug here was pretty similar to the first one. Three runes would deselect themselves now as required. When one or two runes were selected they would deselect after the OnMouseDown() co-routines yield wait was done. The problem was that when one or two runes were selected they would reset one at a time and cause the same problem as before. The array would go out of sync by resetting all the runes in the array even though there may have been one still selected.

So the array resetting itself worked fine with 3 runes but not with 1 or 2 of them. To fix this I had to find a way to keep track of all three rune values and reset them one by one. If a preceding rune was reset and a player clicked on a new rune, the preceding rune slot in the array had to be filled. Not the next rune slot in the array.

To do this code wise I change the way I add values to the array. The important part here is the RemCount. Each rune gets their RemCount and uses it to store where it is in the Array.

    public void AddToArray(string x){
        if(RuneSet[0] == null){
            RuneSet[0] = x;
            RemCount = 0;
            count = 1;
            if(RuneSet[1] == null){
                RuneSet[1] = x;
                RemCount = 1;
                count = 2;
                if(RuneSet[2] == null){
                    RuneSet[2] = x;
                    RemCount = 2;
                    count = 3;

Once the rune expires (meaning if there were less than three runes active) the rune will reset and remove itself from the Array via a set method:


RuneID here is derived from RemCount. Below the method removing the value from the array:

    public void RemoveRune(int y){
        RuneSet[y] = null;

This now worked awesomely! I was super chuffed then I had my runes keeping track of themselves! Woo!

To Summarise:
  • Fixed the array desync bug, which finally gets done
  • Make new runes to fix the collision bugs and make things look better

Wednesday, 15 May 2013

Runes: Songs of the Gods - Version 0.8

Version 0.8 – Fixing the submenus

That’s really all I did on this build other than mess around with ideas on how to fix the select-more-than-three bug.

There was a setting I had to check so that the images that I used for the submenus came up as they should have. The front end was now working perfectly!

Not blurry! :D

To Summarise:
  • Fixed the front ends submenu’s
  • Adding stupid amounts on print statements to fix the more-than-three bug

Runes: Songs of the Gods - Version 0.7

Version 0.7 – Adding a front end and removing debug text

In this build my main objective was to add a front end. After that I wanted to disable debug to see how the overall game felt.

  • Add a front end with audio and sub-menu’s
    • Add a New Game option
    • Add a Credits option to credit people (for audio and font usage)
    • Add a How to Play option
    • Add music
  • Disable Debug to test out the game thus far

The front end was a new scene made up from the same wood texture as the rest of the GUI in the main game. I used Photoshop for this. After I got the textures sorted and sized I imported them and started working on the menu logic.

My Front End :)

I used the same principle I used in the basic games I made years and years ago as a kid. OnHover button effects! This made the menu seems a bit more interactive. When the player hovered over a button a description would pop up. This informed the player about the option. OnClick would select the option.  This build has a bug though, well not a bug but a setting that wasn’t checked. This resulted in the submenu’s being very blurry. I fixed this later though.

All blurry :(
 At first the submenu’s were all separate label elements but this made the whole design unruly. Instead I made the submenus in Photoshop as a solid image and imported them. After that I added a button graphic and added functionality to it. This resulted in a submenu consisting of 2 elements the submenu image and a button. This was better than a menu, a button and a label for every sentence + titles. 2 elements were easier to manage than 10-12 per submenu.

This did mean that if I had to edit the submenu’s I’d have to edit an image or remake it entirely. Fortunately saved as a .PSD file with layers the editing will be easy. And the game is so basic it probably won’t be required … probably.

I added a simple audio listener and added the chant music. Since this was only 1 audio source and it played on awake I just toggled it in the inspector. I could enable it via code by adding it in a Start() or Awake() functions in some script on the scene but this was an unnecessary complication.

After than I simply disabled the debug dropdown to see how the GUI worked and looked and how the general game felt. I changed the GUI text from yellow to white since yellow didn’t fit right. The font was still a bit unclear but it looked ok.

The aura effect on the selected runes looked nice and made the game so much more user-friendly. Unfortunately more than 3 runes could easily be selected and the array desync was still looming ominously. Other than that everything was working as expected for now, so on to the next build!

To summarise in this build:
  • Made a front end by adding a new scene and creating submenu’s imported from Photoshop
  • Added some nice front end music
  • Disabled the debug text to see how the game look and felt

Runes: Songs of the Gods - Version 0.6

Version 0.6 – Adding more Sound Effects, Score and Bonus score system and GUI functionality

In this build I wanted to get the following done and out the way:
  • Implement the Score system
  • Implement the GUI functionality (a timer and score markers)
  • Find a font to use
  • Adding various sound effects:
    • The Rumble effect once the runes are all selected and the Wobble “animation” plays
    • The tingle sound once the Score particles start up
    • Loop the wind sound seamlessly
    • Add the “Gods Sing” tracks to the game and play them once the bonus is activated

As a side-note, as I mentioned earlier the matchmaking had a bug and the array desynced from player actions. So what the player saw wasn’t actually mapped to the data structure and therefore not the game logic. This didn’t seem like a very serious bug back then but as the game became more and more polished these bugs started looking more and more ugly. Especially since my design was kind of going along as I implemented things. I knew this would lead to spaghetti-code down the road and it seem like it was drawing nearer.

Players would often match runes only to have them not match up at all or add to a score. At times they would mismatch them and a score would be added. Because the array was locked to three values but the players selection wasn’t  the player could end up selecting all of the runes. The array added the first 3 then desycned and the player had to wait for all runes to deselect and array to clear before they could start again. So essentially playing the game to fast would completely break it. Not good for a speed based game.

Anyhow more on that later. For now in this build I started adding the score system and after it was up and running I added a bonus score in line with my new design. I also added a simple timer to the game to add a sense of urgency. All the elements worked fine and I made a new GUIManager class (GUIManager script) to handle drawing the GUI values on the screen. For some reason I thought yellow text was a good idea … urgh.

I added a neat celtic themed font. I did this using the inspector and a GUI style. I tried doing this by code during runtime but it really wasn’t necessary so I left it.

The way I was managing the sound in the game was similar to the GUIManager called (amazingly enough) SoundManager! All the sounds were stored in this script locally with a bunch of get methods.

The actual audio files were all added to the games main camera with AudioSources. Once the SoundManager scrip initialised it went and got the audio sources and stored them for later use:

    void Start () {
        Asources = gameObject.GetComponents<AudioSource>();

        windLoop = Asources[0];
        IntroTalk = Asources[1];
        RockSound = Asources[2];
        ChimeSound = Asources[3];
        GodSing_One = Asources[4];
        GodSing_Two = Asources[5];
        GodSing_Three = Asources[6];

Easy to maintain and easy to manage. :D

The next part – adding the “rumble” sound effect probably took my 80% of the time to get working in this build. I edited it from a giant rock scraping audiotrack (I was allowed to edit it according to the license, the people on and the site itself are amazing and I can't thank them enough).

Once edited to a bite sized little rumble I tried to get it into the game. What in design looked like a simple thing turned into a major hassle. At first the rumble sound effect would only start playing once the runes were done with their rumble effect. At first I thought this was caused by where I was placing the Play Sound call. Which was indeed part of the problem.

Because I was using the Update() function that runs once a frame the sound was playing over and over again every frame. Which meant that it would only play once the iteration was done (meaning Update() stopped saying PLAY SOUND PLAY SOUND PLAY SOUND PLAY SOUND).

So this meant once the final rune was done rumbling, Update() let it go and the sound finally played. To fix this (and I used this method a few more times when working with that damn Update() function) I added a toggle. A simple Boolean toggle:

    void PlayActiveSound(){
        if(ToggleSound == true){
            ToggleSound = false;

This means that even though Update() keeps calling this function it won’t play more than once (depending on how you set ToggleSound). Because I’m a slow boy that took me about 3 hours to figure out so I was happy to move on to more simple problems. I added the tingle sound effect next, which was pretty easy. I just called it once the particle effect was spawned and played it once.

Next up I added the wind loop after making it seemless in Audacity. It still didn’t play seamlessly in the Unity editor or builds though. This is still a problem and I will still need to solve this to make the wind audio final. For now however the wind audio looped at least.

Finally I added the God Sings tracks and made them play. I did this at different thresholds that I simply hardcoded into the RndRune class. The bonus score was being done in RuneSaver and the Sounds were being played in RndRune. This is a no-no! I should have made a new class for Scores but I did not think scores would become so complicated.

    //Yay first time run and it works lol
    void GetGodSound(){
        switch (runesaver.getScore()){
            case 5:
            case 15:
            case 20:
                Debug.Log("No Case Reached in GetGodSound");

So to summarise:
  • I added a score system and reflected the score and bonus score in the GUI.
  • I added a custom font asset and used it in the GUI
  • I added most of the games audio effects but couldn’t get the wind sound to loop seamlessly outside of audacity

Runes: Songs of the Gods - Version 0.5

Version 0.5 – Adding sound effects and basic GUI

  • In this build I wanted to create the 2D GUI elements for the game
  • I also wanted to add the game sounds as I have never done it with Unity3D before

With this build I edited some audio (using Audacity) to compress it down a bit size wise and convert all files into mp3 format. I did this so that I could potentially release the little project on a web browser. I got the audio from some very talented people on I was like a kid in a candy store. When I used to make crappy little point-and-click -games as a kid, getting sounds for my game was always a huge effort and I often didn’t bother at all.

I edited some rough wind audio from an approximately 200 meg soundtrack of a storm using Audacity and added some placeholder sounds for the intro. This is pretty much all I did with sound in this build.

I started working on some of the GUI. Mostly the textures which I made in Photoshop. They weren’t amazing but seeing as how I can barely even hold a pencil the right way up I thought it was a pretty good attempt at being artsy. I put them into the game to see how they looked. They had no functionality at this stage however. Also the audio wasn’t playing properly yet, but at least it was playing!

It was at this stage when I decided to add to my design a bit. I was going to have it so that if a player reached a certain threshold, a bonus score would be activated. Once this occurred a message would flash up stating something like “The gods sing!” Once this was done there would be come cool track that played to make the Gods actually have some form of presence in the game. Once the gods were done singing or somehow before then the flashing message would go away and the gods voices would die down. This was until the player reached the next bonus score threshold.

Doing this would allow me to add a bit more interest/lore to my game rather than it being to boring. For example only those good at manipulating the runes can hear the gods talk. Or something like that.

To summarise this build:
  • Created basic 2D GUI textures using the same sources as the in-game textures
  • Started playing around with the audio elements in Unity
  • Started amending my game design into something larger than a napkin scribble
A basic GUI

Tuesday, 14 May 2013

Runes: Songs fo the Gods - Version 0.4

Version 0.4 – On select auras for runes

This was a small build which added an aura effect to selected runes. This worked along with the Wobble effect and the particle score effect to make the runes look more user-friendly and fun. That was pretty much it really.

The aura effect is actually a bigger child-cube with a semi-transparent mat on. I toggle it on and off in the code during runtime depending on the time elapsed and what the player clicked.

Summary for this build:
  • Clicking on a rune will highlight it with an aura effect

Aura Effect

Runes: Songs of the Gods - Version 0.3

Version 3 – Sexier particle effects and actual match-making

  • In this build I wanted to fix the particles and make them look better
  • I also wanted to have match making working fully

To fix the particles going sideways and not vertical I change the rotation of the particle systems themselves. After remaking all my rune prefabs from scratch. It was a tedious process which I hated. This is where I learnt the use of backups. There is no code for this as I chose to change the particles default rotation and I do not change the transform.rotate during runtime.

While messing around with this I added a fog effect from the Unity render settings. I remove this in a later build but it was interesting to play around with. I also add a snow particle effect to my game but the snow is very slow here and distracts from general gameplay which is a bad design choice. I fix this in later builds by speeding up the snow to match the wind SFX.

After this I add some actual match making functionality in terms of a CheckArray() function which is called by the RndRune script when appropriate. Later I realise this fancy pants way of checking the array causes a bug. Silly of me to miss it but at the time I was thinking about other parts of the system (mainly the array desycing from the players rune selections). I’ll post this builds code here:

for(int i = 0; i < 3; i++){
    Debug.Log("RuneSet[i] is: " + RuneSet[i]);
    if(tempStr == RuneSet[i]){
        isMatch = true;
        isMatch = false;
    CheckArrayToggle = false;

Pretty simple way of doing it I guess. It causes a bug when values 1 and 3 are the same but 2 is not. It will return a false positive. The first arrays value is stored in a local temp variable and the whole array is then compared to this value.

I let my girlfriend try the game out and she found it difficult to remember which rune she clicked and the game didn’t show her. I thought that would be good next step to work towards.

To summarise:
  • Particle effects default rotation changed to spray up properly – finalised design wise
  • Match making working properly (at least for this stage)

Runes: Songs of the Gods - Version 0.2

Version 0.2 – Adding particle effects and a datastructure

In this build I wanted to start putting in the core functionality. I wanted the build to cover:

  • Data structure implemented to store the selected rune states
  • Match-making implemented to run a check and see if the player scores
  • Add particle effects into the game for when the user scored a point
  • Make it so the wobble effect only plays when three runes are selected

The first part was to add a data structure. I went for the simplest one that fit – an array. I did not use a dynamic list as I knew I only ever wanted to store 3 values and work with those. Never would I want to compare more than three values.

I implemented a simple string array after thinking (but not designing) what the best type of data would be to store and work with. The main choices I was considering was assigning a numeric ID to each rune type or simple searching for their name and using that as an ID. I eventually settled on the latter as it was easier to implement.

    public string[] RuneSet;

A mistake I make here is declaring it public. There is no reason to do this and it makes code messy. I should be declaring it private or in a local scope and use get/set methods to access the data. I do this later on but some remnants still exist. What can I say – I’m real rusty! I populated the array using a simple iteration and a count variable which was reset by a separate reset function. Later I changed this as it was not complex enough to keep track of runes separately and caused many bugs.

Rather than post all my source code the pseudo-code below describes how this worked:

    If (count < 3)
        Array[count] = Rune Selected
        Debug.log “Array full – run check”
    End If

The string was received from the rune class (actually a C# script called RndRune) It accesses the RuneSaver class (RuneSaver script) using code like the line below.

    public RuneSaver runesaver;
    runesaver = GameObject.Find("Main Camera").gameObject.GetComponent<RuneSaver>();

    [onMouseDown function]
    yield wait for X time

I simply use the gameobject (so the runes) name as an ID and I use this name to compare runes in future builds.

After getting all this up and running I decided that to debug this properly I wanted to have a little debug menu so I put one in. This allowed me to check if the score incremented and to see if the correct runes were being added to the array in the correct position and if the array was being reset properly.

I made a simple DebugGUI script and use the Unity OnGUI() function seen in the Unity tutorial. This resulted in the debug seen below. Pretty swanky! :D

The next part was to add a nifty particle effect. I used the Unity3D particle system and at first tried using my own textures for the particle (to make it look like lightning). This looked very bad and I took it out. Instead I used the default Unity3D particles. I used a simple smoke one in this build.

I ran into a bug here where the particles would play properly once the array was populated by three runes but the particles were going the wrong direction. I tried solving this by rotating the Rune model asset tied to the parent game object but this broke my prefabs and caused a major head ache as the runes would spawn in with different (the default since I don’t change this in the code )rotations.

I added the code to enable the wobble and particle effect only if three runes were selected. In this build I did it by accessing RuneSaver’s count from RndRune and using an If statement in the RndRune’s Update().


    If count = 3 //Meaning there are three values in the array
        Do wobble effect
        Do sexy particles

I check to see if everything works. The match making check is calling properly and incrementing the score but does not perform any match making. It doesn’t really match runes, it just adds to score as long as the array is full. This is fine for now since I know a least it’s called at the right time (when the array is full).

To summarise, this build does:
  • Data structure implemented to store the selected rune states
  • Match-making not implemented fully and buggy
  • Particle effects in game but not called when user scores, just when array is full
  • Wobble effect only played once three runes were selected
V0.2 - Sexy Patricles going sideways!

Runes: Songs of the Gods - Version 0.1

Version 0.1 – Prototyping the design and modelling

The first stage was to create some of the assets I was going to require in my game. The most important assets were going to be the Runes and the game board. I was happy for the runes to be normal cubes since I got quite impatient with Blender at first, but I change that later on in the development process. The gameboard was also of simple design.

I did the cubes in Blender rather than Unity as I wanted to practise UV mapping some more. I made UVmaps and edited some textures in Photoshop to get the look seen below. I also added a skybox which still needs to be tweaked as of the latest build.

This version was simple really. During this version I developed the following areas of the game:

Runes and gameboard had collision added to them and runes had physics added to them to create a cool falling effect once the level starts.

  • Runes and gameboard had their textures added to them
  • I implemented a simple Spawn system for my runes to randomly spawn a type of rune.
  • I added a “wobble” effect to all my runes. I was really happy with this as it was exactly what I had in my design and didn’t have to compromise on it.
  • Once a rune was clicked, it was frozen in place and couldn’t be reselected for X seconds.

The rune spawner is pretty simple really. It doesn’t just change a runes type to a different one. I tried to do that at first but couldn’t get it to work right. What actually happens is it destroys the current rune and then randomly spawns a new one in the exactly same Transform as the previous rune. It does this using InvokeRepeating and spawns new runes every x seconds.

Code-wise I have a sample below but it’s pretty much just a simple select statement.  I call this function every 2 seconds (InvokeRepeating("GetNewRune", 2, 5F);).

void GetNewRune(){
        // Ok all this function does now is destroy and create different rune types
        // On the spot where a different rune was
        // It spawns randomly :)
        if (Freeze == false){   
            int rnd;
            rnd = Random.Range(1, 8);
            //Debug.Log("Random Gnenerated number is: " + rnd);
            switch (rnd){
                case 1:
                    RuneType = 1;
                    Instantiate(Rune1, transform.position, transform.rotation);
                case 8:
                    RuneType = 8;
                    Instantiate(Rune8, transform.position, transform.rotation);
                    Debug.Log("No Case Reached");

The first signs that I didn’t know what I was doing is apparent in my InvokeRepeating call. I specify every 5 seconds but this is irrelevant as only the 2 seconds will be called every time. Meh it works and screwing with it will only cause other things to break so I’m accepting that as a quirk … for now.

My wobble effect is pretty awesome I think and I took it pretty much straight from the Unity tutorials. Just tweeked it a bit:

transform.Translate(0,Random.Range(-2 * Time.deltaTime, 2 * Time.deltaTime),0);

I run the above in the scripts Update() function every time a rune is marked as clicked. It runs for as long as the rune is frozen. It is worth mentioning that the wobble effect did cause my first bug. The runes would sometimes clip into the gameboard and fly off into the air only to land again. Other times they would fall over. I fix this later in the development.

So to summarise I managed to get the following elements working in the first version:
  • Assets textured and loaded into the scene
  • Collision and physics sorted out
  • Code to allow for player interaction/selection
  • Runes randomly spawning implemented
  • Wobble effect and rune freeze implemented
V0.1 - They wobble when clicked ... not much else

Runes: Songs of the Gods - The Start

What started as a quick practise session turned into much more. I put my main game which I named DroneBoats (a working title) on hiatus while I practised some of the stepping stones I was having trouble with. I jotted a quick design on a scrap piece of paper whilst at work. I wanted to get this little project out of the door in less than 1 month.

The original purpose of this project was to learn more about modelling, UV mapping and texturing. I somewhat managed to succeed in that, having no previous knowledge about these areas I managed to put together at least “ok” looking assets/textures/audio to use in the game. What I found interesting was how much I learnt code wise also.

In the next few posts I hope to cover (in varying degrees of detail I guess) what I went through to get things up and running. The little project has been in development for about 3 months now. I have a fulltime job and do this in what spare time I have. Below I have a screenshot of what it currently looks like (v1.0).

Click to enlarge - Giggidy!

The first steps as I mentioned was doing a quick design. Unfortunately I had only a vague idea in my mind. As I was distracted by the other game I was working on I didn’t take this design to seriously. Something that comes back to bite me in the testing part of the life cycle. I knew I wanted the following things:

  • Basic “match-three” game.
  • Decided on a druidic, runic theme
  • I wanted the game to be 3D and when clicking on runes I wanted some neat, lively effects

With the last point I wanted sound effects and awesome lighting effects. Once I started making these things however I realised to how much time the lightning I wanted was going to take and changed the design. More on that later!

The tools I was going to use were:

  • Unity3D
  • Photoshop
  • Blender
  • Audacity

As a side note, even though I have development experience in basic C++, quite a bit of Java, Python etc. and I am familiar with OO programming I have never written any C# apart from a Hello World console program years ago. I have also not done any real development work since University 2-3 years ago. So yea … I’m a bit rusty.

I really enjoyed the learning opportunity to use C# in an interesting and engaging way. I have never picked up a programming language this quickly before and it’s largely thanks to the fact that I am genuinely interested and proud of my little project.

Welcome to the Clusterbug Games Dev Blog!

Good afternoon all and welcome to my Dev Blog.

I tried to keep this up to date as often as possible but I would waste so much development time typing up little posts.

Instead what I have been doing in making little notes as I develop my games. In the following few posts I'll be explaining how I am going about making my very first game using Unity3D!

It is a simple "match-three" game. A lot of people I've spoken to said start small. I would also like some of my future games to run on mobile phones and social sites like Facebook. So I guess practising casual games would be good for me on that point.

My current game project is called Runes - Songs of the Gods. It's currently at version 1.0 from 0.1 so ten builds in. I am at the debugging stage and after the final bug (which im working on now) I'll be entering the polish stage. I can't wait really as I have other exciting ideas I want to get on with!

I cover some of the source code but only when I find it required to explain things. I'm hoping to get better and less technical at this. To make things more entertaining and informative at a glance. Maybe that's why I take so long to write posts!

Anyhow, I have to get back to debugging this stuff. So while I code the night away, chillax and have a beer and see what shenanigans I get up to!

Hope you enjoy the read! :D