Unity3D - Discussion

[foszor]

[QUOTE=BackwardSpy;45641670]OBS is fine, YouTube is just having some problems processing videos at the moment, tons of people I'm subscribed to have had issues with it as well. Wait it out for a bit and it'll probably start working again soon![/QUOTE]

I am both happy and sad to hear this. Happy because I've probably been doing everything correctly, but sad because of all the time I wasted trying to figure out what I was doing wrong.

[KillaMaaki]

Are you trying to record the editor or standalone build? I don't think it will work for editor build, but should work for standalone build just fine.

[foszor]

So this is the first video I've posted about project I'm working on. It's playable but not complete... and it's littered with WIP/placeholder art, but I'm ready to start sharing progress and getting feedback.

Quick Info:
- the main menu is a tabletop game board
- the cards chosen are the heroes brought into battle
- the huge key is required to unlock dungeons and unlock the final boss' treasure chest (not implemented yet)
- dungeons are made of multiple levels, each with waves of enemies
- heroes must protect the key from being stolen and survive all the waves to advance

This video is testing selecting cards (the 3 top positions are the selected cards, the bottom are inventory), unlocking a dungeon (appropriately named "Dev Tests") and running through all three levels in the test dungeon to ensure progress is properly saving in the player profile

[video=youtube;hq6NsXBbPEo]http://www.youtube.com/watch?v=hq6NsXBbPEo[/video]

[Arxae]

The console is something you made yourself?

[foszor]

[QUOTE=Arxae;45643773]The console is something you made yourself?[/QUOTE]

Yes. It's nothing fancy but it sure comes in handy.

[Arxae]

[QUOTE=foszor;45643922]Yes. It's nothing fancy but it sure comes in handy.[/QUOTE]

I bet. Github the source? :v:

[KillaMaaki]

Well, I've just now accomplished a seemingly very easy task: move a sprite back and forth across the screen.
But I've done it in just about the most complicated way ever invented :D

