next »

[Bandreus]

3D graphics, shaders and that sort of stuff definitely isn't my bread and butter, but still I'm not sure why people is willing to dismiss drawing mathematically defined curves within them. Did a quick google search and a bunch of stuff popped up.

Again, BIG DISCLAIMER, I have no idea if any of this would be feasible in Unity/Futile, but here you go:

http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html
http://research.microsoft.com/en-us/um/people/cloop/LoopBlinn05.pdf
http://stackoverflow.com/questions/10300271/bezier-curves-loop-and-blinn-style
http://www.opengl.org/discussion_boards/showthread.php/171885-Rendering-resolution-independent-Curves

etc etc

It might as well be Juan is right, and a simpler solution to Joar's needs might be possible, though I guess that's up to him deciding what kind of implementation fits best

[Whiteclaws]

Shaders are programs that run on the GPU and process data they are given in your main program , the syntax for shaders is pretty similar to C, you can write yours, basically, from what i can see , you will only need 2 shaders, vertex and fragment, lemme see , I bought a book ... I'll get you the definitions, a vertex shader will be called to process the data whenever you issue a vertex via a drawing command (goes thru every vertex), and the fragment shader determines the final color of each pixel, it kinda processes the final image (goes thru every fragment , a.k.a pixel)

for the bezier thingy, you could pass an array of uniform 4x2 float matrices and each row of the matrix would be a 2d position and a 2d direction , each matrix would be a curve, and you could draw those bezier curves in the fragment shader
Here you go

[gimymblert]

This video explain the difference between procedural rendering (classic way of puting things by finding coordinate) and functional rendering (shader aka run a prog at each pixel)




shader for noobs in unity3D:
http://en.wikibooks.org/wiki/GLSL_Programming
http://en.wikibooks.org/wiki/Cg_Programming/Unity

http://unitygems.com/noobshader1/
http://unitygems.com/noobs-guide-shaders-2/
http://unitygems.com/noobs-guide-shaders-3-realistic-snow/
http://unitygems.com/noobs-guide-shaders-4-toon-shading-basic/
http://unitygems.com/noobs-guide-shaders-5-bumped-diffuse-shader/
http://unitygems.com/noobs-guide-shaders-6-toon-shader/

https://cgcookie.com/unity/cgc-courses/introduction-to-surface-shaders-in-unity/
http://cgcookie.com/unity/cgc-courses/noob-to-pro-shader-writing-for-unity-4-beginner/
http://cgcookie.com/unity/cgc-courses/noob-to-pro-shader-writing-for-unity-4-intermediate/

http://http.developer.nvidia.com/CgTutorial/cg_tutorial_chapter01.html



More there:
http://forums.tigsource.com/index.php?topic=32227.0

[Chromanoid]

Drawing 2D shapes with shaders is not easy, especially antialiasing etc. often poses a hard challenge. I would recommend to make "3D objects"/"triangulated 2D shapes" out of everything you need (i.e. with Blender). Just render those instead. For what purpose do you want to draw splines? If you just want to visualize motion paths for debug purposes I guess you can use the http://docs.unity3d.com/Documentation/Components/class-LineRenderer.html. Converting splines to vertex points shouldn't be a problem for you.

[Bandreus]

He uses spline/bezier curves for his procedural animation

[Chromanoid]

For moving objects along a curve? Maybe https://www.assetstore.unity3d.com/#/content/3595 is interesting in this regard.

[Bandreus]

Nope, you don't understand. He generates some of his graphics proceduraly. Like, if you take a lizard for instance, only the legs and head are actual sprites in an actual spritesheet, the body is proceduraly generated in real time.

I don't remember the specifics, but I think this technique is used very pervasively. It's explained in significant detail throughout the devlog.

[Chromanoid]

Ah, I see, didn't read that. I would either export the generated graphics from director to a sprite sheet or use http://docs.unity3d.com/Documentation/ScriptReference/GL.html to generate vertex data on the fly. Maybe a circle/rounded rect shader makes sense, but I would try to avoid anything more complex (see http://www.geeks3d.com/20130705/shader-library-circle-disc-fake-sphere-in-glsl-opengl-glslhacker/3/ or similar stuff).

[JLJac]

Thanks so much again guys 

Update 218
Let's get back to some devlogging haha!

Made two maps for how Rain World c# is looking in my head at the moment. I made them both to clarify my own thoughts, and so that you guys could give me an opinion on it

