Apparently the best way to control background music (BGM) and sound effects (SFX) was to create global booleans to be checked to play sounds. I reverted the original change from using the AudioListener.PlayClipAtPoint() static function and calling an if everytime to changing the original playR() function into a new playBGM() and playSFX() function, along with a new RandomSound_Mech, to check with the global boolean.

A6yog want to play background music randomly from an array of AudioClips, and that is fine (and better, since it will get boring without the shuffling), so I needed something to keep the state of the BGM, along with the ability to wait for the music to complete playing before switching to another track. That is easily solved with a coroutine and a play boolean to check if it is playing. (might change to audio.isplaying later)

As for the SFX, I used the original formula and...

I guess not much using Unity ever used Ruby or Python in their other work. Most of the people I see use C or UnityScript, which I guess stems from their background of C++ or JavaScript. It’s too bad though, this causes a lot of strange descriptions of Boo you see around the forums.

As a language, C is developed nicely, but it lacks the strength Boo actually has over it, such as meta programming abilities and basically cleaner and clearer literals. Seriously, the hardest gripe I have over C are two things: the stupidity (or strictness) of the compiler and the generics provided. Even in D, the language to supersede C++ has a compiler that understands that when you pass an integer array into a foreach loop, then the elements are going to be integers, but not C. Sigh. Seriously?

Development can be faster if the computer does what it is supposed to do, i.e. calculations, instead of the...

I guess what I’m doing now is basically planning for a project, i.e. making sure that everyone doesn’t mess each other codes. Of source, source control can do some measure of that, but source control haven’t been able to control areas of codes without human guidance.

Currently the game is separated to six main parts:

1. Player GUI and input
2. Level design
3. Models and Graphics
4. Game mechanisms
5. Sounds
6. Networks

As you can see, a huge part of the game in on the focus on the player interface, whether it looks pretty, sounds pleasant, the animations are good enough or not. The code underneath don’t matter until it clashes with the above requirements. Players come playing with some expectations of their own, so we’ll have to maintain some of that, while breaking what they expect, in a nice way.

I will repeat, The code underneath don’t matter until it clashes with the above requirements.

If...

I guess the rewrite has paid off a little, when I added a new attack, I only had to add a new weapon as the claw by duplicating the original chest gun, change the name, the texture for this attack and a new script for the behavior.

A departure from original attacks, which were simply ranged attacks with bullets, this time I made a attack based on the claw. What I had in mind was the zoid running forward to the enemy and slashing. With the state architecture up, I could write the state changes and their conditions and prerecord it in a script, since the zoid moves according to the state, not directly according to the player input so I can hack into the motion handle.

Since the swinging motion of the claw essentially means that the damage is dealt when something with health stats is found along that arc. However, without the benefit of pin point physics and animations, I had to think of...

Desperate times call for desperate measures, I guess. For the camera to follow the player around, I had modified the SmoothFollow JavaScript code to fit my needs, which also exposed me to the wonderful that is the Lerp function. However, a game just can’t have one camera view, that would just be boring, since visuals and audio make up a huge part of the gaming experience.

Yesterday I had a conversation with a6yog to discuss the preview build. Apparently what a6yog meant by “bird’s eye view” was something much different than what I thought (and much cooler). He explained that, like in the bottom left corner of this picture, the camera would be able to rotate 360 degrees, so players travelling distances can enjoy the view while they move. Cool.

The idea is simple enough. Have the camera look outwards while rotating around using alt, and above the zoid. The camera starts at the back.

...

It’s time for cleaning out messy hacks! When I write code sometimes I just had to get the job done first, then clean up, resulting in all the WTFs you can see in this place, prompting the rewrite of the entire code base. Of course, the current rewrite is not perfect and there are still horribly mangled code hiding among the current code, such as the timer, and non-commented code, and a misplaced equals sign in Bullet Handle, which caused the weapon pointer not to cycle correctly, so some cleaning is still needed.
I’ve also uploaded all the models so any graphic developer can upload their models into the repository.
Unfortunately though, I have not completed the rewrite of the GUI components so the current build will only have a rudimentary movements, shooting ability and bird eye’s view.
With a departure from previous concepts, we have new code:

Zoid (with it’s components that should

Time is an important concept in games, controlling and constraining player actions so we could have a better game structure.

From time to time, I had implemented a timer like this:

    class timer:
        public start=false
        public time=Time.time

        def Start ():
            record = timer()

        def Update ():
            if state["shoot"]==true:
                if record.start == false: 
                BL=GameObject.Instatiate(bullet, self.transform.position, self.transform.rotation) as GameObject
                record.time=Time.time
                record.start=true
            else:
                if (Time.time-record.time)>cooltime :
                    record.start=false
                    record.time=Time.time
                    state["shoot"]=false

This timer was the original implementation of a custom cooldown clock, but this code is messy and violates...

Audio cues can play a huge part in games, ranging from minor sounds like a gun click to large and dramatic sounds like the usage of an ultimate ability. Unity3D helps in this by providing a 3D sound engine which we could use to our advantage.

The question I pondered while adding sounds to guns was that which agent should handle the sounds? I want the gun shot sound to be heard when the bullet was shot and an explosion sound to be heard when the bullet hit its target.

The first problem was solved easily by setting the “Play On Awake” flag on for the gun shot audio source.

The second problem though, left me stumped for a while when the explosion sound just refused to play when the bullet was destroyed…

Then I realized again that the bullet was destroyed and the sound would not play after that. After thinking a while, it seemed that I had two ways of solving it. Either I disable...

Unlike Ruby, Python and Boo don’t have “blocks”, instead what we have are functions, which is basically named blocks, actually. Function save coding time because instead of copy and pasting your code everywhere, you just do multiple calls to the same block. Pure functions don’t give side effects (e.g. printing, changing global variables inside blocks) but since Unity scripting is a OO-based system, we are going to deal more with methods that change internal states of each class.

Remember my last post where I had to deal with jumping? The code was an ugly hack just to get the thing working, and I could have done better by wrapping the overlapping code in a function, and so I did exactly just that.

Instead of :

def OnCollisionEnter(collision as Collision) as void:

    for contact as ContactPoint in collision.contacts:

        if contact.thisCollider.CompareTag("Leg") or

Somehow this became the best solution to jumping, along with other pleasant surprises. While I was solving the problem of jumping, I couldn’t get a working solution of getting the zoid to jump only when it is on the ground, which resulted in my previous solution ( the code is so hideous that I deleted it about six months ago :P) of recording the height when the zoid leaves the ground.

Of course, that was so wrong that I wrote more and more hacks to cover it up, until it all blew and the zoid still won’t jump up a cliff normally. So I went and think what happens when the zoid jumps.

1. The zoid checks if it’s on the ground.
2. The zoid applies force from it’s legs upwards.
3. The zoid comes back down on the ground.

So that’s when I thought, we need to know if the zoid is on the ground! First I tried using the mesh collider generator to create a collider for the whole body, then wrote a...