jamesprimate on February 08, 2014, 05:31:27 PM:

no stress! we have a big update coming, with new video and info on what everybody is really here for: PUPS!!!!!









 

jamesprimate on February 09, 2014, 02:05:43 PM:

woooo! thank you gentlemen, for all your support and kind words!

Backer Animmikean sent us this cuuuuute $50k fan art to celebrate (wow those DA people are FAST, she sent this literally the MINUTE it hit $50k):



more news and updates very sooon!

jamesprimate on February 10, 2014, 04:30:35 PM:

3 DAYS! Then we finally stop spamming everybody! Seriously though, the support has been fantastic and you guys have all been amazing. Thanks for putting up with this ruckus.

We're doing another live-stream tonight as a sort of kickstarter wrap-up party to hang out with backers, media and friends, and you all are most welcome to join us. We'll be on http://twitch.tv/rainworld tonight, Feb 10th, at 8pm PST / 11pm EST / 5am CET

jamesprimate on February 12, 2014, 08:19:59 PM:

THE COUNTDOWN BEGINS!

This is it, only 24 hrs remain in the Rain World kickstarter! Help us give a big final send-off and spread the word: rt/share/blog, anything you'd like. Do it... for the slugcats!



~~~> https://www.kickstarter.com/projects/rain-world/project-rain-world

jamesprimate on February 13, 2014, 05:52:26 PM:

james "the other guy" primate 

for real though, i can't wait to get some more legit updates in here rather than my PR blathering. but hey, it's a dirty job and somebody has got to do it XD

JLJac on February 14, 2014, 06:35:17 AM:

Hahahaha XD That applies to all of us on the internet though... So thanks for all the good work James, who ever you are!

And in life. We never truly know each other - everyone we ever meet is a "whoever you are".

This has been philosophy corner. Back to Rain World stuff.

Thank you all for your support! This has really been a ride, and we are super happy and excited with the outcome. As you might have noticed, I've been mostly absent from here during the kickstarter days, which is because I figured that the kickstarter updates would be more fun if their content was a surprise. Now I plan to get back to transparency and back-and-forth communication again, so you can all look forward to following me in real time as I wrestle tedious little technical issues etc.

My plan for what to do next is basically play corner with different dev tools. Do a tutorial, mock up some sprites moving and some collisions, functions, objects etc just to see how it works, then try another one. This obviously shouldn't take weeks and months, as we want to get started on Rain World ASAP, but I think it might be a good idea to try two or three different setups before making such a long-term decision.

First up is Unity, I think. You are all more than welcome to drop suggestions for dev environments that you recommend! I'll also go back to the last time we had this discussion and look through what people said back then.

Cheers! 

JLJac on February 14, 2014, 06:54:19 AM:

If any of you know about a Unity 2D game tutorial with c#, throw it at me! The ones I find are very drag-n-droppy, with boxes that get behaviors attached to them etc. I'm looking for something that's more stripped of the unity stuff, where the game is written more in plain code - I want to have unity for the publishing options and debugging etc, the less user friendly drag-and-drop stuff I have to deal with the better.

JLJac on February 14, 2014, 07:14:37 AM:

When I look at the tutorials, I see a million things that makes me worry that they are unnecessarily performance heavy. Like, what I want to do is draw my characters from 20 different 1-bit 2D sprites, that are all moved from the same object instance in the code. In Unity they make sprites by creating a 3D box, giving it a "material" and then applying a graphic and a bunch of behaviors to it. They set an "ambient light" to 255, 255, 255 so that the sprites will have their natural colors, but I can't help feeling that that "light" function is still multiplying its color to every pixel every frame, even though it's invisible, and that makes me uncomfortable.

I want to use a much cleaner environment, not a 3D klick&play. But I'd still be up for using the debugging and structuring of assets etc that Unity seems to have. Problem is that I kind of need a real tutorial to get started, I can't figure everything out by myself. And the tutorials really seem to lean to the "user friendly" side.

I'll check out Futile, thanks! Using FixedUpdate and make one big game loop is obviously the way I want to go, if I understand this correctly - is there any turorial for that? Like, I don't want to drag any objects to the screen, I want to write a big game function that branches down into everything ~

