next »

[Sebioff]

static function Range(min: int, max: int): int;

Description
Returns a random integer number between min [inclusive] and max [exclusive] (Read Only).

So Random.Range(0,1); always gives you 0.
That's actually somewhat strange, because for the float-version of this method max is inclusive...

Edit: For the visibility, it is usually good practice to give stuff the minimum needed visibility, although this is somewhat more important for code you share with others (e.g. APIs). Some say members should always be private and only be accessed by getters/setters, this is probably the cleanest way, but I personally think in games it can get a bit cumbersome. Definitely try to keep things private/protected by default though and only make it public if needed.

[JLJac]

Hehe sorry, clumsy of me! Now it works just fine
When looking at the code, does the solution look conventional or like the alien makings of a self-taught weirdo? I worry about this a bit, because I don't want to drift into weird territory if I'm to bring another programmer on later on...

[gimymblert]

The first problem isn't c# it's float!



Basically it's better to use int by multiplaying the base data by some order of magnitude then divide it back to get the result and use mod to get what's after the point and convert it back to a float ... That's what I do
It's basically the same as the float point format, but it allow me to add hacky step inside

[Sebioff]

Code looks good I think Can't come up with a more elegant solution currently. Just add a short comment above the block about generating a saturated color or some descriptive method name and your other programmer should be happy

[jgrams]

Code:

float frc = (150f - Vector2.Distance(obj1pos, obj2pos))/150f;
frc = Mathf.Clamp(frc, 0f, 1f);

For some reason this returned small values slightly above zero, never a clean zero. <snip> I even tried removing the Clamp and doing an old school if statement, with the same weird output.

That's very odd. There are problems with floats and fractions (basically floats can only exactly represent fractions whose denominator is a power of two, which leads to rounding errors that you don't expect), but clamping to 0 and 1 should absolutely not be a problem. Even if it was a problem, I'd expect that the clamped minimum would be the same every time.

So you tried

Code:

if(frc < 0f) frc = 0f; else if(frc > 1f) frc = 1f;

and got the same results? Are you sure nothing is interfering with the value between when you set it and when you look at it?

Other problem: I wanted to generate a color at random, but I only wanted fully saturated colors and never white or black.

When looking at the code, does the solution look conventional or like the alien makings of a self-taught weirdo? I worry about this a bit, because I don't want to drift into weird territory if I'm to bring another programmer on later on...

You keep saying this. You need to trust your instincts more. I've read through your whole devlog and AFAICT they seem to be good. If you have gotten through a project of this size chances are you've learned the hard way to avoid the really awful things. Well, some people can do it and still be awful, but that takes exceptional talent.

In this case, it looks good. If you had a Fisher-Yates shuffle or shuffle-initialization routine, you could use that and the intent might be a little clearer, but to implement it just for this would be overkill. I'd just add a comment after the colorsL initialization saying "shuffle these values to produce a random color" or something.

http://en.wikipedia.org/wiki/Fisher-Yates_shuffle#The_.22inside-out.22_algorithm

Love your work, BTW.

[JLJac]

Thank you very much for the help and the reassurance :D

Embarrassingly I'm unable to repeat the bug... Sorry Probably it was just a screw up on my side...

Here's a more interesting issue:

Futile has something called "containers", basically the same as movieClips in flash - they're sprites that can have other sprites in them, and they can be nested in each other. I'll be using those for layering my graphics, and also I might use the nesting because that would make it possible to do cool stuff like fade out the entire HUD with just one line of code.

When adding sprites, I need to reference what container to add it to. So I use a "global" array that's a property of the main game instance in order to keep track of them. An object can say, for example, "add this sprite to container 3". It looks like this in my code:

Code:

tpGame.SpriteLayers[2].AddChild(spr);  

Here's the fun part: Ideally, I don't want a linear array of layers, but a tree-like array, reflecting the nested containers.

Code:

                      |Game Graphics -----  ForeGround        |Explosions
Main Container -------                     |                  |
                      |HUD  ---| HUD1      | Game Layer ------ Players
                               | HUD2      |
                                           | Background --- Bkg Image
                                                           |Bkg Sprites

