next »

[JLJac]

I ended up using the dictionary approach. Just want to once again confirm how incredibly thankful I am to have you guys help me :D

The sprite stuff now looks like this - I create an array of sprite containers, and I also have a dictionary where I've named each of the positions in that array. In order to not have to fetch both of those variables from the main game class each time, I've created a little function that looks as such:

Code:

public FContainer returnFContainer(string index){
   return SpriteLayers[ spriteLayerIndex[index]];
}

Where SpriteLayers is the list of FContainers and spriteLayerIndex is the dictionary. Then I can, from the objects, super easily add a sprite to whatever layer I want like this:

Code:

tpGame.returnFContainer("BkgLayer").AddChild(spr); 

It works like a charm Best thing is that if I want to add a layer in the middle of the stack, I just have to change the dictionary in one place, rather than index numbers in all the objects. As long as the strings are the same, they'll find their layers!

I should probably start a workshop thread... But now I feel like I'm ready to start working on real rain world stuff soon, this learning phase should be more or less over.

I'm doing a tiny little learning project, not because I want to waste time not working on rain world, but because I felt that it was better for me to start rain world porting with some tools in the box and some basic knowledge, so I wouldn't immediately clutter rain world with a bunch of stuff I'd implement just to learn this new environment. Now the test project is done, and the last thing I want to implement is a menu, so there's somewhere to press "restart" and I can share it with you guys for fun

This also brings me to another thing I'd like to learn - someone mentioned creating a little mini class inside a bigger class.

My main menu will have four items. All of these have a lot in common, they each hold an FLabel (futile's text sprites), they should all be selectable, they should all change color when selected, etc. A lot of behavior in common, simply.

This calls for a "MenuItem" class. But the "MenuItem" class should only be instanciated and manipulated from inside the "Menu" class. Also it's a very small class which only holds a few variables and hardly executes any code, so it feels weird to roll out the red carpet and give it an entire text file of its own. Ideally, I'd wanna create some kind of mini class that's only available from inside the "Menu" class.

After searching for "c# nested classes" I think this might be the thing, but I just wanted to check with you guys if this practice is considered halal, and if you have some tips or tricks to be considered?

[Savick]

Just wanted to say that slug cat is the best cat. 

[JLJac]

Thank you sir 

Mini class works super well 

Stupid question #4224:

Now both the players and the menu need to take input, so I want to create a FetchInput function where you pass a player number and get the current state of axes + button for that player's input.

Now, the problem is that I want to return both a Vector2 for axes, and a bool for the fire button. Do I have to create a separate text file with an InputData class only to be able to return these two variables in one go? That feels super cumbersome. Also I know that I could bake them together into a Vector3, but that's a hacky solution that I'm not learning anything from - I want to be able to solve this problem no matter what the data types happen to be.

Is there some equivalent of

Code:

public Vector2, bool fetchInput(int playerNum){ 
return new Vector2(0f, 0f), false;
}

that I could use? One of my searches suggests returning a KeyValuePair, but that seems like a hack IMO... 

[Kingel]

You could return a struct.

[Bandreus]

Many different approaches are possible. (again, please keep in mind I'm not at all that familira with Futile/Unity, but here I go).

You could use a struct (or a class even) as a container for the current state of input devices as Arachne suggested. You pass the reference to an instance of said container (instancing a new struct or object every time you fetch input would be bad) to the fetchInput and the function would populate the instance with up-to date info about the state. Then you run all of your logic based on the values within said instance.

OR, you simply invoke fetchInput and have the function set the value for an appropriate set of vars (playerInput[2]axisVector2 = (0f, 0f), playerInput[3]isButtonAPressed = false or what have you). The variables representing the state of the input devices could be static properties of an helper class, for easy access from anywhere in your code.

Just pick whatever solution suits your needs best. Most of us accomplish stuff in the most hacky way possible, and the world (usually!) doesn't explode, trust me 

Oh, and don't forget rule #1 of game development: the user never looks at the code, nore does she care about it.

So yeah, as long as you find an implementation which works without breaking the whole thing and does exactly what you need it to, don't be shy to adopt an hacky approach to stuff. Bottom line, you can always go back and do stuff in a more elegant way later, if you really need to.

I like the helper class approach and that's what I use most of the times, mainly because I can pull the input state at the beginning of the game loop without having to deal with passing references/variables all over the place. The helper class stores the relevant state for the whole time and it's always there, ready to be checked no matter where in the code base the game logic needs to do stuff. It's moderatelly hacky, but it works (at least for me it doeas!)

If you need additional reference about parameter passing in C# I suggest this and/or this.

[Sebioff]

In other languages you'd usually return a struct/array - the C# solution (as long it's just a couple of values you want to return) are out parameters.

[Juan Raigada]

Struct should work. I don't think you need an object for this (since the information will be used and discarded).

But anyways, looking forward to seeing an slugcat moving around in Unity!

[JLJac]

I used out paramaters - they're awesome! I'm learning so much these days my brain almost can't take it   Why oh why didn't I start with C# earlier?

Here's the test project I've made this last week!

The game has quite a bit of Rain World-like stuff going on in it when it comes to the physics, because I wanted to try that out. What it lacks is levels, loading and saving files, sound, and much more, so I still have stuff to learn   But those things I can probably solve as I go - the reason why I made Space Worms was that I needed something simpler to just see if I could get stuff to move on the screen before diving into the depths or RW code. Also I didn't want to have a lot of junk in there from when I didn't know very basic stuff, and I did dodge a few of those bullets - for example I wrote myVector[0] instead of myVector.x for a while, and similar stupid things. Not to say that I'm not still doing stupid things that I'll pull my hair over in a few months, but at least a few of them are out of the way.

I think I'm ready to start the porting, actually!  

I still worry about a few things.


MonoDevelop is slow on my computer, and comes up with stupid autosuggestions once in a while. The Unity console is s**t - it's not in any way a stranger to just skip logging stuff whenever it feels like it. That could probably be circumvented by creating a custom logger that logs to a text file, maybe?

In director I could "watch" an instance and see all of its properties change in real time as the game played. Whenever the game froze because of an error, it would go to where the error occurred in the code, and show what every variable was at the time. If I had for example an array of object instances, I could expand each of them and see what its properties where at. I had a console in which I could write snippets of code and execute them, if the game was running or not. This new environment is clearly inferior when it comes to those debugging assets.

Vector graphics and bezier curves, I can do without them but it would be cool to have them. At least simple shapes like square/circle.

I haven't tried sound.

I haven't tried importing graphics (this might be a problem because Futile only takes its weird texture thingies)

I don't know if I can retrieve the color of a pixel into my code with perfect accuracy. (I save level data in the level image file encoded as colors)

Futile doesn't perfectly respect the pixels. An edge that is 2 pixels wide might end up 1 pixel wide in the game (look at the lives bar in the HUD of space worms). This isn't a super big problem for Rain World which isn't very pixel art-centric, you won't see if a perfectly white silhouette is one pixel off. But it's still very annoying, and might become a real problem with for example the level graphics.

If a graphic is shrunk substantially, it will invent edge smoothing colors despite the texture being set to "point". You can see this on the very small rocks in Space Worms. This can be avoided in all Rain World scenarios I can think of, but is still a very annoying flaw.

The game becomes HUUUGE! The code and the graphics of space worms are together less than 200 kb, still the published game occupies 147MB before compression and 15MB after compression. Whaaaat?


Maybe I should try to make Space Worms work in Monogame as well - just to see if some of the above problems are absent there? Maybe someone can cue me in on that right away?

Thanks again for helping me!

[Juan Raigada]

Ok!!! (I love this)

MonoDevelop is slow on my computer, and comes up with stupid autosuggestions once in a while. The Unity console is s**t - it's not in any way a stranger to just skip logging stuff whenever it feels like it. That could probably be circumvented by creating a custom logger that logs to a text file, maybe?

You can use any other code editor. I will ask the other programmer in Heart&Slash (who's much better that me) what he uses (I think it's free and powerful). The Unity console is just OK. If you click on a line, it shows additional logging (it groups log outputs by frame, I think). Also, if you get certain errors (null references are the most common case)  Unity will NOT EXECUTE THAT FUNCTION ANYMORE during that execution run. It will just skip it the next time it finds it. This can be the source of annoying bugs if you don't know it. If you have a Red error in the console, assume your code is not being executed and fix that error before doing anything else.

In director I could "watch" an instance and see all of its properties change in real time as the game played. Whenever the game froze because of an error, it would go to where the error occurred in the code, and show what every variable was at the time. If I had for example an array of object instances, I could expand each of them and see what its properties where at. I had a console in which I could write snippets of code and execute them, if the game was running or not. This new environment is clearly inferior when it comes to those debugging assets.

Again, Unity vs Futile. I don't know how futile structures it's object once it's running, so you'll have to check, But in vanilla Unity, you can click on any object in the scene hierarchy (with the scene paused or running) and all it's variables will show real time in the inspector (the private ones only show if you activate debug display in the inspector -upper right corner-). It's actually an amazing amount of information this gives, so I disagree completely with calling Unity's environment inferior at all.

Futile might be using objects that are not serializable (not serializable objects do not show in the inspector), or you might just not be looking for it. But in a normal Unity project you have access to all this, so maybe it's there (remember the texture settings!).

Hot coding is not supported, you are right about that. It's something I miss too.

Vector graphics and bezier curves, I can do without them but it would be cool to have them. At least simple shapes like square/circle.

Yeah... You will have to fork out for a plugin in the Asset Store for that (that's both a blessing -there are lots of stuff in there- and a curse -you have to buy extra modules-). However, I don't know how many plugins will be compatible with Futile, so exercise caution...

I don't know if I can retrieve the color of a pixel into my code with perfect accuracy. (I save level data in the level image file encoded as colors)

I think you just import the image as a Texture2D and use get pixel.. Not sure, but there are functions for that.

Futile doesn't perfectly respect the pixels. An edge that is 2 pixels wide might end up 1 pixel wide in the game (look at the lives bar in the HUD of space worms). This isn't a super big problem for Rain World which isn't very pixel art-centric, you won't see if a perfectly white silhouette is one pixel off. But it's still very annoying, and might become a real problem with for example the level graphics.

Don't know futile, but this sounds as a pixel scaling problem. Are you painting your images pixel perfect? (is the resolution set so that every sprite is painted at it's exact size in pixels?). If not, that's the problem. If yes, you might have to implement a "snapping" feature so the visual representation of objects only moves by discrete, pixel-size increments.

If a graphic is shrunk substantially, it will invent edge smoothing colors despite the texture being set to "point". You can see this on the very small rocks in Space Worms. This can be avoided in all Rain World scenarios I can think of, but is still a very annoying flaw.

Mmmm. Are you premultiplying alpha? Setting the texture wrap to clamp? Hard to know what's going on without an screenshot. And yes, if you are scaling things, that's why you are getting the inconsistent widths on pixel lines, I think.

The game becomes HUUUGE! The code and the graphics of space worms are together less than 200 kb, still the published game occupies 147MB before compression and 15MB after compression. Whaaaat?

That's weird indeed. Don't know what's going on. Heart&Slash's first prototypes (with much more content than you have) weighted 80MB uncompressed.

Maybe I should try to make Space Worms work in Monogame as well - just to see if some of the above problems are absent there? Maybe someone can cue me in on that right away?

don't know Monogame, so somebody else will have to help here!

[dancing_dead]

space worms is a neat little project, haha. took me a while to get accustomed to controls (at first I thought direction keys changed the rotation of the worm, and up propelled it forward, but that wasn't the case, after all), but a fun little thing.

how did you store the game graphics? did you, by any chance, have massive white, empty spaces in the tilesets/spritesheets/whatever? 'cause it looks like unity compiled graphics to uncompressed texture format, where the final size is pretty much a function of the texture size, so even if you had 4096x4096 texture of nothing but endless white that would take only a couple kilobytes as png, as an uncompressed texture it might come out to the tune of, like, 60 megabytes. and such empty, uncompressed textures also compress extraordinarily well, so that's why you can get it a lot smaller by simple winrar magic (I once had a 150 mb debug project compress down to 300 kb thanks to this). that's the only size explanation that comes up to mind right now.

MonoDevelop is massively inferior to Visual Studio. I'm using an older VS2010 pro version (thanks, XNA), and coding in C# there already feels almost perfect, and I've heard about some magic features of the newer versions that makes it sound like the 2.0 version of Heaven. you can code stuff in Visual Studio, and get it to work in Unity, but I don't think you can get debugging to work in Visual Studio with Unity, but I have heard about people coding in VS, and using MonoDevelop just for debugging. Perhaps it's an area worth investigating...

Watching an instance is certainly possible, but it might be not totally real time like Lingo had going. I'm not sure if statically typed languages can even do that level of real time, but, in visual studio, you can "watch" any object you want and have it output all the parameters you want to you, but you have to pause the execution of the code to peek inside what's where (you can resume it after, etc. you can type the values of the variables in directly, too, and resume to see the changes immediately etc). The Unity functionality Juan mentioned sounds pretty good, but it's a custom Unity, not a default C# thing, imo.

Vector graphics/Bezier curves is a tricky challenge, you might need to roll your own custom vector renderer thing with a limited vector graphics subset or something (I hope you don't need, like, full Illustrator graphics specs support?), but with dedication and time, programming can yield the most wondrous results. Sorry, all I have on offer here is a motivational speech, which might be somewhat demotivating

Retrieving pixels with perfect accuracy should be possible. If it's for loading levels, it's a cpu thing probably, just investigate what can you do with the texture object, there has to be someway to get an array of colors, corresponding with the pixels, or something out of it.

Scaling issues - a rule of thumb with pixel art graphics - DON'T DOWNSCALE PIXEL ART. It'll look like shit, very little you can do about it, and most of what you can do is extraordinarily painful. If you do pixel art rotation, render the graphics at at least 200 or 300% zoom (2 or 3 scaling factor) or more, that way you should be able to perform rotations in the native resolution, and have each pixel be a neat little rotating rectangle. You can take a look at Hotline Miami to see how that looks, their sprites rotate and maintain the same "pixelishness" at any rotation. For retro pixel purists, this, of course, will not be good enough, haha, but your only other option there is drawing all the rotations by hand.

And if you're serious about wanting to try out Monogame, download XNA 4 and Visual C# Express 2010 (both completely free), and get cracking. You don't want to do actual development in Monogame, trust me, you only want to port the finished game to it.

[jonbro]

Hot coding is not supported, you are right about that. It's something I miss too.

actually hotcoding is supported, you just need to code in a way that supports it.

http://joolsadams.wordpress.com/2012/11/23/unity3d-live-code-reloading/

you basically need to make sure that all components (and the data they rely on), support unity's serialization system. that way, when the compiler reruns (which it does, even when the game is running), it is able to load all of the class instances back into the running engine.

I find that on the small projects I am working on it is more trouble than it is worth, but I suspect if I worked on another big unity project I would use it.

[jonbro]

oh, also, you should switch to xamarin (the new version of mono develop), I find that it is much more stable and faster. That is if you are on mac. If you are on windows I have heard good things about using visual studio for dev, but I haven't done it myself, and it requires some setup. You might want to try out xamarin just for fun though.

[Sebioff]

The Unity console is s**t - it's not in any way a stranger to just skip logging stuff whenever it feels like it. That could probably be circumvented by creating a custom logger that logs to a text file, maybe?

Yeah, I'm slightly disappointed with Unitys console as well. You could get a better one from the asset store, for example this one looks quite nice (havn't tried it, though).

Vector graphics and bezier curves, I can do without them but it would be cool to have them. At least simple shapes like square/circle.

I recently researched this, and the best option seems to be dynamically creating meshes for your shapes. It sounds a bit wasteful to create dozens of vertices for rendering a circle, but it's actually fine As long as you only want simple shapes like squares/circles/bezier curves it isn't very difficult to implement either.

(the private ones only show if you activate debug display in the inspector -upper right corner-)

Oh wow, I did not know this! Awesome!

[JLJac]

Thank you Juan and Jonbro for sorting out some of my concerns. Perhaps I'm a little too harsh at this point considering that I've far from explored all the options.

did you, by any chance, have massive white, empty spaces in the tilesets/spritesheets/whatever?

This could very well be it. I've located the weight to a file called "resources.assets", which points towards this explanation. Why does it bake everything together in an "assets" file that's much bigger than the original image file when it could obviously load a normal png just fine before publishing? Also, there is a way to load image files on the fly right, that's going to be super crucial for Rain World level loading.

You can take a look at Hotline Miami to see how that looks, their sprites rotate and maintain the same "pixelishness" at any rotation.

Hahaha this is literally the worst in my opinion  

Vector graphics/Bezier curves is a tricky challenge, you might need to roll your own custom vector renderer thing with a limited vector graphics subset or something (I hope you don't need, like, full Illustrator graphics specs support?), but with dedication and time, programming can yield the most wondrous results. Sorry, all I have on offer here is a motivational speech, which might be somewhat demotivating

This can be done? Maybe with a shader?

What is a shader, btw? Is it all in the GPU? Can I write one myself?

[Slader16]

I have no idea what a shader is, but I do know that you can write one yourself.

[JLJac]

Hehe I "can" also climb mount everest, but the question is, can I?

[Slader16]

Hehe I "can" also climb mount everest, but the question is, can I?

I guess you could climb mount everest...

[dancing_dead]

(1)Why does it bake everything together in an "assets" file that's much bigger than the original image file when it could obviously load a normal png just fine before publishing? Also, there is a way to load image files on the fly right, that's going to be super crucial for Rain World level loading.

(2)

You can take a look at Hotline Miami to see how that looks, their sprites rotate and maintain the same "pixelishness" at any rotation.

Hahaha this is literally the worst in my opinion  

(3)
This can be done? Maybe with a shader?

What is a shader, btw? Is it all in the GPU? Can I write one myself?

Regarding the 1, you might want to investigate unity for this, there should be settings for compression somewhere, but I'm not sure if this compression is entirely lossless, so it might not work for pixel art 100%. An obvious solution is to have your tilesets be all cramped, and cut out all the blank space from them etc.
I suspect the reason Unity does this is because it compiles all graphics to a lossless gpu format that is pretty much a bitmap, hence the "function of size".

2:
well, to each his own, I find it a legit solution for those on art or tech budget ^^

3:
and yes, you can write shaders, haha! shaders are wondrous little magic programs that get executed on the gpu, not the cpu. They are written in their own cute little languages, GLSL or HLSL (depending on whether you're dealing with opengl or directx), both are very C-like and most shaders are just math. there are 2 main kinds of them (well, more, actually, but that's for the modern dx11 and opengl4 programmer) - vector and pixel shaders, and each affect graphics at a different point in the graphics pipeline. vertex shaders process 3d geometry, pixel shaders process textures and output colors. I have had only limited experience with vertex shaders (and 3d), but pixel shaders have turned out to be surprisingly simple and fun, once you understand how they're limited technically (and unlimited creatively).
the only murky part about them might be the debugging, things can get weird there and the best debugging experience, imo, requires you to use some 3rd party tools in addition to all the other gamedev stuff you already got going.

BUT, alas, no, shaders won't be able to (directly) help you with rendering vector graphics. shaders are part of the graphics pipeline, none of which directly can work with vector graphics.

it'd be easier to think how you can go about this, if you shared how exactly are you using vector graphics here. iirc, you used them for some part of the animation?

[Noogai03]

Shaders are notoriously difficult to write, but they are BLAZINGLY fast and can do amazing things. Shaders wouldn't let you draw bezier curves within my fairly limited knowledge of them, though.

(I only know about HLSL so correct me if I'm wrong)

One major use for pixel shaders is for screen effects, like a morph or colourization or somethig like that - the pixel shader program is run for every pixel on the screen, and handles assigning the pixel the right colour based on texture coordinates. Vertex shaders do the same but handle the vertices of the models in a 3d game (and therefore are less used in a 2D game like rain world).
Normally, you'd have three (4x4) matrices, world, view and projection, which transform a point in game world co-ordinates to screen co-ordinates, and the vertex shader often handles transforming the points of the models by these three matrices.

Shaders are quite similar to C in syntax but have lots of quirks, one of the most noticeable being "semantics", which basically tell the GPU how to handle the data. For example, if you pass in texture co-ords to a pixel shader it might go like this:

Code:

[return data] pixelshader(float2 texCoords : TEXCOORD0, float4 position : POSITION)
{
//code
}

where TEXCOORD0 and POSITION are semantics. float2 just means 2-value vector, float4 is a 4-value vector. [return data] is a struct you define which holds the data you pass between shaders.

Also, shaders have an "instruction limit" - you can only have a certain number of lines in a function, but this is usually minor. Computers also support different "shader models", which basically tells you what things the computer's GPU can support (eg deferred rendering is not supported easily on some older processors)

sorry if I'm wrong anywhere, please correct any inaccuracies and hope this helps somewhat :D

[Juan Raigada]

No, shaders would work well (you can compute in a shader, so you could compute the curve) but seems overkill for your needs. There have to be easier options out there...