rand(seed, iteration)
without having to actually iterate.
I've been going through Unity's tutorials on and off and keep on meaning to really go back into it hardcore.I did the Unity tutorials back then and I thought they were great, and provided a lot of assets to practice with as well. The link I provided has some basic tutorials which I skipped because I already felt I knew that stuff. But it might be worth doing both. I dont feel like the Unity tutorials were bad by any means
That's a really awesome resource. Would you recommend doing this over the official stuff or doing both?
still searching for a random-access RNG algo.
I just need consistentrand(seed, iteration)without having to actually iterate.
not thrilled about Unity as a company now but I feel like I have so much knowledge invested that I dont want to change at this pointThe sooner you leave Unity, the better it'll be for you in the long run.
I have considered using Godot or Defold, but I'm not a fan of the scripting languages. I know it's possible to use other languages with Godot, but they don't have as much support. Right now I'm most excited about the development of SDL3 and I hope to make a game with that and Zig at some point in the future.this is sort of where Im at with sticking with unity
The more news of devs laying off staff at a very rapid rate, the more game dev sounds like a hugely risky endeavour.Yeah. Im trying to be realistic and just understand that even baby steps towards something is progress. I have a lot of time, and in the meantime my family is very comfortable financially.
Apparently the tech field is in a similar state.
So maybe super indy is the way to go, but wouldn't he a sure bet on making stable money.
Food for thought.
still searching for a random-access RNG algo.You should try to understand why this doesn't exist.
I just need consistentrand(seed, iteration)without having to actually iterate.
Bah, I just decided to roll my own.I'm messing around with plain old HTML/CSS/JS. You can do quite a bit in a browser itself these days.
You should try to understand why this doesn't exist.because the RNG reseeds itself with the last rand.
I tend to stick with a language (like C, C++, Rust, Go, or Zig) and a simple multiplatform library (like SDL, SFML, Macroquad, or Ebitengine). It takes me longer to actually make something, but I enjoy the coding aspect more than navigating the engine interface. It's easier to reason about performance as there is less abstraction and the games I tend to make typically end up as extended tech demos anyway.SDL3 is gonna come out in like 2200. I was able to implement the functionality I wanted from it in the time it sat on 38%. And that involved writing my own Ada bindings to OpenGL, lol.
I have considered using Godot or Defold, but I'm not a fan of the scripting languages. I know it's possible to use other languages with Godot, but they don't have as much support. Right now I'm most excited about the development of SDL3 and I hope to make a game with that and Zig at some point in the future.
I'm messing around with plain old HTML/CSS/JS. You can do quite a bit in a browser itself these days.After playing around with GameMaker back in the stone ages, my second round of attempts at gamedev adopted this strategy. Using the canvas element (which was pretty new at the time), I was able to put together something kinda decent--even if tiny--in just a couple of days.
because the RNG reseeds itself with the last rand.
I believe this is still accurate.The important part:
I believe this is still accurate.I always liked this one:
https://www.sandraandwoo.com/2012/11/19/0430-software-engineering-now-with-cats/
still searching for a random-access RNG algo.You know, actually, you could try perlin noise. It's normally used for textures but the algorithm can be defined for one dimension.
I just need consistentrand(seed, iteration)without having to actually iterate.
You know, actually, you could try perlin noise.that looks way more complicated than the jank I have now, and I don't think bitshifting is useful in js.
I've been trying to delve into the indie dev scene myself. I have to learn basically everything so it's a slow process. The part I still don't quite grasp is the coding part, even with Godot's default scripting language.Basic coding is not super hard but it does require a certain ability to do abstract reasoning and break down problems into parts that doesn't really seem to click with a lot of people. I dunno how much this will help you but maybe try (before writing any actual code) just taking the thing you're trying to do and try to describe all the smaller parts that come together to make that thing happen in just plain language. Can help make sure you aren't forgetting any pieces or doing extra unrelated stuff
I'm using Unity and don't plan on changing to anything else.Are you making 3D or 2D? I think this is the first time I've seen someone so concerned about the renderer in particular
Clients never know what they actually want , just what they don't like.And if you are a contractor/consultant, you get paid either way!
Basic coding is not super hard but it does require a certain ability to do abstract reasoning and break down problems into parts that doesn't really seem to click with a lot of people. I dunno how much this will help you but maybe try (before writing any actual code) just taking the thing you're trying to do and try to describe all the smaller parts that come together to make that thing happen in just plain language. Can help make sure you aren't forgetting any pieces or doing extra unrelated stuffIt's good advice, I think. I essentially get all the main functions in GDScript it's just stringing things together that keeps getting me. Luckily it does have some kind of guidance system though.
GDScript is another thing that gives me pause about GodotI'd prefer C# over Python.
I dont really know python and i dont want to learn a language that is specifically for one use
i hear it also supports C# but that integration is less than ideal?
I'd prefer C# over Python.If you want the fastest language thats not a pain to write in, you should be using Rust.
Working on a Faster Language is better overall for yourself and your programs performance IMO.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html
https://gamefaqs.gamespot.com/a/forum/e/eee36c38.jpg
Python is fairly slow compared to C# for similar tasks on the same hardware.
If you want the fastest language thats not a pain to write in, you should be using Rust.I'm a C++ guy since the old days, so I'll stick with that.
I'm a C++ guy since the old days, so I'll stick with that.I developed SharePoint in C# for 7 years, and Ill take Python over it or Java any day.
But I can understand why people like Rust, lots of internal safety mechanisms built into the language and is C & C++ adjacent and nearly identical in syntax.
C# should really be there to swat down languages like Python & Java.
Julia should eventually replace Fortran
I'd prefer C# over Python.reason I brought up Python is my understanding is GDScript is based off it, so picking it up would take longer for me compared to something like C#
Working on a Faster Language is better overall for yourself and your programs performance IMO.
Python is fairly slow compared to C# for similar tasks on the same hardware.
reason I brought up Python is my understanding is GDScript is based off it, so picking it up would take longer for me compared to something like C#If you understand C or C++, getting into C# should be cake for you.
I developed SharePoint in C# for 7 years, and Ill take Python over it or Java any day.What is it about C# that you don't like?
What is it about C# that you don't like?Too dependent on Windows and .NET.
If you want the fastest language thats not a pain to write in, you should be using Rust.yeah Rust is only a pain to compile in.
SDL3 is gonna come out in like 2200. I was able to implement the functionality I wanted from it in the time it sat on 38%. And that involved writing my own Ada bindings to OpenGL, lol.Right, I can accomplish what I want without SDL (or SDL2 + handling my own graphics subsystem) but I just like the user experience of simply sticking to what it offers. Handles all the multiplatform issues for me and will have bindings to multiple graphics APIs. Supposedly Apple will be dropping support for OpenGL, for example. All I want is the ability to write vertex and fragment shaders (compute shaders would be a great bonus) and have that work on multiple platforms.
Too dependent on Windows and .NET.You can always use Mono