JLJac on February 14, 2014, 11:48:33 AM:

So basically you get that stuff for free, because it's in the gpu and the gpu is made to run like, Crysis? Fair enough And this is the case even if I have hundreds of hundreds of sprites?

What is a drawcall and a manager?

JLJac on February 15, 2014, 09:51:20 AM:

Thank you all for your super useful advice!

So, a few hours of unity tutorial later, I feel like unity isn't my thing. If I made a game from scratch, perhaps, but now I'm porting and restructuring a current game, and everything that makes unity user friendly seems like it will get in my way big time. For example, the built in physics engine (basically a checkbox "yes I want physics on this object") will most definitely collide with my game. Also I don't want to drag scripts to objects etc, I want to build a proper inheritance tree with classes (this is what I've been missing in Lingo, and I'd like to try it because I think it'll save me the hassle of writing the same thing over and over).

My question is this: Is it possible to strip unity of every bit of pre-defined animation handling etc, and only use it for:
* Rendering sprites
* Handling input
* Audio
* Debugging
Basically I want to create all game behaviors myself, and only use pre-defined stuff for the stuff that isn't Rain World specific, such as interacting with the OS etc.

@Gimym JIMBERT
I see your point, and I won't make that mistake. Right now though, it's a question of what platform I should choose, and if I make the wrong choice I won't be able to go back, which means that I have to look some distance down the road despite it being premature. If I pick the wrong platform and it turns out the optimization I want to do can't be done when it's time to do it - trouble.

Last optimization question for unity: From how I understand it Unity has a lot of cool optimization and handles some functionality on the GPU, which is from what you guys have said basically free extra performance?

That's one hand - Unity does cool technical optimization stuff automatically that I wouldn't be able to do myself.

The other hand - Unity does a lot of things I won't use. Light, physics, cameras that can rotate and zoom, etc etc etc. I feel like I've just scratched the surface. All of those things take time, right? Even if I don't use them, I'm afraid they'll eat away milliseconds unnecessarily. My game is mostly just 1-bit graphics being stretched and re-colored, and it might be a bad bargain to also have all of them be lit and zoomed etc every frame, without it even being visible. Also some of this stuff might really get in the way, eg can I even rotate a sprite without it being anti-aliased?

Which of those two hands weight the heaviest? Does the fact that Unity does cool optimized GPU stuff make up for the fact that it also does a lot of cool optimized GPU stuff that won't even be visible? Or will the net be slower than if I just stripped away everything and wrote my own, clumsier, solutions?

Or even simpler put: Which is slower? 10000 super professionally optimized functions of which I only use 4, or 4 super clumsily written functions but nothing else?

JLJac on February 15, 2014, 10:44:09 AM:

I'll take your two cents! GPU power it is, why miss out on free performance?

I'm still hesitant to unity though, because I don't want their pre-defined definitions of what's an object, what's an animation, etc. I want to create my object instances myself, and move my sprites around myself with code. I've been told that this can be done, but I need a tutorial to get started. Can anyone direct me to something as weird as a unity tutorial that doesnt use unity tools, just pure code?

JLJac on February 18, 2014, 01:09:43 AM:

Thanks again guys Futile + Unity seems really good so far!

Wooooooooooow. The performance of this thing. I just had it draw 15 000 bouncing little balls with randomized alpha and color. Fifteen Thousand. Framerate doesn't even seem bothered by it If I try 20k some parameters seem to touch bottom and it won't start, but the limiting factor surely isn't performance.

Compare that to macromedia director, where I might maybe be able to have 150 semi transparent sprites moving around before things got slow. That's a hundredfold increase. I figure this is the renowned Power of the GPU.

Now on to stress testing the processor! I'm gonna mock up some Rain World like physics (trigonometry heavy) and see how that works out. Fun times!

JLJac on February 18, 2014, 03:45:00 AM:

Yeah, and thanks for the help! I'm super excited to have gotten started!

Ok, so now I see that the CPU is definitely the bottle neck here. 15 000 sprites moving around was no problem, but when I started doing some square root based distance checks between them I suddenly couldn't have much more than 200. If I did some optimizing (avoiding sqrt unless necessary) I could get up to 1000 or so, except in special scenarios (all the balls packed together so that they do a lot of distance checks between each other) when the framerate would drop.

