This is currently a thought experiment, but maybe it could be turned into an “IRL” experiment. Perhaps think of it as a “Godot Forums Game Jam”. If it works out (and even if it doesn’t), it might be a fun little event.
Most simply:
Invite a few or several members. Start when a minimum amount of participants accept.
Dictate theme, time limit, …
Provide common source repository
Chaos!
Profit?
I’m competent enough to play (I think!), and would, perhaps, have the same reservations as many of you (my time/effort is worth something). I tend to lurk, and post sporadically, so I don’t think I’d ever be invited…
…All the same, I’m just curious. Personally, even though I brought it up, I think the project would be a hot mess. Then again, who knows!?
I’m not sure what my motivation would be TBH. Every few months I do a game jam when I’m taken by an idea and need a deadline. Communication becomes wildly more difficult when multiple people are involved, and while Git is great, resolving conflicts in Godot merges is a bit of a bear.
Motivation? Expect it to fail - meet good friends along the way?
No one is an island.
TBH, you could bug-out half way through, but maybe meet someone else along the way that is worth following up with, outside the project. Consider the experiment as a filter. Every forum is flush with people looking for help with “the next big thang!!1!”. 98% of those are people who don’t have the skills or foritude to follow up: the “idea guys”
Or, you hit that jackpot, and the team punches out a “game”. It sucks, but is playable, Or, it’s awesome, and instead of submit the entry, keep it, publish on Steam, and, $$$.
Git gets it done. It’s the best-worst solution that I’ve come across (My previous life was managing source control systems). Managed appropriately, it isn’t the beast it can turn into. This is the ‘team’ aspect - I was an build-management, source control expert in a previous life.
Ok I have a question for you then. I have two branches with different fixes. Drag-and-drop of items works before I merge the branch that has that feature. When I merge them, the feature stops working. Right now I’m thinking my best solution is to just move pieces over by hand in the editor until it works the way I want, building off the new main. Thoughts?
The “hindsight is 20-20” answer is smaller, focused commits. This way, if a branch commit proves difficult, you can trace it to a specific commit. I’ve implemented (automated) systems that would work this way, and “blame” the commit (and developer) that caused the conflict.
If your commit history is granular enough, then moving pieces becomes easier - you can isolate the difficult change-sets, focused on what the intended change was.
This is always complicated by systems that write their own data, or embed it. This is why I always use external scripts in Godot. Godot isn’t even that bad: try integrating with (old!) Smalltalk systems!
If done methodically, git merges will mostly happen with no conflicts, or are obvious enough that merge choices are obvious. The code you see in the conflict should be cogent and relevant - enough to keep in your head.
Which merge conflict tool do you use? I like KDiff.
This is where the main/master branch is important. Work on two, or three, or fourteen branches, all fixes should fold into that common branch
If you have fixes that belong in main/master, then you create a focused commit for that one fix. Every other branch must merge that commit (from main/master) before merging back to main/master.
From what you’ve said so far, I think you have several “all-at-once” changes that need merging, and they may be intertwined. That will involve some pain (Sorry!).
I appreciate the thoughtful response. I was unclear. I do know all that.
My issue is I have main, and I have a branch off main with some changes. I’ve tried merging both ways, but Git is just smashing together everything, and I’m losing something. I use VSCode fo my diffing needs these days or VI. I’m old school. Sadly, the problem isn’t merge conflicts, but Git making poor merge decisions.
This is so appropriate to the original post: a team that cannot merge changes without difficulty: Chaos!
With one user, and one branch, merging to main, it should be simple (main ← your-branch).
I didn’t mean to suggest that you didn’t know any of that - I just won’t assume you do until you tell me.
Git doesn’t make poor merge decisions, it defers them. Is it happening where you have merges that perform with no conflicts/complaints, but your code stops working?
Despite the fact we’re all game developers, programmers, designers, and community members, we all have different lives, projects, mindsets, experience levels, and end goals.
We just so happen to congregate here because we have one thing in common: Godot.
I consider Slay the Spire to be one of best-balanced games ever to have been made, and probably in my top 10 games of all time… I could die happy if I’d worked on a game as good as that
As to your question, I guess the main limiting factors are budget and time. A great game doesn’t take much more than a great idea, but production value is expensive.
Million dollar studios spend thousands of dollars a day to produce crap. If you wanted, you could rip Slay the Spire code, remix, and publish. I’m sure some “not where I live” “studio” is doing that right now.
We wouldn’t need to rip the code, just clone the idea (which, really, isn’t original to Mega Crit), and sell it on Steam, GoG, all the walled mobile gardens, and make a mint, no?
It’s not the idea that makes StS great - it’s the fantastic variety of cards, relics, enemies, and other mechanics, which have been playtested and adjusted to perfection through thousands and thousands of manhours of effort. We don’t have anywhere near the resources to make a game in that league.
If the thought experiment is to end up making a profit, I think it would be best to develop a novel design that doesn’t require a lot of assets (to keep it cheap), and is relatively simple. If it’s good enough to be entertaining, and novel enough to stand out, it could potentially sell.
The thought experiment isn’t to make a profit - I’m sorry to have phrased it that way. It wouldn’t be a measure of success. I was thinking more along the lines of “worthy to be published” on sites that sell games, and having a game worthy of anyone willing to pay for it.
I think of the game “The Battle for Wesnoth” (try it!). You can get it for free, but is easily a $30-50 game.
Ig theres me with my game, although i changed the name, graphics and basically went about redoing the thing from scratch because my original version sucked
I dont think that many people are excited though, and i dont blame anyone; my current footage is terrible and outdated. (Ambitious project? Yes. Will it succeed? I have nooooo idea —everyone else will probably do a lot better than mine alone )
(apologies for the rant)
I personally think it is a pretty cool idea, i am not sure if everyone would be able to pull it off due to programming styles and whatnot, but it would be interesting to see.
I see this is as a strength. Someone is a master of state machines, another with ECS systems, someone else has wicked shader skills, and another with build/backend automation.
Ahh, i was referring to specifically in GDScript/C#—it can be kinda hard to work around a project with multiple people doing the code, but yes, with that in mind it is a large strength.
)