First up are the classes:



Those are the most basic classes I know I'll need. Later a lot of new ones will definitely pop up, such as "level loader" etc etc, but this is just what's needed to run a basic game session.

What do you guys think? Am I using inheritance the right way?

Then, what I call the "instance tree" or "update tree":



This is the structure through which the "update" command is forwarded each frame. The general idea is this - objects own each other, and objects further down the hierarchy are dependent on their "masters". Masters are autonomous.

So for example, a lizard has four limbs. It creates them on startup and saves them in an array. The "Room" (which is the class that does most of the game engine stuff) is not aware of these limbs, it just has a reference to the lizard. Every frame, the Main Loop tells the Room to update, the Room tells the Lizard to update, and the Lizard tells each of its Limbs to update. The Room doesn't need to bother about the Limbs.

One thing that might need a special mention is the BodyChunk class. This is basically a physics object, the one that will do collision checking etc. Note that contrary to how many games would do it, the creatures are not physical objects, they have them. This is because of the exact thing that gives Rain World its animation style - that each creature has many segments which makes them soft and bendable.

This means that the creature classes (lizard, player, etc) are just coordinators of other instances, and "communication hubs" those instances can use to talk to each other. For example, a lizard will own an instance of LizardAI, and when LizardAI wants to know where the body of that lizard is, it'll go by the Lizard instance. From inside LizardAI I imagine it might look something like this:

Code:

Vector2 myPosition = parent.bodyChunks[2].pos;

where parent is a reference to the Lizard instance, bodyChunks is an array of the BodyChunk instances that Lizard has, and pos is the position of a specific BodyChunk.

Similarly I imagine the Room will be a communication hub where difference creatures and objects can find each other. Say that a LizardAI wants to loop through all the items in a room to see if one of them is a spear. Then it could look something like this:

Code:

Spear spear = null;
for (i=0; i < parent.currentRoom.objects.Count; i++)
{
   if (parent.currentRoom.objects[i] is Spear){
      spear = (parent.currentRoom.objects[i] as Spear);
      break;
   }
}

Where parent is the Lizard that owns the LizardAI we're currently in, currentRoom is a reference to the Room that Lizard is currently in, and object is an array in the Room used to keep track of all the objects.

The idea here is that when two things some way out in the branches (LizardAI and Spear) want to communicate, they have to trace their way back to the last common branch (LizardAi -> Lizard -> Room). This is my interpretation of an un-messy way to do things without using globals, and I just wanted to check if you think it looks OK.

It just struck me that in the Classes map, creatures, items and effect sprites should probably all inherit from an "updateable object" class that the rooms could hold in arrays and dish out update commands to. Please consider that changed

So, what do you guys think? Does it look reasonable? Any critique super welcome 

[eigenbom]

Looks alright. I think Body part and Item should only really be in hierarchies if they differ a lot in functionality. In my game, for example, I've basically just got a single item structure that holds the union of all item parameters with an item enum. The main benefit is that all the item code is then in one spot, and I can switch/case on item.type.

The real test for a system design like this is to run through some really complex aspect of your game, like looking for, picking up, and throwing a spear, and see how complex the web of interactions between classes will be.

[dancing_dead]

these class diagrams are looking pretty nifty, nice.
also, yeah, you're doing it alright, from your descriptions. I would have done most of the things somewhat like that, too, except without the pretty diagrams, but it seems the oop intuition is strong with you 

[Juan Raigada]

It just struck me that in the Classes map, creatures, items and effect sprites should probably all inherit from an "updateable object" class that the rooms could hold in arrays and dish out update commands to. Please consider that changed

So, what do you guys think? Does it look reasonable? Any critique super welcome 

It's definitely a nice class structure. I would take a look at C# interfaces, though, because those could help you organize things better.

Basically, a class can inherit from multiple interfaces, so the updateable object class you suggest is better suited to be an interface, since it seems it's just a series of functions and variables that are common to those classes but that have not "base" implementation -that is, the updateable object class would only define methods, but would contain very little to no specific logic. When you have something that just defines an interaction method (a function name and parameters, for example, but all those functions will have specific logic on the children class, you should use an interface, since it gives you flexibility.

But, it's more a matter of code organization, and your scheme seems perfectly usable, so I wouldn't sweat too much about it (specially since you are porting an already designed game, so you already know the functionality you will need!).

[JLJac]

