Tag: game dev

Unity 5 physics bug update

Posted on

Over the last week I also had a look at some of the Unity 5 physics bugs I mentioned in an earlier post.

It turns out the rigidbody freezing bug only happens when I modify a rigidbody’s mass properties (i.e. mass, inertia tensor etc.)  I was quite easily able to repro this in a very simple project, so I’ll send this off to Unity when I get a chance.

After browsing the Unity forums I found out that hinge joint motors not working is caused by the motor not waking up the rigidbody.  As a temporary solution, if you force the rigidbody to wake up every update, the motor works.  I also found I had to multiply my torque values by a factor of around 50 to get similar behaviour to that in Unity 4.6.

Velocity drives definitely aren’t working for me.  Again, I was able to repro this in a very simple project.  One for another bug report.

I haven’t had a chance yet to look at the hinge joint limit and OnCollisionExit issues, but I’ll keep chipping away at these next week.  I also noticed that my gears don’t seem to be working properly, sometimes the gears (particularly rack gears) get stuck.  I checked and the configurable joints I’m using for the gear constraints do still seem to be updated correctly, so I’m not sure what’s changed here.  I always was concerned I’d find some slightly different behaviour in Unity 5 with PhysX 3.3 that would unavoidably break the delicately tuned physics setup in my game, and this may be evidence of that.  Let’s hope not, more investigation required!

GearBlocks Demo 0.1.5557

Posted on

GearBlocks Demo 0.1.5557

GearBlocks

Well, my as yet unnamed game now has a title – GearBlocks.  It was quite hard to think up a name that summed up the game in some way, as well as being short, easy to remember, and not already in use.  In the end I had to just pick something and go with it!

Full vs. demo builds

I’ve now set up a simple build pipeline that lets me build demo or full versions of the game.  As I add more stuff to the game, this will allow me to easily exclude certain features or content from the demo.

Build versioning

Builds of the game are now versioned, and the version number is shown in the game.  This means I can release standalone builds of the game on a regular basis from now on, yay!

Phasing out the web player

https://dl.dropboxusercontent.com/u/157530041/GearBlocksDemo.html

For now the web player build is still available at the link above.  I think I’m going to stop bothering with it soon though, and just release the standalone version, as there are starting to be too many difficulties with it:-

  • The new save game system doesn’t work due to the .NET serialization problems I mentioned in the last post.
  • It seems getting the .NET assembly version isn’t supported due to the web player sand-boxing, and I need this for showing the build version in game.
  • For some reason Unity is now always building the web player as a “development build”, even when this build setting is turned off.

Playable build – updated

Posted on

Playable build – updated

Save game system overhaul

Over the last week I have completely reworked the save / load system.  Previously I was using Unity’s PlayerPrefs to save game state into, which was only ever a temporary solution.  The PlayerPrefs are only intended for small amounts of player settings data, not for save games.

Now I serialize everything into a single binary file per save game (into a local “SaveGames” directory).  This does away with the old fixed slot based system and allows you to name your save games and have as many of them as you want.

This works great for the standalone build, but the Unity web player doesn’t allow file IO for obvious reasons.  So for the web player I tried saving the binary data into PlayerPrefs (much like I used to do with the old save game system).  This works fine, however the .NET serialization I’m now using doesn’t seem to work in the web player (deserialization fails with a FieldAccessException for some reason).  I don’t have time to look at this right now, so I’ve had to disable save / load in the web player for now.

Unity 5 upgrade on hold for now

Posted on

This week I tried porting over to Unity 5.  It went pretty smoothly to start with, a few shader and code tweaks were required to get everything running properly, but nothing too bad.  However once I got things going I found some pretty fundamental physics bugs that totally break my game:-

  • Once frozen, rigidbody rotations can’t be unfrozen (positions are fine).
  • Joint motors, limits and velocity drives seem to be non-functional (at least when setting them from code).
  • The OnCollisionExit callback never seems to be called.

It’s a pity really, as I can already tell the physics performance is significantly improved (which I sorely need!), but for now I’ll have to stick with Unity 4.6.  Hopefully Unity will resolve these issues fairly soon.