It seems like a solution like this would make more sense than having a document by the side where you have a note that says "item 6 in the list is the Background sprites layer" - that's not very elegant.

In the best scenario possible, I'd want to be able to write something like:

Code:

tpGame.SpriteLayers.GameGraphics.Background.BkgSprites.AddChild(spr);

And I know that this can be accomplished by defining a class for each and every intersection in the tree, but if elegance is what I'm after, that doesn't seem like the way to go XD

Is there any way to create a tree-like structure like this? Note that all the branches can be different lengths.

[Juan Raigada]

Mmmm, I haven't thought about this much (first thing that popped to mind, actually), so maybe this is stupid... And mind you, I'm not good at C# (I don't use many of the advanced functions the language has, which is a pity, since it's beautiful -but I'm too busy coding my game to learn C#-), so probably there's a much better way to do this.

I'm guessing sintax is important. So that's what I have focused on.

You could extend <Hashtable>Hashtable() (let's call this class NamedNode) to have the AddChild function and an Object variable that holds the data of the node itself (let's call this NodeValue)

AddChild(Object o) basically adds another NamedNode using object's name as the key and assigns o to to that NamedNode NodeValue.

Then you write:

tpGame.SpriteLayers["GameGraphics"]["Background"]["BkgSprites"].AddChild(sprite);

and to access that sprite (that we are going to assume is named sprite):

tpGame.SpriteLayers["GameGraphics"]["Background"]["BkgSprites"]["sprite"].NodeValue; ->with a cast to the type you want obviously.

I don't know how efficient this will be, or if it will fit your purpose, though  Better programmers here might offer better advise...

[dancing_dead]

yeah, dictionaries/hashtables within dictionaries is a solution that would fit the requirements. the lookup will be more expensive, tho, than simple arrays (dicts are more efficient the more elements you have in them, but less than "many" is probably slower than simple looping through array). you can also have arrays within arrays/lists within lists, but you would have to lookup things by their index anyway, but there really is no problem with declaring a bunch of index variables, that have the names of the containers you're interested, i.e., int HUD1, int HUD2, int Background. however, if you go the arrays within arrays way, you would have to keep separate indexes for each array "level", so, actually, you could just have a single array with all the containers and then have proper index variable names, and then you would have it work like this:

Code:

tpGame.SpriteLayers[Background].AddChild(beautifulSprite);

you would have to manually figure out the drawing order, but given proper index names, it wouldn't be hard to draw the background first, midground second, then some gameplay action, and finally slap some hud on it.

alternatively, if the tree like structure is really needed, I would still do it the "inelegant" way - it's the fastest, gives you the syntax you want, and game scenes probably should share a universal structure anyway, so such structurization wouldn't be all that "inelegant" after all, imo.