This shouldn't be a problem though, as the standard Rain World scenario doesn't have 200 objects all checking distances against each other. It's nice to know that as long as I don't bring too much CPU heavy stuff like physics etc into the equation I can have basically unlimited moving sprites on the screen. Makes me think quite a lot about different exciting possibilities...

Then again I've only tried this with extremely light-weight graphics. There could very well be an exponential increase in performance demand as I use bigger graphics with more color depth - so I should definitely try that before I celebrate too much.

Currently I'm contemplating whether to continue to play with this current setup and try to create more game-like mechanics to feel what that feels like, or if it's time to move on to MonoGame. Much of the stuff I need to try/learn is C# and not Futile or MonoGame specific, and as I'm having fun with this I figure I could just hang around for a bit and learn more about inheritance etc.

JLJac on February 18, 2014, 08:36:03 AM:

Oh, so unity already has a thing for distances between vectors!? And also for normalizing! And a bunch of other stuff! So cool

The Unity built in Distance function wasn't much faster than my home made pythagoras theorem function though, in the end I guess they do the same thing. Concerning optimization, I don't think space partitioning would really be a good bargain in Rain World - mostly there are relatively few collidable objects at a time (10-50 rather than 100-500), and keeping track of which zone they're in might even be more of a hassle to them than just checking against each other.

Each RW creature consists of several parts. In the old engine I optimize by doing a rough check where I use something I call a "distanceWithin" function, essentially pythagoras theorem but by having a defined compare radius (I'm not interested in what the distance is specifically, just if it's smaller or greater than this radius) I can avoid doing the square root. So I check from one of the body parts in one creature to one of the body parts in the other creature, and only if that distance is smaller than say 8 tiles I actually check all the body parts against each other. This worked OK, so I could do something similar here. But, as Gimym JIMBERT says, I probably shouldn't get stuck in premature optimization. It's better to make the game run, and look into optimization when you actually need it.

? ? ?
Keep talking!

JLJac on February 18, 2014, 09:26:42 AM:

Thanks! I like it too, so far!

Hm... On the subject of draw calls. I noticed that unity has a little thingie in the top left where you can see the number of draw calls. I decided to check that out, and made it so that my moving sprites got their textures from two different atlases, assigned randomly.

Instead of 2 draw calls, I got some random number in between 1 and the number of sprites I use, which made me think that it goes through them one by one and every time one of them uses a different texture from the last one, it unloads the old texture and loads the new texture, creating an new draw call. Surprisingly this didn't seem to affect performance at all, but my sprites are pretty light weight.

Is my theory correct? In that case, is there some way to manage the draw calls, so that you put all the sprites using one specific atlas in an uninterrupted queue before moving to the next one, getting only one draw call per atlas? Do I need to care, it seems to run just fine?

Another question that's more relevant to my game making stuff rather than optimization - how do you sort sprites? I'll give you a super simple example just so you know what I'm after:

Say that you have bouncing balls, and each ball have a shadow (2 separate sprites). You don't care about the internal order of the ball sprites or the shadow sprites, but you want every ball to be above every shadow. When you create a new ball its shadow should be in the "shadow layer" behind all the other balls.

Unity has some kind of layer functionality, right? Can I tap into that from Futile? Can I nest layers within each other?

JLJac on February 18, 2014, 11:58:52 PM:

@Juan, ah I see... Uh, I was kind of happy to move to Unity because there was so much documentation, and here I am again hehe. But most of the problems I encounter likely won't be Futile-specific, so I think it's not a major problem

@dancing_dead, thanks! Checking it out! When it comes to the draw order, I understand that what gets drawn later ends up on top of what gets drawn early - problem is that I've found no way to control this in Futile - they just seem to do the classic where they go by the order the instances of the sprite object was created. This does give me the possibility to do a hack where I start up like, 1000 sprites right at the start and have them idle outside the screen, then I'd be able to manage them through some kind of function from which objects could request "the highest possible sprite" or "the sprite that's closest to 870" or things like that. But that seems like a really slow and limited way to do it. I'll do more Futile research!

