nickavv

the daikon games guy

I'm an indie game developer, software engineer, and friendly fella. Always trying to learn/grow and be a good person.

--
click this thing for my games acct
Daikon Games


hthrflwrs
@hthrflwrs

man. what the hell do i even do now, engine-wise


hthrflwrs
@hthrflwrs

option 1: stick with unity. tank a moment like this every six months until one of them is actually directly harmful to goatgame's success
option 2: go back to starlight. spend the next year working on a game engine instead of the actual game in that engine
option 3: godot??? luxe??? something else??? meaning i'll have to spend even more time, both learning a new engine and porting everything over to a new engine... for a third time

no good answers here!! if anybody has any thoughts i'd be happy to hear em


nago-
@nago-

this is a genuinely ignorant question: are there any open source engines out there?

I know UE4 had source available but it is otherwise under a strict licensing agreement and it isn't free. I know Unity has random pieces somewhat uselessly open sourced. I don't know about anything else, really.


nickavv
@nickavv

Godot is the big open source option. I've played with it, seems pretty good, but obviously a long way to go features-wise from the big ones


You must log in to comment.

in reply to @hthrflwrs's post:

the best solution for me was a lightweight framework. i've been using ggez in rust (https://ggez.rs/) and it means i don't have to interface with filesystems or the graphics card, even if basically everything else is homegrown. but i'm also the kind of person who cannot, for the life of me, make a game in an editor-first piece of software like unity or unreal, and i'm also making a game (turn based strategy) where many of the conveniences of the existing engine don't really help game logic at all

in reply to @hthrflwrs's post:

Since it happens that friendship valley is a card game, I'd go hard on the mechanical parts and be careful to abstract those from the engine they are running in; then once everything works with static visuals and hardly any animation, either plug that into some other engine or finish Starlight, based on how things look then

(i guess it's a bit presumptuous to suppose you haven't got all the mechanics and writing done already? sorry)

here's the thing: writing and mechanics are implementation. things are changed by the act of putting them in the engine. the systems i use to create things are inextricably bound to the context of what creates them. the mechanics of the game may have already been decided, but i still gotta make the dang thing

It doesn’t super matter whether they do or not. part of the issue isn’t this specific thing, which is frankly unlikely to impact many small or hobbyist devs (you need a million installs AND a million annual revenue to qualify), but instead the fact that the time between making fucking stupid business decisions is getting shorter and shorter

If you're using Unity, Monogame is a good choice. Maybe don't switch mid-project but it's another C# engine, it only does 2D but you can build to most platforms. If you are switching mid-project, you know, your libraries will port over and stuff since it's the same language, so you won't have to get stuff finalized to build to DLL or anything. It's open source. Apparently Celeste is a monogame, uh, game. Celeste had 3D bits so either they faked it or it can do some 3D rendering.

Idk we're using it for college work next semester so hopefully it doesn't suck, I've never actually used it but switching away from C# is going to be more of a hassle than switching from one game engine to another since most of the work on a larger project is basically engine-agnostic anyways.

I switched my side project to Godot (full GDScript, no C#) about a year ago because Unity kept laying off my friends. I don't love the progress I lost, and my experience using the engine has been equal parts pleasant and frustrating as using Unity, so it was mostly a productivity hit for a sidegrade.

I haven't hit any hard walls though, and if I really need to look at engine code, I can. I also don't have to think about Unity's idiot investor bullshit!!

in reply to @nago-'s post:

I'll look into it! I write F/OSS for a living but I don't make games, but I've dabbled in engines here and there and... idk it'd be nice to contribute if I could large shrugging emoji guy

God speed dealing with unity's jackassification.

in reply to @nickavv's post: