Unity

It’s again time to post about the current project going on at university. We are creating games for use with a custom controller. This controller has some unusual control devices, like linear and rotary encoders, as well as conventional input methods like buttons and an accelerometer. Also it is not very ergonomic. If you want to know more about the device, you can find informations and images here on the Chair’s website.

For my project I chose to create a tank game, but not the obvious control-each-track-separately-with-one-of-the-two-linear-encoders kind of tank-game, but one inspired by the all time classic arcade game Pong. Two tanks, one at each edge of the screen, move along a straight path ad try to shoot each other. In between is a city block, which can be used to hide from the enemy’s attacks. This cover is completely destructible and after a couple of minutes there are only two places to hide left, one on each side of the screen. Additionally there are some powerups to vary the gameplay a bit, like carpet-bombers, shields and cover-piercing railguns.

Initially I wanted to make this a two-player game, with each player using one set of controls on one single controller to steer their tank, but the placement of the rotary encoders, used for the rotation of the tanks turrets, made this impossible. The two players would interfere with each other, because they are so close together. So instead I chose to write a simple artificial intelligence and made this the purpose of the exercise. This A.I. is of course nothing sophisticated. It is a simple state machine which can switch between hiding, attacking, defending and collecting pickups. Each state uses multiple raycasts to  find the best position to hide or fire from, always trying to keep cover between the player and the enemy or finding the spot with the least amount of cover to fire through, respectively. And since it is so simple, it is really difficult to kill initially, since it seems to have perfect aim and always knows where to hide. Until you see through its simplicity, at which point it becomes nearly trivial. It can still land some lucky hits, but the player should be able to easily keep the upper hand.

A second, even simpler A.I. was used to control the soldiers trying to traverse the battlefield. They also use raycasts to detect obstacles, but then simply move up or down until the way to the other side of the screen is free again. When they are close to an enemy soldier, they try to kill each other.

To test the game’s mechanics without having access to the controller at home, I also created an alternative control scheme, using the keyboard. W/S to move up/down, A/D to rotate the turret, Spacebar to fire the main gun, Q for the small lasers and E to use your current powerup. If you want to try it, here you can find an alpha build.

 

Some time ago I created two models for inXile’s Unity Crowdsourcing Experiment. A turret and a bicycle. I am proud to announce that both assets were accepted by inXile and should be found in Wasteland 2, when it gets released. They can already be downloaded from Unity’s Asset Store (for free).

Download Link

Download Link

I also created a concept for one of the drones, but sadly haven’t had time to create the model yet and, since the deadline for the drone-batch is now two weeks past due and I will not have the time for at least two more weeks, it is doubtful if I will ever create it.

Since the practical course at University is finished, I now present you the final submitted state of the puzzle platformer. The single existing level is a bit short and the puzzles don’t really deserve that label, but it shows the assets and functionality. Once the level is finished, it will be loaded again.

Here is a screenshot:

And here you can download it.

After trying to wrap my head around procedural mesh generation in Unity for hours and failing repeatedly, I decided to use Unity’s Line Renderer instead of generating a real mesh. Besides being easier by orders of magnitude it also helps keeping the polycount down, while offering good visuals, although it seems to ignore most of my material’s properties. Not sure if I can get this under control. I kept the curves I calculated, and created an empty for each sub-Spline with a Line Renderer Component using the points calculated for the respective subspline.

Here is the finished code. Sadly it doesn’t have the instant feedback in the Editor anymore, but I had to remove the ExecuteInEditMode. The objects created weren’t cleaned up properly when returning from PlayMode. If I find a way to have both, I will update the code.

Read More »

For my current project I need some way to show the player which button does what. The easiest and way that doesn’t show too much or annoy the player is some wires connecting the buttons to their respective mechanisms. First I created some models, but I wanted more, so I decided to write some code to procedurally create wires between two objects.

I divided the problem into three smaller problems:

  • create a Master Spline between two objects that curves according to gravity (cosh(x))
  • create multiple sub-Splines that curl around the Master Spline
  • create the actual mesh by creating and connecting vertices around the sub-Splines

Read More »

I teased a bit about my current project in my last post about squishy bones in Unity, and I figured I should finally put some information up. It is the final project for the practical course at university, with the requirement of being a platformer. I decided to create a 2.5D puzzle-platformer-hybrid, starring a blob of jello (after attempting and failing to recreate a look I wanted to use for a short-movie once).

Read More »

Two days ago I wanted to get an animation using stretchy bones from 3ds Max to Unity. I tried to simply export it using .fbx, but when I played the animation in Unity, my character, a blob of jello, just waggled a bit, and didn’t squash or stretch. Yesterday I found a working solution, and I thought I’d share this here, just in case someone has a similar problem and finds this.

First a little warning, or two. This might not be suitable for complex rigs, for several reasons, one of which is the second warning: I will be breaking a paradigm here, that I usually adhere to almost religiously. As you might be aware (if not, you will be after reading the next few lines), you should never ever (ever) scale an object that you might want to animate at any point in the future, especially not non-uniformly. Scale only in edit Poly Sub-Object mode or use a XForm Modifier. If you scale on object level, you distort the object’s transformation matrix and all children will move/rotate in this distorted coordinate system. You can easily notice one problem, when you rotate a child of a non-uniformly scaled object. If you really have to scale on object level, always use Reset X-Form afterwards to reset the transformation matrix (rotation is set to (0, 0, 0), scale to (1, 1, 1); position is left untouched), even if you don’t plan on animating the object ever, just to be on the safe side. I try to avoid the pitfalls I know of here, but be careful anyways.
Read More »

Added two more enemies. A flying saucer that fires lasers in a spiral pattern and mines that are deployed in random minefields. These mines explode on impact (obviously) and can be shot down. Additionally, they are magnetic, so when the player comes to close, they start tracking him, but he can fairly easily move out of range again. Probably into the range of another mine, evil grin. Sometimes the last resort is a Smartbomb. Just like with asteroids, the player’s guided missiles will not lock on to mines, but unlike asteroids, enemies can pass through mines unhindered and enemy projectiles also won’t destroy them.

Lastly the spacecraft from the last post are now created in groups of five, flying one behind the other, just like in the good old days of SHMUPs. It is slowly getting crowded on screen. I might have to create real enemy patterns soon instead of just spawning them more or less randomly, to make it less luck dependent.

I updated the uploaded build, so you can try it and see how long you survive. Did I mention that I halved the players health?

Read More »

I added the first enemies. A stationary rocketlauncher that fires three unguided rockets in quick succession and a spacecraft that fires some lightning projectiles and moves in a sinus-shaped path. I initially wanted the rockets to be destructible by player projectiles, but they are to small to really be hittable, so I scrapped that idea. Only the laser was really able to destroy them and I thought that would be an unfair advantage. But they’re easy enough to avoid.

As a side note: I suck at texturing. Also I have some strange shading errors on the wings of the spacecraft. They are just visible in Unity, no such errors in Max. Have to fix those somehow.

Read More »

Last post for today. Now I have posted more today than in the last six months together.

I created a ship selection scene to replace the ugly buttons. Still untextured, but it works. I might add some GUI overlays to describe the current selected ship later. When you die in the game, you will be returned to that scene (currently without any transition, so it might be a bit disorientating). Arrows or A and D to cycle the ships, space or return to select. Same download link as before.

(Background music: Street Fighter II ‘Guile’s Theme (R.A.H. Mix) by Rayza, OCRemix.org)