In the meantime I’ll have to re-jig my task plan a bit, but it shouldn’t hold things up too badly.

Playable build – updated

Posted on

Playable build – updated

Over the past week I have continued working on the game design and project plan.  This has taken most of my time, but I have also made some improvements to the build.

Unfreezing / deselecting inside the terrain

Previously if you deselected or unfroze a construction while it was positioned inside the terrain, it would immediately be free to move under physics.  Due to the interpenetration with the terrain a massive impulse would then be applied, flinging your construction way up in the air, which was very annoying.  To get around this, for a construction that is currently interpenetrating the terrain, deselecting it will simply freeze it, and unfreezing is prevented until it’s moved away from the terrain.  Hopefully this will eliminate one of the big frustrations while building constructions in the game!

New parts

I have made some new assets for the electric motor and servo motor.  Note that the new servo motor is a different size to the old one, so this may affect your existing saved constructions.  I have also added 4 unit length beams.

Other than that I’ve done a few minor bug fixes and code cleanup.  Next task I think is to port over to Unity 5 to see how that goes, might be a big job, not sure yet.

Playable build – updated

Posted on

Playable build – updated

Minor tweaks

I’ve made some improvements to the way parts get serialized out to save games (I’m afraid this will break any existing saved games).  I’ve also removed all options for multi-player from the game.  The current networking implementation isn’t ready for prime time, and multi-player is currently on the back burner while I work on the rest of the game.  I don’t want to promise what I may not be able to deliver, hence the disabling of multi-player for now.

Game design and project planning

On the subject of what I hope to deliver with this game, I have been working on finishing the overall game design and planning out all the tasks needed, at least up until alpha release.  This has meant facing some harsh realities about project scope, as I’m the only one developing this game, I have to try and be realistic about what I can get done.

I have decided to settle on a fairly simple design consisting of two game modes, “creative mode” (basically the existing sandbox mode), and “challenge mode”.  This second game mode will have a series of distinct challenges that get unlocked as the player progresses, each challenge will require the player to build a particular construction and then use it in some way to complete the challenge.  My hope is that this will give the player a feeling of progression and will gradually ramp up the complexity of constructions they build.  Ultimately I also want players to also be able to create their own challenges and upload them for others to play.

This alone will still take me quite a while to build, so that’s why I have sadly had to cut out all the crafting, exploration and survival ideas.  I have also cut multi-player from the plan, at least until post alpha.

I have lots of ideas for challenges for the challenge game mode, which I’ll share as I get to working on refining them in more detail.

Playable build – updated

Posted on

Playable build – updated

Part material variations

I’ve implemented a system that now automatically generates variations of all the generic block / plate parts with a selection of different materials.  These materials are just test examples for now, and are not final.

image
image

To make this work, I had to change the part ID convention, so I’m afraid any old save games will no longer work!  The good news though is that this part ID change should more easily allow modding in the future.

Now that there are more parts available (and eventually I plan to add many more), it’s starting to make the inventory UI a bit cumbersome to use.  At some point I think I’ll change it so that you first pick the block size, and then pick the material from a sub-menu.  First though I want to port over to Unity’s new UI system before making any more UI changes.

Playable build – updated

Posted on

Playable build – updated

Slider rails

There are now some new parts in the game, and a new attachment type.  Slider rails can attach to blocks either with a rigid or with a slider attachment (you can cycle between these).  The slider attachment allows relative linear motion between two parts in one direction only.  This allows you to create sliding platforms, lifts, extending crane booms, and all sorts of other things!

Construction mechanic

I have also made some improvements to the construction game mechanic to make things work a bit better:-

  • The construction you have currently selected no longer collides with other constructions.  This prevents you from accidentally knocking other stuff around due to physics collisions with the selected construction.
  • After cloning a construction, it becomes currently selected.  It used to be that the construction would collide with its clone, causing stuff to fly around uncontrollably; this no longer happens.
  • You can now only detach parts from frozen constructions.  Given that you can only attach parts to frozen constructions, I think this behaviour is more consistent.