@Bandreus, thanks! This is weird... I think that what I see might just be Unity's dev tools being confused by Futile. If I use only one atlas, I get only 1 draw call, and a framerate of 60fps with 15 000 sprites. If I use two atlases, I get a couple of thousand draw calls, and the framerate drops to 20fps. I don't really see what logic is behind that relationship... It's not like 60/4037 is 20.

I do alpha blending, rotation, color tweaking etc in my stress test, and still only get 1 draw call if I use only 1 atlas, so I don't know... Once again, could just be Unity being confused.

Word!

JLJac on February 19, 2014, 12:50:07 AM:

Thanks! So yeah, it's as we suspected then. I'll just try to keep everything in the same atlas, and there shouldn't be a problem

Also, I found out how to do "layers" in Futile, they're called "containers" and seem really great! From how I understand it they resemble movieClips in flash, in that they're basically a sprite that has other sprites drawn inside it, and if you move or rotate the container every sprite in the container moves and rotates with it. Hopefully you can do other fun stuff too, such as color tweaking an entire container or the like. I assume that you can nest containers as well - if that's the case I have a truly awesome tool for keeping everything sorted and tidy and in the right z-order, without even having to use sortZ

JLJac on February 19, 2014, 01:26:56 AM:

Cool! Actually the game only has a megabyte or two worth of graphics, because it's almost only low-res 1-bit stuff, and the majority of the animation is done by code rather than by having huge sprite sheets. The largest animation image data wise is probably the player legs' running animation which would fit in, like, a 150*40 pixels sprite sheet. Where all the content is is in the levels, and they are loaded from external files. I think texture packer is accessible from code, so ideally I could use that and end up with one atlas for the level, and one for everything else. So no problem there :D

A problem that might be more pressing - in Rain World, I use two things that I haven't been able to find in Futile - Bézier curves and "quads" as they're called in Director. A "quad" is a sprite that's transformed to fit in a shape defined by 4 arbitrary positions, one for each corner. The "quad" I think there's hope for, with Unity being 3D at its core and all, but Bézier looks worse from what I've been able to research. I'm super terrible at reddit though, so what do I know :S

In the end I guess it can't be impossible to get Bézier curves into Futile, or use some type of extra plugin. Worst case scenario someone could perhaps be hired to do it (Actually having money is such a surreal feeling).

JLJac on February 19, 2014, 02:54:44 AM:

Other, less Futile-specific question: Does anyone know of a good tutorial for making games in c#?

I'm able to fiddle around and make things do stuff by myself. But I worry that I will drift into weird self-taught unconventional territory with my solutions, which could be bad for optimizing and would be bad if I want to have someone else work with the code later. Remember that I have no formal programming education, everything I've learnt is basically trial and error, and I don't know much about the traditions and customs of professional programmers.

So if someone knows of an article or something that just outlines the standard go-abouts for making a game loop, using inheritance, having objects interact etc in a C# game, that would be gold! I imagine that this is a pretty separate issue from the decision of what I'll be using for drawing sprites etc.

JLJac on February 20, 2014, 12:47:02 AM:

This is amazing! So much useful stuff! Interestingly it seems I have already been using some of these methods, but without knowing the name for them. So maybe I don't need to worry too much about my intuition taking me bad places. But much of the stuff he's talking about is obviously more refined than my own home-brewn solutions, and I feel like I'm really learning a lot reading this. I'll make a list of the things I find particularly interesting and see if I can find implementations for them in C# specifically, some of the stuff I've encountered here I suspect might be C++ specific. Do you know of any more resources such as this? It's a good read

No, I'm not going to re-create the game from scratch, and it will probably be a lot faster the second time around because instead of going through this process:
  Decide on what I want to create
  Figure out a solution on how to implement that
  Implement the solution
  Iterate, iterate, iterate, iterate
I'll be cutting that down to just
  Figure out how this will work in C# (mostly the same)
  Implement

However I will do some restructuring, because the old engine didn't use inheritance and thus had a lot of redundant code. That's mostly because I didn't have overview of what I wanted in the game, I just added things one by one, giving each its own solutions to basically the same problems. In hindsight I understand, for example, that the players' forepaws shares a lot of behavior with the lizards' legs, and because I know that both of those entities will be in the game already, I can plan around that.