Dungeon building

[BasiliskWrangler]

It's very problematic, and it hurts indie devs like us the most.

I'm not sure what we're going to do, just to "wait and see" for now. I'm hopeful that they will revise their policy, or maybe get bought by a bigger parent company that can manage the software better. Long term, if nothing changes, probably move back to Godot which I dabbled with a while back.

[Leezar]

Clickety clack

conversion.jpg (197.56 KiB) Viewed 762 times

Now of course, I am not a legal expert so maybe this method copies some propriety material or whatever.

Also, although I got a big fat F at the programming course I took way back when in my youth, I am still well aware that the biggest issue with making software is not the programming itself, but hammering out all the dents such as getting different blocks of code to work together without going Bethesda level of quirky.

None the less,..

I did make a hypercard game once (yes, I did have a PowerMac6100/60 and then an iMac), that I had to re-"program" into supercard. So, I also know that a lot of the hard work of consists of structure and story and purpose of the game etc. So, it's probably less work than you imagine to reimagine the game for Godot, even if you have to do it from scratch. Hell, maybe you can even finally get rid of that one messy and buggy block of code you have to keep using because other blocks depend on it and...

What I am trying to say - which may or may not have been successful due to my poor social skills - is; Keep you chin up, Basilisk! We all are counting on your next game to allow for a solid 40 h escapism from the pain, suffering and boredom of our otherwise bleak and mundane lives!

[Leezar]

Oh and also,

Probably rip off that bandaid quickly. Maybe they walk back their BS this time, but there will be a next time. Just look at Magic the Gathering. Controversy after the controversy, it's the gift that keeps on giving.

[MyGameCompany]

One of the major things I learned as a software developer for 25+ years is to compartmentalize things. I always built an abstraction layer on top of any third-party software that I used, and kept the main program logic completely separate. I never used 3rd-party types or functions directly in my code. That way, whenever a third-party package changed or became obsolete, I only had to retrofit a limited set of classes/functions and recompile.

It came in handy on more than one occasion. I worked on a program with 100+ software developers, and we were using .NET for our UI and OS interactions. We built an abstraction layer on top of it and kept .NET types out of our regular code. In fact, none of our regular code was managed code. Our program managers thought it was overkill and that we were crazy, until our customers demanded a UNIX version of our software. (They also demanded a UNIX port for a competitor's software package). It took of our competitor almost 2 years to port their software. We finished ours in 3 months by rewriting our low-level code to use Qt instead of .NET. That 3 months included research for alternatives, coding, and testing.

I continued this practice as an indie game developer too. Came in handy numerous times, like when I had to switch from DirectX to OpenGL to support Mac and Linux. Most of my code was unchanged. I only changed the few classes that directly interfaced with graphic, audio, and input functions, recompiled, and I was mostly good to go.

Granted, I don't know anything about Unity or whether that tip helps...

My mother-in-law always said, "Advice is only worth what you paid for it", so if it helps, cool. If not, I understand!