Unity 3D shmup framework

This forum is for discussing shmup development, tools, engines and techniques.
User avatar
Posts: 76
Joined: Mon Aug 20, 2012 8:11 pm

Unity 3D shmup framework

Postby wondersonic » Fri Aug 24, 2012 8:59 am

Hi all,
according to you, what would be the requirements for a good shmup framework? Please put priorities/step order as well.

Cheers,
WS

User avatar
Posts: 76
Joined: Mon Aug 20, 2012 8:11 pm

Re: shmup framework

Postby wondersonic » Fri Aug 24, 2012 11:33 am

Oh, the goal is to start building a framework to ease shmup development under Unity3D.

Also, I'll use it for my own needs since my project starts to be not as well organized as I wish.

User avatar
Posts: 76
Joined: Mon Aug 20, 2012 8:11 pm

Re: shmup framework

Postby wondersonic » Fri Aug 24, 2012 2:33 pm

Seems the very first thing to setup is the camera.

This is the game object that allows to render the scene to the screen. So a scene basically always has (at least) one camera object.

It also has a property named "Audio Listener" that allows it to "hear" (musics, sound effects). So if you wish to listen music, don't suppress this component nor disable it (unless you wish to implement a PAUSE feature).

Now to setup the camera, you need to know how you shmup will look like:
  • pure 2 dimensions with no perspective effect
  • some perspective effect

2D:
In the first case, you'll also need which screen resolution you want. This is important to allow right pixel placement.
Imagine you want 640x480 resolution, then you must set:
  • The Z position property to -240 = - (480 / 2)
  • The Projection mode to Orthographic
  • The Size property (under Projection mode) to 240 = 480 / 2

3D:
In the second case, you must set:
  • The Z position property to -240 = - (480 / 2)
  • The Projection mode to Perspective
  • The Field of View property (under Projection mode) to its default value: 60

You can also add more components to the camera as image post processing effects (motion blur, lighting manipulation...) and Audio Source(s) which typically is(are) music track(s) (with the "Play On Awake", the music track will start just when the game starts).

It is considered as a best practice to tag the camera as "MainCamera". And as it suggests, you can have several camera per scene allowing complex scene rendering; for example, a 2D (=orthographic) camera which renders ennemies, player ship, bullets in 2D and which does not clear the screen (understand z/depth buffer), and another 3D (=perspective) camera which can render a magnificent 3D background like say mountains.

Generally, you will configure screen clearing using camera's "Clear Flags" property to Solid Color (color defined just under) or Skybox (shouldn't we speak of Spacebox instead?). Now if you want to have a background with say tiles, that's another story and you can fix this value to Solid Color only.

So in the framework, this can be a good idea to have already preconfigured cameras 2D/3D and in several pre-defined screen resolutions.


Note right now, that for scrolling implementation, the camera will move. This allows to place enemies in advance in the scene builder. (more on that later)

User avatar
Posts: 76
Joined: Mon Aug 20, 2012 8:11 pm

Re: shmup framework

Postby wondersonic » Fri Aug 24, 2012 3:52 pm

After that, there are Render Settings to setup.

This can be done using menu Edit>Render Settings or more easily using the new menu (thanks to the framework) My Schmup>Initialize scene.

Using this, the ambient color is set to: Color(30, 30, 30, 255), fog is disabled as well as sky box (this will be the default).

Note that each scene can have its own Render Settings. Also a game is generally made of several scene (~game level).

User avatar
Posts: 76
Joined: Mon Aug 20, 2012 8:11 pm

Re: shmup framework

Postby wondersonic » Fri Aug 24, 2012 4:31 pm

By the way, I'll need some beta testers ;)

User avatar
Posts: 76
Joined: Mon Aug 20, 2012 8:11 pm

Re: shmup framework

Postby wondersonic » Fri Aug 24, 2012 4:33 pm

And now, input are also configured in one menu click. I currently have only one set of inputs, but I can enhance it according to your wish or one can use the "Axes" defined and use it as tutorial.

See menu Edit>Project Settings>Input.

Explanations:
As there are currently no way to programatically modify the input Axes, I had to overwrite the configuration file with the one from the myshmup framework (a little dirty, but it works).

User avatar
Posts: 76
Joined: Mon Aug 20, 2012 8:11 pm

Re: shmup framework

Postby wondersonic » Fri Aug 24, 2012 8:51 pm

Here is the first alpha version.

User avatar
Posts: 76
Joined: Mon Aug 20, 2012 8:11 pm

Re: shmup framework

Postby wondersonic » Sat Aug 25, 2012 9:00 am

And next, what will you need?

This is an open question to you that will help me to prioritize developments.

I've got some ideas but I prefer your advice, since this framework is more targeted at you ;).

Site Admin
User avatar
Posts: 232
Joined: Thu Jul 26, 2012 2:32 pm
Location: Melbourne

Re: Unity 3D shmup framework

Postby monoRAIL » Sat Aug 25, 2012 10:09 am

This is a great thread wondersonic. I've renamed your topic "Unity 3D shmup framework" because I think we should aim to have many of these threads, one for each of the popular shmup engines. I already have a Torque 2D shmup template game that I often use for rapid prototyping or game jams which I will post in its own thread.

By the way, I noticed that your UnityPackage is called MyShmup - but internally it's called MySchmup, you should probably leave the c out to be consistent.
Also, what does the InputManager do? It doesn't appear to be a script or a scene object.

User avatar
Posts: 4
Joined: Thu Jul 26, 2012 9:47 pm

Re: Unity 3D shmup framework

Postby motorherp » Sat Aug 25, 2012 1:35 pm

I can chip something in when it comes to making shmups in Unity. One problem I've seen many people complain of when making danmaku style shmups using Unity is that the performance is lacking. This usualy comes down to two common issues.

Firstly is that Unity doesn't automaticaly recycle resources and people tend to waste a lot of performance by constantly creating and deleting entities, for example bullets or enemies. Therefore one useful feature to write would be an object pool, ie: a class which would pre-create a whole bunch of objects of a given type and handle managing which are currently free and in-use and correctly enabling or disabling those objects when they're needed or not. When a new object is called for the object pool would return you a free one from its pool rather than dynamically creating new ones, and similarly when an object is no longer needed it should be returned to the pool.

Secondly is creating a more efficient way to handle large quantities of bullets. The way I've seen most people handle bullets is to create a new entity for each individual bullet with each one having its own set of components attached such as a mesh, mesh renderer, collision shape, and custom script for handling the bullets motion and logic. The problem with this approach is that each component, and in particular monobehaviours, impose a performance overhead since they are written to be as general and flexible as possible. This isn't really a problem for complex entities which you have fewer of, the trade off for the added functionality and flexibility is worth it. For something as light weight and simple as an individual bullet however then the overhead from all these individual components adds up when you wish to have a lot of bullets.

What I'd recommend is that instead of having each bullet as its own entity is to create a bullet group entity which contains all your bullets of one type. That will require you to write your own mesh rendering logic and collision detection routines for bullets however, but if making a danmaku game then it should give you a good deal of performance back if done right.

Alternatively it used to be possible to abuse the unity particle system to create a pretty decent and quick bullet engine. Unity's particle engine has undergone a big rewrite since I last dabbled in that though so I dont know if its still possible but its certainly worth looking into.

Next

Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest