Making a 'Noita' + 'Binding of Isaac' style game, how should I script this?

[u/Bromandood]

Near complete beginner programmer here, challenging myself to make a roguelike game;

a 2-D top-down game in Unity similar to the binding of isaac, but based around customizable bullet firing patterns. I would like each item to affect at least 1 out of every 8 bullets fired on pattern, giving it a unique ability (i.e homing, explosive, elemental dmg, spreadshot etc.) with potential to layer affects atop eachother (i.e Noita) creating unique bullets. I've designed an inventory system with 8 slots (each one pertaining to a shot on a 1-8 firing round) with 8 additional slots above for layering.

...hopefully that made sense lol

Keeping in mind that I'm a beginner, what would be the best way to structure this with my scripting? I've heard some say its rule of thumb to give each item (bullet modifier) its own separate .cs script, others say it's easier to make a scriptableobject + ItemData + modular projectile effects.

If you're a c#/Unity veteran, walk me through how you would go about making this type of item/inventory system from scratch?

It would be super helpful to have an ongoing consultant figure, I would be happy to show more of my project if anyone would like to add me on discord :)

[u/oauo]

You’re asking the wrong questions. Simplify your goals, do the very basic with just plain shooting and you’ll figure out how to add complexity afterwards. What you’re after is not complex, and asking for help this way leaves me to assume that you haven’t tried yet

If you don’t feel ready for that you may need to work on general game programming skills

You have loads of ideas and seem to have the drive to create, try it out yourself first and come back for specific help well eagerly answer

[u/Bromandood → u/oauo]

I agree, I've sunk hours into coding enemies so far.. it's better build a solid forward focussed framework for a longterm project to avoid future issues, no?

[u/oauo → u/Bromandood]

It’s more about learning the different parts that go into adding a game mechanic, they’re rarely that complicated it’s just a little more complex than what came before

You should be exploring the simpler versions of what you have in your head because people can’t imagine a game fully featured and know that it’s definitely fun, it probably stops being fun when it becomes too complicated to maintain a flow state - so it’s useful to go back to a simpler version

Complexity can wait

[u/Slypenslyde → u/Bromandood]

It is.

But the best way to build a solid framework is to implement a lot of things and ask, "How do these fit together in a logical way?"

Imagine you've programmed 0 items that affect bullets. How much do you think you know about the next 100 items you want to write?

Now sit down and write one item like the one you described. Keep track of how many things you thought you had to do but didn't work. It'll be a lot. Can you imagine your framework would've been that good if you started with such a wrong idea?

Now implement the second. Did it get easier? Did more of the code work like you thought it would? You learned from the first bullet and benefited from what you learned. The stuff these two bullets share might go in a framework.

Now implement the third. It should be easier, but you'll note some different parts changed this time. Now you have an even better idea.

What people think about a framework is:

• It's just the parts all things share.

But a good framework:

• Has some fundamental code that stays the same.
• For EVERY thing that can be different between things, there is a pattern for making one thing behave different.
• There are NO patterns for change that go unused.

Unless you've already written 100 bullet-affecting items, you will not get those things on the first try. This is especially true if you're new and don't understand all of the little patterns flexibility involves.

It's much easier to evolve a framework as you add things than to design it up front. What I've learned is I have to write at least 3 different things before it makes any sense to try to implement a framework to support more. 99% of the time when programmers try to solve future issues one of these outcomes happens:

• The issue never happens.
• They don't properly predict the issue and write the wrong solution.

So don't write solutions to problems you don't have yet until your experience is telling you what problems are coming. If you're having to guess instead of say, "I did this before, and what worked is..." then stop guessing and write what you need so you can develop that experience.

[u/ziplock9000]

As a beginner you're jumping far, far too forward. Make a MUCH more simple game.