Just messing around in Unity - getting a half-formed idea out of my head and into a project file. The environment is from from the Urban Construction Pack and the car is the free Stockcar model. I'm not yet sure if I'll take this further but it's nice to get something up and running and just about to a playable state in an hour or so from thought to finish.
Noodling in Blender
Messing around in Blender... no real goal in particular except to practice with the tools. It's a long way from being finished but I did learn a bit about aligning objects and got a little more comfortable with the UI. I don't have the time, or the artistic ability, to get really good but it would be nice to get to the stage where I can put together some game assets that are a little more evocative of my intentions than a collection of primitives. I'm probably missing something obvious but I did have trouble keeping things in the middle. It's also not such a great idea to just drag out faces as it screws up the object scaling. Live and learn.
Tools - Blender
I'll never be an artist. However, it's often useful to have some ability with the various asset creation tools. Blender, being free, is a very good way to create some 3D assets to test out ideas and/or build up something basic. More experienced artists may well have access to something more professional like Maya, or 3D Studio Max. That's not to say that Blender is less capable though. For my needs, it's perfectly usable.
Creature - based on the Lynda.com Blender 2.4 Essentials course.
I've no experience with other modelling tools (beyond some dabbling with Sketchup) but, with my limitations in mind, and a bit of thought about how to approach it, I've created some passable assets to use as placeholders. I've still a lot to learn about texturing, and more advanced modelling techniques and it's possible I won't get there but that limitation is with me and not the tool.
The interface is a little off-putting but there is a lot of power there. Following along with a video tutorial helped to begin making sense of it. Being able to filter out the stuff I don't need broke that initial mental paralysis. Knowing how to get back to the default state was also a big help.
The tools I mostly need access to
There's plenty more to learn so I'll follow this up as I do more with it.
Unit Tests
In my day job I work with a large team of developers. Project demands often require a rapid developement schedule which often means low quality code gets submitted in order to hit a deadline; incurring technical debt. Now, regardless of your opinions on this, at some point someone will need to interact with that code. They’ll immediately have a few questions:
- What does this do? Does it look bad because it’s a workaround for something I don’t know about?
- Does it look bad because it is bad?
- Am I going to break something if I change this?
#1 is technically two questions but they kind of resolve to the same thing. Hopefully there’s a comment that provides the context but don’t count on it.
Here’s a place where unit tests are incredibly useful. With good unit tests, if you’ve identified the input and the result you can have a lot of confidence that the code you’ve written is not going to break in production. Sure, there are exceptions. For a start, like everything in programming, testing only covers the cases you thought about. It’s a good argument for keeping testing in mind when writing code as it encourages keeping your methods small and single-purpose. Even if you’re not writing tests up front you might have cause to later (or someone else will have to, and there are few things so fun as having to refactor someone else’s 500 line super method).
So you have the code you need to change. You need to know it won’t break after you make your changes, and if you’re fixing something it’d also be good to validate that it worked without having to try and repro some weird case within the app itself. So, identify the range of inputs and the expected results. Write the test cases. If you have a bug and know the cause the chances are you can write a test for that. Get the tests done up front and validate the existing code first. Now, fix and/or refactor the original code. You’re free to change it and you know your unit tests will give you an early warning that something went wrong without having to compile and run the whole app to get to the specific problem.
Unit tests are not a magic bullet. They are not a substitute for testing the app. They are another tool to help you be confident with your code.
Unity & Playmaker - Building a Keypad
Update: There's an updated version of this post, complete with source code and the full project here: http://www.stephen-gurnett.org/unlikely-objects/2014/11/20/unity-playmaker-building-a-keypad
I've been experimenting with Unity for making games and prototypes more quickly. One of the things I picked up in the recent Unity sale was Playmaker. When I first started out programming I wanted to do everything myself. I'm in two minds about the benefits of this. On the one hand, I learnt a lot of things (mostly what not to do but that is kind of useful as well). On the other, now I know those things I also know I don't have the time to spend on them.
I want to put together a quick project to provide as a little birthday gift to someone. It's little more than an animated card but I wanted to put some interactivity in there just to provide a little entertainment. It's also a good excuse to learn putting how to work with Unity (and Blender as well).
The view in game (debugging shows the state of the FSM on the Game Object).
The GUI is built from standard Unity components. The keypad is represented by the small box on the wall. When the player gets close enough it triggers automatically. This could be refined but works well enough for testing.
The Finite State Machine in Playmaker's editor window.
And here's the Finite State Machine (FSM) as depicted in Playmaker's editor. It starts in the 'Off' state. On entering the triggering state we progress to 'On'. This state handles drawing the GUI and also fires an event to the player controller to enter an 'interacting' state which freezes the player in place and enables the mouse cursor.
On pressing a number button a modified version of Playmaker's GUIButton class is called. This sets a string on a specified variable equal to that of the number of the button. We go to Error Check to see if the current value should be cleared, and, finally, append the number string to the code. On pressing OK we validate the entered code by comparing it to the correct version, and, if it's correct, we open the doors. We go to the Exit state from there so we can send an event to restore motion to the player and they can exit the area of the trigger. Once done, the FSM is reset and will trigger again if the player hits the trigger. If the code does not match, we update the display to show an error message and set a flag so we know to clear the display when the user presses another button.
There's some small improvements that could be made but, otherwise, this is working nicely. It's easy to modify and could be used in a number of places if required. Overall, it was a useful learning exercise and picking something slightly more complicated than a light switch forced me to learn a few different ways of using Playmaker.
Time To Try This Blogging Lark Again
Who knows if I'll stick with it but every so often the urge will strike. Same thing happens with social sites like Twitter and Instagram, though I find the signal to noise ratio a lot more bearable with Instagram so I tend to stick with it more. Perhaps I just need a better tool to manage the twitter environment - or just be much less self-conscious about what I'm putting out there. I don't feel quite the same way about a lengthy blog post. Perhaps it's because someone has to come here to read it instead of me pushing it out into a public forum.