@eigenboom: Yeah, that's a good point - object oriented programming is a tool, not an orthodox religion. For the items it might very well be better to use an in-class solution rather than messing around with a bazillion text files and classes. The limbs have very different behaviors though, the only thing they have in common is basically a "position" parameter and a "owner" parameter, so there the inheritance seems like a good fit. A quick question on that note: The limbs will all have Owners, but some of them will have Owners that are slugcats, some lizards, etc. This makes it difficult for me to decide what to declare the Owner parameter as - if I declare it as a Creature I'll have to go "(owner as Lizard)" for every single line in the lizard arm, for example, which seems unnecessary as I know that a lizard arm will only be owned by a Lizard. Any ideas for this? Should I declare the Owner variable in the child classes rather than in BodyPart? That seems weird as all of them will have an Owner.

For the items, maybe a clean solution would be state classes? Has anyone played with those in c#? I get the general idea, but I have a hard time translating the examples to c# syntax. How do you make this thing work? Do you create an instance of each state class at startup, and have a currentState variable that points to the one that's currently active? In that case, what would you declare currentState as, as all the states have different classes? If anyone has some more on this design pattern in c# I'd be happy, as I plan to use it for the different "animations" for the creatures as well

@Juan: Thanks! Looked up interfaces, and made a (somewhat messy, but working) implementation in Space Worms. It's very useful!

Other question: In the old code, the game held a lot of lists of objects by type in order to be able to easily access them. So for example, I'd have a CreaturesL, a LizardsL, a PlayersL, a SlugcatsL, a PupsL, etc. A player, for example, would appear both in PlayersL and in SlugcatsL, where the latter would also have references to all the pups. This was very useful (sometimes I wanted to check something against players only, and would then repeat through PlayersL, sometimes I wanted to check something against pups and players, and would then use SlugcatsL) but I have a hunch it might be considered impure programming-wise. Is that hunch correct, or can I go ahead with my many not-mutually-exclusive lists?

Other other question: For the Game, Hunt, ShortcutHandler instances, should I use singletons? Those seem to be very taboo?

[eigenbom]

...if I declare it as a Creature I'll have to go "(owner as Lizard)" for every single line in the lizard arm...

