I haven’t posted anything about my current project, mainly because I mostly worked on internal systems. But recently I needed a bit of a break and implemented some visual FX. The first I want to show here is a ‘simple’ explosion.
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.
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
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).
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?
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.
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)
I just realized I never linked to the test version of Void(). You can download it here, if you want. Some firewalls or anti-virus software will complain when you start the game, because it tries to install some dwmapi.dll, but sadly I have no idea what this is caused by. I haven’t noticed anything bad happening. But I also haven’t noticed any functionality missing from the game if that request is blocked, so do that if you want to be safe. If you want to be super safe, don’t play it.
I added the Smartbombs. They destroy everything on screen, but the player only has three of them. Typical SHMUP stuff, really. Anyone interested in the current state can download the game here. No install required, just an archive with an .exe and a corresponding data folder. Controls are pretty much standard: WASD or arrows to move, spacebar to fire, hold left shift to charge the main weapon, release to fire once fully charged, and c to drop the bombs.
I am currently working on a scene to replace the ship selection with. Buttons are lame.
Again I apologize for the lack of updates, but university and work leave me little time to do anything else. And there are so many games to play. The completely non-existent motivation to create levels for Void() doesn’t help either. But since you are my only reader, there are not that many people upset.
Anyways, one course in university is about Unity and while most peers don’t have much experience with it, if any, I can do a little bit more than just follow the tutors’ examples. The first project is meant to be a space shooter, and since I had some spaceship models sitting on my HDD for quite some time which were once meant for such a game that sadly never came to fruition, I decided to revive them and create the game I wanted to then (albeit now on my own).
Currently I have all three player ships implemented, completely with all their weaponry (except the Smartbomb). The weapons are all upgradeable, but the system to do that is still in the planning stage. I have yet to decide if I want the player to be awarded money with which to buy upgrades between levels or to have some items flying around in the levels that upgrade the weapons when collected. The missiles track enemies, but not asteroids, the asteroids will break up into smaller pieces when destroyed, but only once. The smaller pieces will not break up again, they just disappear in a puff of smoke. The asteroids also collide with each other (without breaking up) and their respective mass is determined automatically by their local scale to make the collisions behave more correctly, although I don’t intend to make this a celestial body physics simulation, so the collisions are not nearly realistic. After all I have to override the z-component of the resulting movement-vector and set it to zero to keep the asteroids in the correct plane. They damage the player (and enemies) when they collide with him and the damage done is their current health, which is also determined by their scale (so a hit from a small piece is much less severe than one from a big one).
Initially I planned to build the game for Android, since I got my hands on a basic Android Unity license when they were free a couple of months ago and wanted to learn how to do touch controls, but for some reason my machine doesn’t want to. I installed the Android SDK, the JDK (32bit and 64bit), all Android APIs since 2.3.3, but when I want to build, Unity throws an error. I have found that I can successfully build a game for a couple of minutes after a fresh Unity install, but after a short amount of time (roughly 15 minutes, didn’t measure it) the error is back. The error is independent of the project I want to build, when it happens with one project, it happens with all others, even empty ones. It is simply no fun to have to re-install Unity every time I want to update the build, so I shelved the idea for now. On the bright side this allows me to go overboard with particle effects and stuff. The first version I managed to build for Android was quite choppy on my device already.
And now, after the wall of text, some screenshots.