Actually, what I've been doing today is writing a custom-built retro-console-style virtual machine in Unity. It's got 256 registers, 128kb of RAM, 32 hardware sprites, 57 colors (actually it's got the NES pallette), and an unlimited subroutine stack because I was lazy.

[video=youtube;GMUncx1bUM8]http://www.youtube.com/watch?v=GMUncx1bUM8[/video]

The bytecode is entirely custom made and somewhat simplified (some commands map directly to loading or unloading sprites, or setting sprite positions, and there's even a command for waiting for a screen refresh called VBLANK)

To help write the above demo, I came up with a class which acts as a "compiler". You override the Main method and use the helper methods provided to emit "opcodes". The end result is a byte array which is passed to the virtual machine for execution.

The program above looks like this in C#:

// load player sprite
LoadSprite( 0, 65 );

// initialize player position
SetReg( 0, 16 );
SetReg( 1, 24 );

// save player position to RAM
Call( "SavePlayerPos" );

// initialize velocity
SetReg( 2, 0 );
SetReg( 3, 1 );

WhileTrueLoop( () =>
{
	Call( "MainLoop" );
} );

Subroutine( "LoadPlayerPos", () =>
{
	// load player position from RAM
	RegLoad( 0, 0 );
	RegLoad( 1, 1 );
} );

Subroutine( "SavePlayerPos", () =>
{
	// save player position to RAM
	RegSave( 0, 0 );
	RegSave( 1, 1 );
} );

Subroutine( "MovePlayer", () =>
{
	// check whether we should be going left or right

	// if register[2] equals 0
	LoadTemp( 0 );
	RegEqual( 2, TEMP_REGISTER, () =>
	{
		AddReg( 0, 3 ); // add register[3] to X
	}, () =>
	// else
	{
		SubReg( 0, 3 ); // subtract register[3] from X
	} );
} );

Subroutine( "BouncePlayer", () =>
{
	// if we hit the edge of the screen, flip our direction of movement

	// if X is greater than 160
	LoadTemp( 160 );
	RegGreater( 0, TEMP_REGISTER, () =>
	{
		SetReg( 2, 1 ); // set register[2] to 1
	}, () =>
	// else
	{
		// if X is less than 8
		LoadTemp( 8 );
		RegLess( 0, TEMP_REGISTER, () =>
		{
			SetReg( 2, 0 ); // set register[2] to 0
		} );
	} );
} );

Subroutine( "UpdatePlayerSprite", () =>
{
	// set player sprite pos
	SetSpritePos( 0, 0 );
} );

Subroutine( "MainLoop", () =>
{
	Call( "LoadPlayerPos" );
	Call( "UpdatePlayerSprite" );
	Call( "MovePlayer" );
	Call( "BouncePlayer" );
	Call( "SavePlayerPos" );

	// wait for VBLANK
	Vblank();
} );

And what that code generates, translates roughly to this (fake) assembler code (many of the labels are automatically named):

LDSPRITE 0 65
SET 0 16
SET 1 24
CALL SavePlayerPos
SET 2 0
SET 3 1

;LoadPlayerPos
RLOAD 0 0
RLOAD 1 1
RETURN

;SavePlayerPos
RSAVE 0 0
RSAVE 1 1
RETURN

;MovePlayer
SET 255 0
EQUAL 2 255 LBL0.FALSE
ADD 0 3
GOTO LBL0
;LBL0.FALSE
SUB 0 3
;LBL0
RETURN

;BouncePlayer
SET 255 160
GREATER 0 255 LBL1.FALSE
SET 2 1
GOTO LBL1
;LBL1.FALSE
SET 255 8
LESS 0 255 LBL2
SET 2 0
;LBL2
;LBL1
RETURN

;UpdatePlayerSprite
SETPOS 0 0
RETURN

;MainLoop
CALL LoadPlayerPos
CALL UpdatePlayerSprite
CALL MovePlayer
CALL BouncePlayer
CALL SavePlayerPos
VBLANK
RETURN

;LBL3
CALL MainLoop
GOTO LBL3

I say "fake" because ATM there is no such thing as assembler code for this - it's currently just translated directly to byte code, but this was the closest analogy I could find without just dumping the raw hexcode onto the forums. Well, and those labels (the lines preceded with colons) don't actually exist in the final byte code at all - they're resolved to uint values at compile time which point directly at which byte to jump to.

So yeah, what I've just done is made a sprite move back and forth on a screen. Yes, very productive day ;)

EDIT: By the way, while far from complete (I've been adding instructions as I go, basically winging it), here's the instruction set so far.

00 GOTO
01 CALL
02 RETURN
03 SET
04 ADD
05 SUB
06 AND
07 OR
08 XOR
09 NEG
0a SHL
0b SHR
0c EQUAL
0d GREATER
0e LESS
0f RSAVE
10 RLOAD
11 RCOPY
12 CLRSPRITE
13 LDSPRITE
14 SETPOS
15 GETPOS
16 VBLANK

[reevezy67]

-snip-

[AnonTakesOver]

Any recommended C# Unity books? I'm fine with anything beginner-intermediate.
Also, any recommended C# books? I know C#, but only basic shit, I don't know any of the libraries and shit, also very faint on OOP, I understand the concepts and what not, I can never apply it practically though. Also would be nice if someone could tell me a good C# book that includes server to client.
Cheers!

[date4o]

[QUOTE=AnonTakesOver;45647474]Any recommended C# Unity books? I'm fine with anything beginner-intermediate.
Also, any recommended C# books? I know C#, but only basic shit, I don't know any of the libraries and shit, also very faint on OOP, I understand the concepts and what not, I can never apply it practically though. Also would be nice if someone could tell me a good C# book that includes server to client.
Cheers![/QUOTE]

As i think the best way to learn something is a practice. Of course you shouldn't start writing of serious project without knowledge of C#, but the best way to become better in Unity3D and C# - just a practice. Start doing something and then when you'll solve a troubles it gives you much more experience than reading of books without practice.
I think that you should start read books when you don't know nothing about programming, OR when you after few month/years of developing will understand that you STILL don't know nothing about a programming.
In the first case you should read books for beginners, in the second case you should read advanced books about architecture of programs and etc.
PS: I can be wrong, but as i think it's a better way to grow up very fast.

[AnonTakesOver]

[QUOTE=date4o;45647538]As i think the best way to learn something is a practice. Of course you shouldn't start writing of serious project without knowledge of C#, but the best way to become better in Unity3D and C# - just a practice. Start doing something and then when you'll solve a troubles it gives you much more experience than reading of books without practice.
I think that you should start read books when you don't know nothing about programming, OR when you after few month/years of developing will understand that you STILL don't know nothing about a programming.
In the first case you should read books for beginners, in the second case you should read advanced books about architecture of programs and etc.
PS: I can be wrong, but as i think it's a better way to grow up very fast.[/QUOTE]

Practice is how I learn, but I've been having issues recently and thought you know what would be good, a complete read through of a book, that'll get the ideas flowing when I learn something new and cool etc.

Just wanna hear any recommended books before winging it.

[reevezy67]

You should probably learn C# before Unity, unless you have experience in another C-like language.

There's so much shit copy paste script-like code in Unity from people that don't know anything else. But hell if it works for you what do I care.

The C# Pocket Reference is good as a quick start guide if you already know the basics of programming.

[Pelf]

[QUOTE=KillaMaaki;45644447]Well, I've just now accomplished a seemingly very easy task: move a sprite back and forth across the screen.
But I've done it in just about the most complicated way ever invented :D

Actually, what I've been doing today is writing a custom-built retro-console-style virtual machine in Unity. It's got 256 registers, 128kb of RAM, 32 hardware sprites, 57 colors (actually it's got the NES pallette), and an unlimited subroutine stack because I was lazy.

-

The bytecode is entirely custom made and somewhat simplified (some commands map directly to loading or unloading sprites, or setting sprite positions, and there's even a command for waiting for a screen refresh called VBLANK)

To help write the above demo, I came up with a class which acts as a "compiler". You override the Main method and use the helper methods provided to emit "opcodes". The end result is a byte array which is passed to the virtual machine for execution.

The program above looks like this in C#:

-

And what that code generates, translates roughly to this (fake) assembler code (many of the labels are automatically named):

-

I say "fake" because ATM there is no such thing as assembler code for this - it's currently just translated directly to byte code, but this was the closest analogy I could find without just dumping the raw hexcode onto the forums. Well, and those labels (the lines preceded with colons) don't actually exist in the final byte code at all - they're resolved to uint values at compile time which point directly at which byte to jump to.

So yeah, what I've just done is made a sprite move back and forth on a screen. Yes, very productive day ;)

EDIT: By the way, while far from complete (I've been adding instructions as I go, basically winging it), here's the instruction set so far.

-[/QUOTE]

This is so cool. I've been trying to do something kinda similar where there's a command console in the world and you can input commands to have things in the world do stuff (like open a door). And the player could code scripts and run those. It would work similar to Matlab. I can't figure out how to tokenize the input strings though. :v:

[KillaMaaki]

Tokenizers aren't that hard to write.

Think of them like a state machine, where whatever token it's currently building is the current state (it generally has some type enum associated with it, like "is this whitespace, is it a word, is it.... etc")

So for instance, let's say you're passing over some text and you encounter a " character. That transitions to the String token state. It will then iterate over each new character until it finds another " character, which ends the String token state. Now you've got a String token, which is everything that was sandwiched between the "" characters.

Similar for all the other tokens you need. You probably don't need much beyond text token, whitespace, and string token.

[Pelf]

[QUOTE=KillaMaaki;45648352]Tokenizers aren't that hard to write.

Think of them like a state machine, where whatever token it's currently building is the current state (it generally has some type enum associated with it, like "is this whitespace, is it a word, is it.... etc")

So for instance, let's say you're passing over some text and you encounter a " character. That transitions to the String token state. It will then iterate over each new character until it finds another " character, which ends the String token state. Now you've got a String token, which is everything that was sandwiched between the "" characters.

Similar for all the other tokens you need. You probably don't need much beyond text token, whitespace, and string token.[/QUOTE]

Should I be specific with tokens like String, Variable, FunctionCall, Expression, Parameters, etc? Or just leave it simple like what you suggested text token, whitespace, and string token?

[reevezy67]

I hang out on the Unity IRC and help people every now and again, 9 times out of 10(unless it's a regular) the person turns out to have no programming skills and wants me to write it for them. Then I tell them I'll do it for $60/hr and they run away.

This happens at least 3 times a day, I might just stop helping people.

[KillaMaaki]

Well, no. The job of the tokenizer isn't to parse what the text actually means, it's just to split it up into individual tokens. It would then pass that off to the parser, which is what makes sense of those tokens.

For console commands that's all you need. Your "parser" would probably just look at the first token and say "right, that's the command, all these other tokens are parameters".

For general scripting... well, that's a complicated subject that you may not want to dive into. There's third party scripting engines out there for that (such as Javascript interpreters).

[editline]10th August 2014[/editline]

So I've made a couple of changes to my virtual machine.

Now, when you do a CALL, it pushes the state of all registers onto the call stack.
When you do a RETURN, it pops the state of all registers from the call stack.

This simple change has had some serious implications for how code is designed. For instance, changes you make to registers in a subroutine will be erased when the subroutine calls RETURN. Therefore, if the subroutine wants to store any values for other code to access, it must save those out to RAM before it calls RETURN, and the other code must load those values back from RAM. Just to make life harder, I guess ;)

I also added input. Now you can fetch the state of a button (buttons are the same as a NES controller) and store it in a register via the INP command.

I also changed how resources are handled. Previously, I separated them out into a separate byte array from the main program since it was otherwise difficult to pass along the start location of the sprite (every tweak I made to the program would basically mean I had to go back and manually find the start location of the sprite - ick!). Now I'm using labels for those - you just prepend your sprite with a label, and pass that label to the load sprite command. It will then resolve that at compile time to the uint value that LDSPRITE expects.

Here's the ASM that my program is now, and moves the player with the arrow keys (which are currently bound to the buttons UP, DOWN, LEFT, and RIGHT as you might expect):

LDSPRITE 0 TestDudeSprite
SET 0 16
SET 1 24
RSAVE 0 0
RSAVE 1 1
SET 2 1

;LBL0
CALL MainLoop
GOTO LBL0

;MovePlayer
RLOAD 0 0
RLOAD 1 1
INP 0 5
INP 1 6
INP 2 7
INP 3 8
SET 255 0
GREATER 5 255 LBL1
SUB 1 2
;LBL1
GREATER 6 255 LBL2
ADD 1 2
;LBL2
GREATER 7 255 LBL3
SUB 0 2
;LBL3
GREATER 8 255 LBL4
ADD 0 2
;LBL4
RSAVE 0 0
RSAVE 1 1
RETURN

;UpdatePlayerSprite
RLOAD 0 0
RLOAD 1 1
SETPOS 0 0
RETURN

;MainLoop
CALL UpdatePlayerSprite
CALL MovePlayer
VBLANK
RETURN

Still quite potentially the most useless use case for Unity to date, but hey it's the weekend and this is what I do for fun.

Might actually release the VM project in this state. There's no sound, the instruction set is severely limited, it's not terribly realistic, the code is a mess, and the performance is horrid (due to drawing the screen with Texture2D.SetPixels/Apply), but maybe someone will come along and write a fun program with it or something. Maybe Pong.

[Tamschi]

[QUOTE=reevezy67;45648694]I hang out on the Unity IRC and help people every now and again, 9 times out of 10(unless it's a regular) the person turns out to have no programming skills and wants me to write it for them. Then I tell them I'll do it for $60/hr and they run away.

This happens at least 3 times a day, I might just stop helping people.[/QUOTE]

Before you do that please try being more up front about not doing their work.

It should be possible to politely make it clear you will only give advice and no/not much code.

[Layla]

It's not a huge problem but I don't like how pitch and other parameters can't be changed when using PlayOneShot. To get around it I make a temp object with an audio source that is alive throughout the duration of the audio clip. Is this a common work around with Unity audio? I hope the new audio system fixes annoying issues like that.

[KillaMaaki]

[QUOTE=layla;45650036]It's not a huge problem but I don't like how pitch and other parameters can't be changed when using PlayOneShot. To get around it I make a temp object with an audio source that is alive throughout the duration of the audio clip. Is this a common work around with Unity audio? I hope the new audio system fixes annoying issues like that.[/QUOTE]

That's basically what I'm doing, except hidden behind an AudioManager API and the game objects are pooled to avoid Instantiate/Destroy overhead.

[foszor]

[QUOTE=KillaMaaki;45650051]That's basically what I'm doing, except hidden behind an AudioManager API and the game objects are pooled to avoid Instantiate/Destroy overhead.[/QUOTE]

Exactly how I've done it.

	private static AudioSource[] soundPool;
	private static int soundPoolIndex;
	private void CreateSoundPool()
	{
		GameObject soundParent = new GameObject();
		soundParent.name = "Sound Pool";
		soundParent.transform.parent = transform;

		soundPool = new AudioSource[ Settings.Audio.PoolSize ];
		for ( int i = 0; i < Settings.Audio.PoolSize; i++ )
		{
			GameObject sound = new GameObject();
			sound.name = "Sound";
			sound.transform.parent = soundParent.transform;
			soundPool[ i ] = sound.AddComponent<AudioSource>();
			soundPool[ i ].playOnAwake = false;
			soundPool[ i ].loop = false;
		}

		soundPoolIndex = 0;
	}

	public static void PlaySound( AudioClip sound )
	{
		PlaySound( sound, 1f, 1f );
	}

	public static void PlaySound( AudioClip sound, float volume )
	{
		PlaySound( sound, volume, 1f );
	}

	public static void PlaySound( AudioClip sound, float volume, float pitch )
	{
		if ( Settings.Audio.GameVolume == 0 )
			return;

		soundPool[ soundPoolIndex ].volume = volume;
		soundPool[ soundPoolIndex ].pitch = pitch;
		soundPool[ soundPoolIndex ].PlayOneShot( sound, Settings.Audio.GameVolume / 10f );
		if ( ++soundPoolIndex >= Settings.Audio.PoolSize )
			soundPoolIndex = 0;
	}

[Layla]

Oh nice you can set the pitch before calling PlayOneShot, wasn't aware. That makes things easier.

The only problem would be is if a long sound is playing and the pool index wraps around before the one shot has finished playing, if it uses different volume and pitch values then the original one shot would change too. Just have to live with that I guess and make sure the pool is large enough for that not to happen.

[Pelf]

I also do it the same way except mine seems to be riddled with bugs. :v:

[editline]edit[/editline]

Actually, now that I think about it, the problems may have been caused by a bug with my object pool that I recently fixed.

[Tamschi]

[QUOTE=layla;45650458]Oh nice you can set the pitch before calling PlayOneShot, wasn't aware. That makes things easier.

The only problem would be is if a long sound is playing and the pool index wraps around before the one shot has finished playing, if it uses different volume and pitch values then the original one shot would change too. Just have to live with that I guess and make sure the pool is large enough for that not to happen.[/QUOTE]

If you get events when the sounds stop maybe it would be better to queue up the inactive cached instances only.

You won't need as many instances and when you run out you can just create a new one.

[foszor]

[QUOTE=layla;45650458]The only problem would be is if a long sound is playing and the pool index wraps around before the one shot has finished playing, if it uses different volume and pitch values then the original one shot would change too. Just have to live with that I guess and make sure the pool is large enough for that not to happen.[/QUOTE]

Yea I didn't compensate for that because my sounds are all really short. You could add in a 'sound.isPlaying' check, that might help.

[KillaMaaki]

Onwards with my useless Unity virtual machine! It's the end of the weekend, so I'll be getting back to my main work on Orbital Assault for the rest of the week.

Anyway, I've made a lot of changes to it.

- The first 16 registers are 32-bit, not 8-bit This allows them to store memory addresses which are 32-bit unsigned integer values
- Accordingly, there's some new instructions specifically for manipulating 32-bit registers. They are SET32, RSAVE32, and RLOAD32, for lack of better names for them.
- RSAVE, RLOAD, RSAVE32, and RLOAD32 no longer take a raw memory address. Instead, they take a register ID, which holds the target memory address (presumably, one of the 32-bit registers)
- The program counter is now stored in the very first register. That means you effectively get 15 32-bit registers to work with for general purpose (although you *can* manipulate the program counter now)
- Now there's a limit on the call stack of 16 levels, just to make things harder.
- Memory is now unified. There's currently three distinct blocks of memory: VRAM, standard RAM, and Cartridge. VRAM is where the data for each hardware sprite is stored. Standard RAM is intended for general purpose access. Cartridge is where your program is stored, and can contain up to 4mb of data. These each have their own range of memory addresses, and can all be read from via RLOAD/RLOAD32, and VRAM and RAM can be saved to via RSAVE/RSAVE32 (you can pass a Cartridge address, but it will simply ignore it as the Cartridge is assumed to be read-only).
- Now that there's VRAM which can be read from and written to, there's no longer LDSPRITE, CLRSPRITE, SETPOS, or GETPOS commands. The helper methods for them still exist, they just write out a different set of instructions which accomplish the same task.

At this point, the instruction set is now much more generic except for VBLANK and INP. I might move VBLANK to a register and get rid of the dedicated instruction. I'll have to think about INP. Maybe memory addresses?

Anyway, after all of those changes, here's my "game" demo code as it stands:

SET32 15 157
SET32 14 0
RSAVE32 15 14
SET 16 16
SET 17 24
SET32 14 192
SET32 15 193
RSAVE 16 14
RSAVE 17 15
SET 18 1

;LBL0
CALL MainLoop
GOTO LBL0

;MovePlayer
RLOAD 16 14
RLOAD 17 15
INP 0 19
INP 1 20
INP 2 21
INP 3 22
SET 255 0
GREATER 19 255 LBL1
SUB 17 18
;LBL1
GREATER 20 255 LBL2
ADD 17 18
;LBL2
GREATER 21 255 LBL3
SUB 16 18
;LBL3
GREATER 22 255 LBL4
ADD 16 18
;LBL4
RSAVE 16 14
RSAVE 17 15
RETURN

;UpdatePlayerSprite
RLOAD 16 14
RLOAD 17 15
SET32 15 4
RSAVE 16 15
SET32 15 5
RSAVE 17 15
RETURN

;MainLoop
CALL UpdatePlayerSprite
CALL MovePlayer
VBLANK
RETURN

And here's a video of the above code running in the VM.
[video=youtube;SHJq0t1aIi0]http://www.youtube.com/watch?v=SHJq0t1aIi0[/video]

[Layla]

I made the hud because I wanted to get it out of the way. It's inefficient because of how the GUI system works, I'm glad they're replacing it with something better.

[img]https://dl.dropboxusercontent.com/u/99765/fw_progress_25.png[/img]

[MogeyQ]

Anyone been using 4.3's 2d implementation? How does it compare to something like 2d toolkit?

[Arxae]

Can't get collision to work in 2D.

I have a simple setup:
[img]http://i.imgur.com/3AuQ3Pi.png[/img]

The white bar should behave like a bar. It's on the Environment sorting layer
The character is on the Character sorting layer.

None of the collision work, register or fire. Same goes when i set it as trigger.
Both have a box collider.
Problem persists when i put them both on the same sorting layer.

Anyone has an idea?

[AwesomeX]

Do both of them have a [B]2D[/B] Box Collider?
And if so, how are you moving your character? If you are simply translating him across the scene, he wont collide with things very well.