Ah, the fun of OO! Can you do something like this? (I not too familiar with C#)

Code:

class Limb<T>{
  T owner;
  vec2 pos;
  // other commonality
};

class LizardArm: Limb<Lizard>{
  // extra stuff here ...
  void do(){
    if (owner.canClaw){ ... }
  } 
};

class Lizard {
  List<Limb<Lizard>> limbs;
  bool canClaw;
};

But if Limb<T> is only used to store owner and pos, and you never need a list of generic Limbs anywhere, then it's probably too much abstraction and you should just have LizardLimb, SlugCatLimb, etc.

For the Game, Hunt, ShortcutHandler instances, should I use singletons? Those seem to be very taboo?

I would use single instances, but not the strict Singleton pattern. Instantiate one of each and provide a static function to return the instance. I'd be very careful of over-engineering this thing. Have you considered rapidly creating a simple Unity prototype of the basic gameplay? It will probably reveal a whole heap about the best Unity-compatible way to build this thing. In the couple of Unity things I've made I always had a single empty object, called Game, that had a Game script (and thus was my single instance).

(Lists...) I have a hunch it might be considered impure programming-wise. Is that hunch correct, or can I go ahead with my many not-mutually-exclusive lists?

Hmm .. from the screenshots I saw there were never many objects in the world. If that's still the case then I'd probably start with a single list of all game objects, and perform your filtering/queries on the fly. Maintaining sub-lists is an optimisation you may not even need. To simplify you could provide a bunch of helpers, then if you're taking a big performance hit you can think about caching with extra lists as you did in your previous code.

Code:

// Helpers
List<Pup> happyPups(){
  return allThings.Where(thing => thing is Pup && (thing as Pup).isHappy()).Cast<Pup>(); // not sure if this is possible in a single line..?
}

[Juan Raigada]

Other question: In the old code, the game held a lot of lists of objects by type in order to be able to easily access them. So for example, I'd have a CreaturesL, a LizardsL, a PlayersL, a SlugcatsL, a PupsL, etc. A player, for example, would appear both in PlayersL and in SlugcatsL, where the latter would also have references to all the pups. This was very useful (sometimes I wanted to check something against players only, and would then repeat through PlayersL, sometimes I wanted to check something against pups and players, and would then use SlugcatsL) but I have a hunch it might be considered impure programming-wise. Is that hunch correct, or can I go ahead with my many not-mutually-exclusive lists?

I agree with eigenbom that maybe you are worrying too early about optimization, but as he points out, Generic lists (which actually are not generic, but class specific) will be fast if you need them.

[Noogai03]

Unless you really need to, try to avoid using LINQ such as

Code:

// Helpers
List<Pup> happyPups(){
  return allThings.Where(thing => thing is Pup && (thing as Pup).isHappy()).Cast<Pup>(); // not sure if this is possible in a single line..?
}

in functions where it's called every frame because it's REALLY slow (lots of garbage created), same with most LINQ including foreach loops sadly.
It's ok to use for initialization or something only called once, but putting it in an update method is a bad idea generally. And it's pretty easy to avoid LINQ on the whole.

Bear this in mind for a finished product, though also don't go to massive effort to avoid it (premature optimization )

[dancing_dead]

same with most LINQ including foreach loops sadly.

not sure if I understood this correctly, but foreach loops don't require LINQ, and, while they do generate garbage compared to a simple for loop, they can be quite a bit faster, depending on how complex the condition in the for loop is.

the advice to avoid LINQ is good, tho, especially using Mono, some versions of which still struggle with garbage collection big time.

[eigenbom]

A non-LINQ alternative might be something like this:

Code:

public IEnumerator happyPups()
{
  foreach (Thing thing in allThings){
    if (thing is Pup && (thing as Pup).isHappy()) yield (thing as Pup);
  }
}

..

foreach(Pup pup in happyPups()){
  if (pup.smileTimer<0) pup.smile();
}

[JLJac]

Thanks!

The reason I used those lists wasn't mainly optimization, but to make the code cleaner. Instead of looping through all the objects and clutter the loop with conditions, I could just ask for whatever category of object I wanted.

But maybe with inheritance I could make the same thing work with only one single if statement? Say that I have Player and Pup classes, and they both inherit from the Slugcat class. Players and Pups are in a huge ObjectL list with all object of all different classes, only sharing an interface. I want to get Players and Pups, but nothing else. Could I use the IS keyword and check for Slugcat?

Code:

for (int i = 0; i < ObjectsL.Count; i++){
  if (ObjectsL[i] is Slugcat){
    //do stuff
  }
}

If that would work it's a solution that's clean enough

Update 219

I've been researching the state pattern a bit, as I think I will use this a lot in rain world. In the old code I use switch cases on strings, and I use it for everything. AI states, animations, etc etc. This time around I want to do it properly, using the state pattern, which I feel I really like but haven't quite pinned down yet.

I've mocked up a little powerup system in Space Worms using the state pattern, and it seems to work well

There are a few things I feel weird about though. For example I've declared the state classes inside the Player class, as I think of it as a sub-system of the Player. Is this the way most people roll, or do they have an external text file for that stuff? The Player class is becoming rather big.

An other thing is that in an example I found, the guy created one instance of each state on start up, and had a currentState variable pointing to which one was active. I have chosen to instead create a new instance of the state when I change it, as it feels weird to have a couple of inactive states hanging around.

My idea is this, tell me if it's wrong: If I change state very often, like, every frame, it might be nice to have one instance of each state hanging around and just point to the active one. Because creating and deleting the state instances every frame would generate garbage. On the other hand, if you change state very seldom (say, once in 30 seconds for space worms powerups) you might as well kill and spawn the state instances, for cleanliness' sake.

For Rain World I don't quite know which approach I'll be going with yet. For AI I think it would be really cool to have an instance for each state hang around and be inactive, because then the creature could pick up its behavior where it left off once it goes back to it! Say that a Lizard is doing something, like searching through some tiles, and then it is interrupted by some other behavior, like snapping after annoying flies. With the state pattern and consistent instances, I could go back to the search behavior, and the list of tiles searched would be intact - the lizard could just pick up where it left off, like it had a memory! Totally cool!

Could maybe combine that with pushdown automata...

[Noogai03]

same with most LINQ including foreach loops sadly.

not sure if I understood this correctly, but foreach loops don't require LINQ, and, while they do generate garbage compared to a simple for loop, they can be quite a bit faster, depending on how complex the condition in the for loop is.

the advice to avoid LINQ is good, tho, especially using Mono, some versions of which still struggle with garbage collection big time.

ah, sorry about that. But doesn't it create an object for every item in the enumerable? That could lead to a lot of garbage, surely?