my 2c, disclaimers (I don't know shit etc etc) apply, haha.

[JLJac]

Thanks guys! Wow, dictionaries and hashtables seem awesome, though I still haven't been able to figure out the exact difference between them...

Juan, your solution seems pretty amazing! It would enable me to name, remember and access every sprite, right? I'm not sure I understand it 100% hehe ... I just worry about the memory it would take to store names for hundreds of sprites D:

So, for my problem, maybe the simplest and most "elegant" solution would be to add all my containers to an old school array, and then use a dictionary to store their indexes? That way I could access something like this:

Code:

tpGame.SpriteLayers[sprLrsIndxDict["Background"]].AddChild(someSprite);

The question that comes to mind in that case is why not to use an enum? Then the auto complete would help me remember what I named all my layers.

Code:

tpGame.SpriteLayers[(int)SpriteLayerIndexer.Background].AddChild(someSprite);

Or, even better, maybe you could create an enum where the data type is a futile container?

Code:

FContainer  bkg = new FContainer ();
FContainer  fg = new FContainer ();
enum SpriteLayers : FContainer {Background = bkg, Foreground = fg};
SpriteLayers.Background.AddChild(someSprite);

That would be totally awesome, because it would be a neat way to clump together related data, and name it according to its function and have the autocomplete help me remember the names!

Then I could use that for a loooot of things! For example, if I want to store the some parameters for the playable level area, I could go like:

Code:

enum LevelParams : float {LeftPadding = 10f, RightPadding = 10f, RoundCornernsRad = 5f};

And then just access that easy as pie, without having to create a cumbersome class that would only be created in one single instance either way. I'm gonna try this out right now! The only thing that could make me happier would be the same thing but able to store mixed data types, and I think I read something like that in the Dictionary documentation page... To the hackmobile!


Edit: It turns out the enum structure is very particular about what data types it takes Only int, byte, long and a few others are valid. Perhaps a dictionary is the best way to create a list where you access stuff by a name rather than by an index number, then? 

[dancing_dead]

Whoa, hold your horses (and/or hackmobile, haha), Enums can't do that, they can be of a bunch of types, but all of these types are numbers, nothing more, they're not meant to hold large amount of data or anything.

I think this MSDN page agrees with me: http://msdn.microsoft.com/en-us/library/sbbt4032.aspx

You can, however, use an enum to keep track of the index variables, that might help with organization some, yeah.

edit: ninja'ed, but yeah. I'm not sure I even understand what seems to be the problem anymore.

[JLJac]

Hahaha yeah the hackmobile didn't even leave the garage this time XD

In Lingo, there was something called a property list. It was basically a little class that was declared on the fly. A declaration could be like this:

Code:

LevelParams = [#CornerRadius : 120, #BottomPadding : 40, #LevelName : "Magma Mayhem", #TerrainData : gigantic2Darray]

Then I could just grab anything out of that thing, like this:

Code:

levelTitle.text = LevelParams.LevelName

This was cool because it enabled me to group my data together by context. I didn't need to create a new property in the player class for every little parameter that was related to movement, I could just create a

Code:

MoveParams = [#Runspeed : 4.2, #JumpHeight : 2.1, #DefaultMode : "Running"]

and everything became a lot less cluttered.

Also, talking about tree-like structures, these things could be nested indefinitely. So I could group things, and then access them like

Code:

jmp = MoveParams.JumpParams.DoubleJump.Strength

I don't expect to be able to do this in C#, but if I was able to just group and label the data at all, even if everything in the same container needs to be the same data type, that would be awesome.

Dictionaries feel wrong, because they feel like they're used for searching gigantic databases rather than just grouping three variables together because they're related. I could create classes for all of those things, but it feels super cumbersome to have a million classes where the majority is just a container that holds two or three properties.

Is there some way to accomplish something like this, or is my approach just wrong from a purist programming point of view?

[dancing_dead]

you can define a small static class with a bunch of constants right inside the object class you want, you will only be able to access it from this object's class, but you avoid the pain of instantiation. or, if you want to access it from the outside as well, give it a small dedicated field, and create a new instance in the bigger object's constructor.

i.e., you have class LittleCreep, and in the body of LittleCreep's class you also define a small class LittleCreepMovement and add a corresponding field LittleCreepMovement to LittleCreep itself. LittleCreepMovement contains a bunch of floats "creepingSpeed", "amountOfLittle" etc, but in LittleCreep's constructor you instantiate this data field by simply calling LittleCreepMovement = new LittleCreepMovement(); and then you can read the data you want by just accessing this field.

it feels a bit hacky right now, but it's certainly fast and easy to do, not sure right now, what the downsides would be...

[JLJac]

This seems like the thing for me! Is it similar to this? Why is it hacky?  

I feel a bit confused, to be honest. You can create two classes inside of one class? Where does the code actually go? In the same text file, but where? What is a "namespace"? What is a "dedicated field"?

[dancing_dead]

That link talks about C# Properties vs Fields. Properties, in C# tongue, wraps some methods around the getting and setting of a field. For example, you have a private field called HP, but you want to also check if the object, who has this HP field is still alive and should still be updated, but if you just set the HP field, your object might be still hanging around even with 0 hp (assuming you don't check for it anywhere else). With properties, you can do this, tho:

Code:

private int health;
public int HP {
   get { return health; }
   set { 
           health = value;
           if (health <= 0) IsDead = true;
       }
}

you can also execute whatever code you want in the get accessor. for example, you can have a get property defined with no clear corresponding field, but code that takes several fields and outputs some math combo of all these fields, yet having it in a property gives you slightly different syntax compared with fields and methods.

namespace, hmm, probably MSDN has something wise to say about it, but, in my plainspeak, namespaces allow you to structurize your code into departments or something, and then only use the departments that are currently relevant for you.
at the top of the class files you usually have using directives/statements/whatever they were called, that say smth like "using System; using System.Diagnostics;" etc. these using things point to the namespaces and their corresponding "departments" that you currently want to use in this file.

and yeah, you can define a class inside another class, but you will be able to use that inside class from the inside only, I think (I might be wrong here, tho).

edit: it also "feels" hacky, because I haven't done things like this, is all, haha, so it feels unusual to me, but it might be totally ok, idk.

[Chromanoid]

Dictionaries feel wrong, because they feel like they're used for searching gigantic databases rather than just grouping three variables together because they're related. I could create classes for all of those things, but it feels super cumbersome to have a million classes where the majority is just a container that holds two or three properties.

You should have a look at http://wiki.unity3d.com/index.php?title=ExpandoObject.
These kind of behaviors are part of more dynamic programming idioms and not that fitting for C#. In .NET 4.0 you can use the dynamic keyword and a .NET implementation of ExpandoObject (see here and here), maybe Unity supports this too and the article is deprecated... Maybe you could port to UnityScript first. Behind the scenes of Lingo and the ExpandoObject in the unity Wiki etc. there are probably Dictionary-Implementations. So you can really use Dictionaries in your code when appropriate.

As an alternative you can use interfaces to define certain property groups: http://msdn.microsoft.com/en-US/library/ms173156.aspx But be careful, too many interfaces can become cumbersome too.

[Juan Raigada]

Oooh, I like those expandoObjects. As I said, I'm not that fluent in C# (never got to that chapter in the book ), but if Unity supports this (a link with an easy tutorial is this http://stackoverflow.com/questions/6329489/dynamically-add-properties-to-a-existing-object), it's exactly what you want.

But note, as Chromanoid says, that in the end they do implement a dictionary interface. Code wise it's much more elegant than my solution, but performance wise probably they are not that dissimilar... I don't know the lingo implementation, but an array of properties and classes needs to be stored and accessed at runtime anyway, and that's at the end a dictionary (which is something that access a value based on a key) -C# dictionaries aren't the fastest, but they are pretty fast-). I do not know about data structures to know if the hashtable is the most efficient dictionary for your specific problem, though.

I wouldn't worry about using dictionaries too much. They seem like the correct solution here. And it's more easily maintainable than enums or static classes. And it allows you to define new relations dynamically (which I think is what you are getting at).

[Noogai03]

One of my main problems with C# is that it doesn't (I think) have simple arrays you can instantiate with [] like in flash or python.
You can do

Code:

var thingy = new int[]{0, 1, 2, 3, 4}

- I use it for Flixel-style animation in my c# game engine, but it's less nice...
Correct me if I'm wrong 'cause that would be very nice indeed...

[Chromanoid]

In C# you do this exactly like that (see http://stackoverflow.com/questions/5678216/all-possible-c-sharp-array-initialization-syntaxes). C# is very expressive, especially the dynamic keyword is very powerful in this regard.

BTW @JLJac maybe you can create a "Rain World Programming Workshop" thread to fight thread pollution, but on the other hand this is a DevLog .

[jgrams]

Edit: It turns out the enum structure is very particular about what data types it takes Only int, byte, long and a few others are valid. Perhaps a dictionary is the best way to create a list where you access stuff by a name rather than by an index number, then? 

Yes, that's exactly what they're for. And if they're implemented properly they should be efficient at both small and large sizes...

As for the difference between Dictionary and Hashtable, maybe this is helpful? http://stackoverflow.com/questions/301371/why-is-dictionary-preferred-over-hashtable

--Josh

[Mstrymt]

One of my main problems with C# is that it doesn't (I think) have simple arrays you can instantiate with [] like in flash or python.
You can do

Code:

var thingy = new int[]{0, 1, 2, 3, 4}

- I use it for Flixel-style animation in my c# game engine, but it's less nice...
Correct me if I'm wrong 'cause that would be very nice indeed...

C# does have basic arrays see http://msdn.microsoft.com/en-us/library/9b9dty7d.aspx