Starting my own danmaku project, any advice?

[Reviire]

So, not much to say right now. But I picked up Unity 3 weeks ago, and after a little learning, 3 days ago I decided to start making my own little game. I have to say, things are a mess so far, but progress is being made I guess.

But I wanted to ask the more experienced people of you, are there any things you think are important/very useful to have in any game of this sort, in a programming sense? Maybe a way to store attack sequences/enemy spawning and behavior.

[Squire Grooktook]

Hi, and welcome!

Question: are you going to be using 3d graphics with Unity?

My personal advice is that if you're using a premade engine, Unity is workable but very slightly unwieldy and a bit of extra work if you're just going to be using sprites or 2d images of some sort. I personally recommend Game Maker (with Bzpbanshee's "gmosse", for starters, which can be found on this board) for a sprite based project, but there are other options of course.

The scripting stuff can be done in a lot of different ways, most of which are right so long as you don't get any of the bad kuso-game side effects (ie player sprite stuttering when it starts to move offscreen, bullet wobble, etc.)

How you do things probably depends on what you're going for. My game uses a system based on Dangun Feveron where extra enemy waves show up if you kill things fast enough, so I script stages based on dynamic timers and crap like that.

[Reviire]

Sorry about the late response, I got caught up with some real life stuff.

Yes, I'm using Unity, although I'm doing it in 2D with sprites and all that. Code is the thing I mostly deal with, art just isn't my thing, but I've basically only just picked this up, so while learning new ways to do things in general, specifics for something such as a bullethell, I don't know those either. I find it helpful being able to look at other peoples work, or just going over some code snippet with someone.

As for what I'm going for, nothing in particular right now. I'm just going through different things to learn about them, the goal right now isn't to have something sensible.

[Squire Grooktook]

I find it helpful being able to look at other peoples work, or just going over some code snippet with someone..

Another reason why I'd recommend Game Maker: besides being a bit faster for 2d sprite-based development, there are also several people here who are very well versed in it (Eebrozgi of Final Boss, BzpBanshee of Gmosse, Cagar of his various mods, Geist of Trigonometry Wars, and myself if I do so say so ^_^) and in using it for shmups.

[Reviire]

I find it helpful being able to look at other peoples work, or just going over some code snippet with someone..

Another reason why I'd recommend Game Maker: besides being a bit faster for 2d sprite-based development, there are also several people here who are very well versed in it (Eebrozgi of Final Boss, BzpBanshee of Gmosse, Cagar of his various mods, Geist of Trigonometry Wars, and myself if I do so say so ^_^) and in using it for shmups.

I had considered it, but I went with unity because it's in C#, and I thought it might be a better language to get a basic idea of.

[Sumez]

If you aren't afraid of doing a bit more custom engine coding (honestly, if you want to make anything good in Unity you're gonna have to do that with everything apart from the 3D rendering anyway) I think MonoGame is a really good framework that is also C#. It's based on (cloned from) Microsoft's "old" XNA Framework that they discontinued for inexplicable reasons (though most likely because there was no decent way for them to make money from it). It's really good, and a lot of great games have been made with it, such as Rogue Legacy, Towerfall Ascension, Bastion and a lot more I can't think of. I think Fez was even ported to it.

[M.Knight]

Maybe a way to store attack sequences/enemy spawning and behavior.

This thread has a a bit of discussion related to that question.

As you use Unity, I suppose you could have each enemy be a prefab with a behaviour script attached that controls its bullet patterns. Enemy movement can be placed in the enemy's behaviour script if all instances of this enemy are supposed to move in a similar way. (e.g. "moves forward in a single direction" or "rushes towards the player")

The enemy spawning itself should be done with a level manager IMO, which is a general script that handles the sequence of events within your level.

If you are new to game programming in general and are not familiar with the concept, look up Object pooling. This concept is very useful for shmup programming as you will reuse the same bullets/player shots/enemy instances instead of instantiating dozens of them at runtime, which can hurt performance.

[Sumez]

I get that object pooling is probably very useful in Unity, but if instantiating enemies or bullets in a 2D shoot'em up is a performance heavy operation, you're doing something wrong. Of course, with the C# garbage collector, any excess object constructor is potentially a problem.

If you're making hundreds of bullets with their own individual velocity in a C# project, you definitely want to pay attention to how you refer to variables in the RAM, which is usually a bit of a "dark art" in this type of programming language, since there are a lot of abstraction layers between your code and the actual memory management. You definitely want to learn the difference between a struct and an object (which is completely different from C++ where the two are almost the same)

[M.Knight]

Yeah, by performance issues, I was mostly referring to GC kicking in at unexpected moments.
That said, I think another Unity-related issue with on-the-fly object instantiation is the Destroy() call to delete the objects which can possibly be heavy in the long run, especially in a danmaku with hundreds of bullets.

[Sumez]

Yeah I can imagine even treating bullets like standard Unity objects (pooled or not) will produce absurd amounts of overhead. Of course, with the high end computers we have today you might not even notice, but I don't personally feel good about it.

[Squire Grooktook]

IMO

If you're scripting enemy movements and crap on the surface with a pre-made engine, you're not really at a level where your choice of programming language is really all that important. Unity with C#, Unity Language, or Java, Game Maker with GML, etc. all feel pretty much identical with very minor difference when you're just telling something how to shoot bullets and move around with all the core components of an engine (renderer, input polling, etc.) already done for you. I'm not sure if Unity scripting even lets you get into the "dark arts" if you want.

Only difference is you don't have to screw around with a ton of functions that were designed with 3d movement in mind when doing basic 2d movements in GM. I've heard a lot of developers say Unity is "overkill" for 2d sprite based game development, and I tend to agree.

I actually originally picked Unity because I wanted to write something with C++, and Unity's C# was the closest alternative. It should say something that I could not tell any difference despite knowing exactly zero C# at the time.

Now mind you, if you're half decent at programming, you can easily get past the minor roadblocks Unity has and do all the same shit. But it's extra work and time and won't result in a better game. Do consider if it's worth it for your project. The only reason I'd recommend Unity for this sort of project is if you want to become a professional gamedev, as I hear many developers are interested in people with experience in Unity/Unreal and such.

[mamboFoxtrot]

I guess I should mention Godot. It's similar to Unity, but is more 2D focused out of the box.
Last I checked it uses its own language, but I think C# scripting is being added soon, or has already been added at this point? I haven't checked.