Space Farm devlog 11

After a bit of a hiatus, I'm back with a fun post.  I'm making the Space Farm repo public!  Find it here:

Space Farm code!

The reason?  I'm pivoting away from my initial design towards more of a farming/ RPG hybrid that an actual game designer is helping me with.  Much of the code I've put together can be reused, but I'd like to save this little snapshot of Space Farm before I start tearing things apart to build RPG Farm.

I'm hoping someone somewhere will benefit from my code, as little as there may be.  To help y'all out, here's a features list:

• Basic 3D isometric movement (which I borrowed from someone else...) with grid-locked mouse interactions
• A limited-size inventory system with rudimentary UI functions
• Plants that grow over time, drop items when harvested, and can be reset to specific growth phases as desired
• A framework for a crafting system using JSON
• A work-in-progress "auto-farm" system where players can define a rectangular space that will automatically generate farmland (planting and harvesting were up next, but I don't think I got there yet)

I know I should stop being impressed by myself, but it sure feels like I got a lot done.  Hopefully in the near future I will add more, but so long for now, Space Farm.  May your spin-off actually turn into a complete game this time!

Extra details

Images: here's a link to the most interesting work-in-progress .gifs and images, gathered into one imgur album for easier access.

Demo: here's a dropbox link to a demo!  Please note that at this stage, I am still relying on the console output as feedback that things are happening as expected, so it might be hard to know what's happening without those logs.  Controls are WASD to move, , and . to scroll through your hotbar, Q to open and close player inventory (and close chest inventory, for some reason), left-click to use your selected item, right-click while mousing over a chest to view its inventory, and shift-right-click to put items into and out of the chest.  You'll need to dig up dirt and then both till and water it before seeds will grow.  Give the auto-farm a try by placing the skinny poles in a small rectangle!

Space Farm devlog 10

This update is all about plants!  I've been neglecting them since I felt like I got so much done last time I touched them, so here's a few much-needed features.

When I added seed bags, I had them default to a turnip plant, which felt like an appropriate first crop to add to the game.  Unfortunately, I simply hard-coded it to plant a turnip when used, so in this work session I changed the code to actually create the type of plant defined in the inspector window.  For some reason this changed the collision relationship between plants and their parent dirt block, so I had to redo a little bit of my code for detecting which block is being hit when the player clicks.  The end result is I can now more easily create a seed bag for each unique plant I add to the game.  Nifty!

In the process of working on seed bags, I went ahead and added plant prefabs to the Resources folder alongside the tools, blocks, etc I moved earlier.  I'm not entirely sure I needed to do this, however, as the seed bag is currently taking a drag-n-drop prefab input for which plant to grow.  I'm imagining at some point I'll rework this to remove the drag-n-drop requirements by converting the name of the seed bag into the corresponding plant name and attempting to load based on that new name, but that also seems a little unnecessary right now.  I'm putting it on the back-burner and will come back to it later.

Last but not least, I added some more functionality to the existing plant growth stages code.  Previously, after harvest every plant would just revert to the "just been planted" seedling state and regrow.  Now I can choose which growth stage a plant can return to after being harvested, if any.  This ended up being difficult mostly because I had forgotten how my old code worked.  I'm using four different variables to decide if a plant can move on to its next growth state: current game time (Time.time), growth stage time, growth start time, and elapsed plant growth time.  It's a little fuzzy in my head still, but the equation comes out to be as follows:

If current time > the starting timestamp + how long the plant's been growing + how long it should stay in this stage, then move on to next stage

When I tried to have a plant start in a new stage after harvest, the elapsed time variable threw me off.  When a growth stage is complete, the elapsed time variable is incremented by that stage's growth stage time variable.  For a while there, I had it programmed so plants were taking as long to grow from any stage as they would have from a seedling because I was using that elapsed time variable wrong.  It no longer needed to care about how much time should have elapsed to reach this stage, just how much time had actually gone by relative to the growth start time, which I was already resetting to Time.time after harvest.  As I'm trying to write this out, I'm realizing I can make this a little cleaner by combining the start time with the elapsed time to make one variable that's the timestamp of last growth:

Timestamp of last growth + how long it stays in this stage = timestamp at which it moves to next stage

Wish I had thought of this while I was working the other day!  I'll put a new task in my Trello board.  Thanks for being my rubber ducky, internet friend!

Speaking of my Trello board, I've made a new category I can drop cards into called "things missing art" so I can better see which tasks are pending which type of work.  A couple of my categories got pretty empty when I made this change, which helped me see what actually needs to be started next in a few places.  As a result, I've groomed a couple more features that I'll likely work on next time-- one for item and inventory management, and one for farming.  Yay!

Space Farm devlog 9

I've got some fancy gif progress shots for you this time!  For the past week, I've been working mostly on the GUI and inventory functions, and I think I've gotten a lot done.

First, the hotbar:

Woo, hotbar!  Now I can kinda sorta see what item I have selected for use.  Well, once I get more icons in, at least.  The code for this is a little hairy.  Specifically for the player's inventory, any time the inventory is updated I split it into two arrays-- one for the hotbar, and one for the rest of the inventory.  These two arrays are used solely for updating the GUI, so I don't have to do any weird swapping around when it's time to let the player move things between them.  And as the gif shows, everything gets visually updated correctly when you place down or pick up an item.

I've also started on functionality to let the player pick up blocks again once they've placed them.  Right now, the player can pick them up by hitting them with the mattock three times.  This one I'm kinda proud of-- I added a little "decay" timer for the counter that tracks how many hits a block has received, so they'll have to hit it three times in a 10-second window to actually pick it up.  This is in case the player just hits it by accident every now and then, like I am prone to doing in these sorts of games.

My future goals for item dropping involve an intermediary step, where the object is dropped into the world as a floating item the player can choose to pick up by either clicking or walking over it instead of just automatically cramming it into their inventory.  I haven't picked which method to use yet, but I'm leaning towards walking over to avoid adding too-specific of controls to the interface.  I'll have to sit down and map this feature out before I can really get started on it, regardless.

In addition to these features, I've done some light refactoring and code clean-up during the times when I want to work but can't really get anything big done.  I reworked my inventory manager class to hold an array of inventory items instead of just game objects, which improves readability by getting rid of lots and lots of "get component" calls everywhere.  I also did a little code review with a good friend who reminded me that lambda expressions are scary but also beautiful, so a few of my functions have been reduced in length by a good 75% or more.  There's still a few messy spots left to clean up, but they'll also be affected by the item dropping feature, so I'll wait and scoop them up with the rest of the carnage that will likely leave behind.

In the meantime, my "tech debt and bugs" list on Trello has had a few more cards added to it in the past few days, so I should probably get the more urgent of those knocked out before I really get going on any "big" features.

Space Farm devlog 8

Hello again!  I've managed to start squeezing in an hour or two here and there this week, which is abnormal for me.  Usually I end up only devoting a few hours of my weekend to Space Farm, if even that, so it's kinda fun to see repro pushes dated "34 hours ago" instead of "2 weeks ago".  Since I've made some little bits of progress here and there, I'll try to keep this update little.

I've finally added a seed maker machine, which has been sitting in my todo list for a pretty long time.  As the name implies, this machine will convert a crop into its corresponding seed.  Code-wise it's relatively simple-- I added a new prefab that copied my sawmill, named it accordingly, checked the necessary checkboxes to mark it a container that can process things, and then dropped in a recipe for turning turnips into turnip seed bags.  At this point I'm not sure if it should continue using manually-created recipes or if I can make it "smart" enough to grab the crop's itemID and convert that into the corresponding seed bag's itemID.  It seems like a nifty change to make, but I might want to have some crops that you can't make seeds for-- that will be a design decision for future Caitlin.

I also took a few minutes to add in support for multiple output items from recipes.  I had been putting this off because it sounded scary, but it ended up being pretty trivial.  Most of the code was already there but hard-coded to use index 0 of the output item list-- I just needed to add a for loop that would cycle through the entire list.  Took like 5 minutes.

On the topic of recipes, adding the turnip seed bag recipe showed me pretty quick that my fancy recipe loading code could only handle one recipe, not multiple.  As I subtly alluded to in devlog 5, I was not super confident about blindly copy/pasting code from a tutorial, so I half-expected to run into this very issue once I added a second recipe.  After a bout of clicking on the same Google results over and over but not understanding what I was reading, I realized the issue-- I was trying to treat the JSON data as an array of recipes, but I didn't actually define its class as an array, but rather one single recipe.

Hopefully the commented out code can help you see what I mean here.  Originally the top class was just "RecipeData" and contained the commented out code.  This meant that when I read the JSON into a RecipeData object, it tried to cram the file into one RecipeData object.  This works fine when there's only one in there, but the editor got really confused when it found more data in the file after that.  To remedy this, I updated the top class to be a RecipeDataList class, and had it contain a list of RecipeData classes.  Now I read the JSON into a RecipeDataList object and it's perfectly happy to do so.  Having a class that has a list full of other classes which also have two lists of additional classes each makes my pea brain hurt, but it seems to work.

After getting all of the above checked in, I realized that my codebase was littered with a lot of junk, such as old commented out code and todos that had long since been completed.  I took some time to hunt through my classes (with the help of Visual Studio's fancy task list window that will look for standard "to do" comments and add them to a list for you!) and tidied up.  It feels a little like busywork at this point, but 15 minutes here and there will probably save me hours of clean-up later on when I can't remember what on earth that todo item was supposed to mean.

Unfortunately I still have a healthy bit of design decision paralysis going on, so I'll probably continue on with the little tasks in my Trello board for now and play some games for "research" in the meantime.

Space Farm devlog 7

I've been putting off writing this post because I'm not super proud of my most recent progress.  It's pretty messy and I have pretty much no idea what I'm doing.  I'm talking, of course, about UI.

UI graphics are courtesy of Kenney NL who is doing a wonderful thing by giving dorks like me access to some really nice art.  Visit his site here.

Yep, that's my player inventory as of my last code check-in.  I only got this far after hours of trying to follow a tutorial video series (why are they always videos?!) but getting distracted by the dogs every 10 minutes.  Ugh, I'm stressed out just thinking about it.

It looks pretty darn funky, but it does a couple kinda neat things already-- it can load icons based on the item (or lack of item) in a slot, as well as display the number of items in the stack in that slot.  It can also be opened or closed via button press.  The UI element itself is made up of a couple layers of panels and then some prefabs for the item slots.

The idea here was to have one version of the element that could be used by all the inventories in the game, but I'm already finding design flaws in this approach.  I'll likely end up using this more as a template for future inventory screens, assuming I keep any of this mess at all.

In the meantime, I've been trying to sort out some overall game design questions I've left unanswered for a little too long.  I need to get something nailed down for a core gameplay loop so I can build it and see if it's any good, but there are a few different directions I could take this basic "farming game but in space" idea.  I just might have to go play some of my inspiration games for ideas!

Space Farm devlog 6

I'm not quite sure how frequently I should update this log, so enjoy a relatively short post while I try to figure that out!

As mentioned in devlog #5, I recently updated my prefab management process to allow for easier loading via script.  So for this work session I focused on cleaning things up to work in this new system.  Almost all of my prefabs are now in the Resources folder and renamed to use a standardized naming convention that I hope I won't decide to change again later.  The exceptions here were the things I'm not sure how I'm going to handle yet, namely the plants.  I'm assuming I'll eventually follow the same process I followed for items, but I'll save that for another time.

I found a couple interesting features of the Inspector pane during this reorg.  The good-- renaming and moving the prefabs in my Projects pane did not seem to break the links that already existed in the Inspector.  Hooray!  The bad-- I cannot for the life of me figure out how to reset just one field of a prefab back to the default I added in the code.  I can reset the whole thing, of course, but that's kinda overkill when I just want the "recipe name" field to update on my Sawmill prefab.  I struggled to Google the issue, as the keywords picked up a lot of similar-but-not-quite-matching forum questions.  However, the Sawmill is the only building that can craft things right now, so it's not exactly an urgent matter.

My Trello board is starting to fill up, and many of the old cards are tagged as "art" and "UI" tasks.  I'm still not sure how I ought to handle art-- hiring out sounds wonderful, but it's early enough in the project that really spending time or money on legit models seems a little silly.  I'll probably have to just keep suffering through my "I spent 30 minutes in Maya throwing something together" programmer art for the foreseeable future.

Space Farm devlog 5

Oof.  It's been a while since I've written a devlog thanks to 2018 being so... busy so far.  I got some stuff done before taking a break from Space Farm that I hadn't written about yet, so I'll go ahead and cover it here alongside the stuff I got done this weekend.

This post will give a brief overview of the new inventory system, how I'm going to start managing prefabs, and my work-in-progress crafting system.

Inventory!  This one is usually the stumbling block that derails my projects, but I managed to power through it this time.  I put together a relatively simple inventory manager class that I can just drop on any game object that needs to hold stuff.  As a companion to the manager, I've added an inventory item class that I'll be attaching to any object that can exist in the game and also in the player's inventory.  This means my manager can hold an array of "inventory objects" that have data about their quantities, quality level, stack size, and so on while also holding all the info I need to place that item back in the world.  Doing it this way required some elbow grease initially, as I had to go in and update all my prefabs to have both a world object class and an inventory item class, but it's been pretty straight-forward to use since that point.  It's helped standardize what's going into the inventory and reduced the "cast to this object" kinda code I had floating around everywhere.

My main gripe with my inventory manager at this point is that it has a lot of functions already.  I have functions for adding new items, removing items from a specific index, checking if there's already a stack of a specific item forming, checking if there's even room to add more items, and sorting the mess of items once they've been added.  And the weirdest part is when I realized I had all these functions but didn't have a means of taking a specified number of an item out of a stack, like it hadn't occurred to me while writing these other dozen functions.  I'm wondering how many more there will be-- I might have to come back and refactor this class before too much longer.

Prefabs!  I like prefabs now that I've figured out how to use them.  Unfortunately, it's easy to find yourself buried in prefabs when you're working on a game that will have a lot of different items, tools, and buildings.  As per my inventory changes, everything that appears in my game world is now a prefab with a world object class and an inventory item class attached, plus the other fun stuff game objects need to exist.  And any time I need to instantiate a new game object via code, I've been having to expose a variable in the inspector pane so I can drag-n-drop a specific prefab into a script.  This didn't seem too bad until I had more than one tool and realized I had to attach several prefabs to my player just to give myself the items I was trying to test.  I kinda pushed this problem under the rug until I got started on crafting and realized it'd be impossible to implement my solution with drag-n-drop prefabs everywhere, so I took to Google.  Luckily I found a relatively simple-sounding solution-- Unity has a Resources.Load function that can be used to load up a prefab by name.  It sounds like there may be some concerns about this method's efficiency, but it's an easy solution that I'll go ahead and use until I find something better.  It will take another round of changes to many of my scripts and prefabs, but the pain should be worth it if I can get crafting up and running as a result.

Crafting!  Yes, I decided to bite the bullet and start on the crafting system.  Like the inventory system, this was uncharted waters for me, and I'm pleasantly surprised I didn't run head-first into an iceberg.  I decided to use JSON despite being completely unfamiliar with JSON beyond knowing people use it for lists of stuff in Unity.  Luckily there's a Unity-sponsored tutorial on the topic that helped me get it up and running, so I created a JSON file to hold the crafting recipes.  Each recipe has an array of required inputs and their quantities, an array of outputs and their quantities, and a base crafting speed.  I'll be using the tutorial's nifty editor window class to add new recipes to the file over time, though I may need a more robust tool in the future.

To use the crafting recipes, I have a game object set up to load in all the JSON data at the start of the game so my buildings can simply request recipes by name as needed.  At the moment, I have buildings set up to check if they can make one of their recipes any time they receive an item, assuming they're set to automatically craft stuff.  If so, the code will check the building's inventory for all the items the recipe needs as input and make the new item if everything's there.  When I write it out like that it doesn't sound very complicated, but putting it together was a bit stressful-- I had to make some changes across a number of scripts before I could even really start testing the code I was writing.  Luckily there doesn't seem to be any goofy bugs... yet.  The next step will be to add more recipes and see if I can get a building to check more than one when an item comes in, so we'll see how that goes!

Space Farm devlog 4

Alrighty, time to share some more details about how I've been structuring my code.  As mentioned in the last post, I've recently added in a few tools the player can use.  I'm kinda excited about the way they're implemented, so first I'll cover the tools themselves, and then I'll describe their current implementation now that I've refactored a bit.  Disclaimer-- this feels pretty clever right now, but I'm more than willing to admit that it's an experiment that I might scrap for something better later on.

Tools!  What is a farmer without farming tools?  Right now I have a mattock, a watering can, and seed bags.  The mattock will be a multi-purpose tool covering digging, tilling, and chopping.  The watering can is, well, a watering can.  And the seed bag currently lets you plant an unlimited number of my generic testing plant, but in the future will come in a variety of species and max seed counts.

Ok, the tools themselves aren't super exciting.  But maybe the way I've coded them will be.  As seems to be standard practice for Unity, I have a player controller class.  Right now, this class handles all the button presses.  I currently have three tools, which means three unique functions.  But wait, I've already mentioned that some of the tools, like the mattock, will have different uses depending on what they're getting used on.  This could easily turn into a lot of different functions.  Cramming them all into the player controller would be a nightmare, and putting all the different uses for each tool into the tool's own code would be multiple smaller nightmares.

I've chosen option three: have the objects you act on be the ones holding code for what to do when they are clicked on.  I'll admit it, when I write it out like this it sounds more like a bunch of tiny nightmares scattered across my entire code base.  To try to prevent it from getting out of hand, I've started trying to keep the different classes to a minimum, but give each one a lot of options that can be used when making a prefab to create the unique game objects.

To illustrate, here's what happens if you click on a dirt pile with the watering can equipped: the player controller detects the click, and then tells the dirt pile you've clicked on to run its "get hit with the watering can" function.  The dirt block checks to see if it already has its "I've been watered" boolean set to true, and if not, it sets it to true.  If there's a plant attached to the dirt pile, it will be told about this new update to its watered status so it can start growing.  Essentially, the player's click was passed through every game object connected to the place they clicked on, and anything hit took care of managing its own reaction.

It can get a little hairy trying to track down the path an input takes (or is supposed to take but didn't!) but so far this method has been more help than harm.  I guess over time I'll get to see if my opinion changes!

Space Farm devlog 3

I've had a lot more free time lately due to the holidays, so I ended up getting some neat stuff done.  I also didn't stop to think about a devlog post until now, so I guess I'll put the small stuff in this post and the big stuff in another one where I can go into more detail.

I took a screenshot this time-- there's stuff to see! The green cube off in the distance is the cursor from my last post. I haven't really made any changes there, beyond tidying up the code. I tend to do a lot of writing lines in and then commenting them back out as I work through problems, so I had some discarded code to delete.

Working my way down, the cylinders are my first farm "buildings" which is the term I think I'll use to describe any structure the player places in the world, e.g. chests, machines, decorations. Right now these guys don't really do anything, but the player can put them down under the cursor by clicking.

The little brown squares are my dirt blocks. They have a few booleans on them to control plant growth-- whether or not the dirt has been tilled, if the block has been watered, and if it currently has a plant in it. Using the mattock, which I'll cover more in my next post, the player can click an empty space to spawn a dirt block, and then click the dirt block to till it. The player can also plant a seed in tilled dirt, and then water it (again, more on those tools in the next post). It sounds a lot fancier than it is, really-- just a bunch of if statements. I also got the game object to change materials when tilled, which really tickles my fancy for some reason.

Finally we come to the plants themselves. Here's where things get fun-- the plant class has an enum for growth stages, and each growth stage can have its own timer for how long to spend in that stage. In other words, my plants will visibly grow through multiple different stages! Right now I'm just scaling a capsule mesh, but in the future I'm expecting to swap out models as they grow. I might also add different requirements for the stages, like needing to be pollinated, fertilized, weeded, etc. We'll see how the design goes.

Space Farm devlog 2

Welcome back!  I have more Space Farm updates.  To help you navigate these posts, I've added a "space farm" tag that should bring up anything related to this project.  I'll try to add other useful tags as I go, especially whenever I include code snippets.

As I might have mentioned in the last post, this time around I worked on letting the player interact with the game world.  Since I don't really have a clear plan for the gameplay just yet, I figured a cursor might be a good start.  I created something similar in a tower defense prototype in GM, so I had already worked out some of the logic at some point in the past and felt it should be possible to make again.  Seems reasonable enough, right?

So I started with simply spawning an object called "cursor" on the map.  Like everything else in this game so far, it's a cube.  I put a translucent green material on it so it'd stand out a little better.  Life was good.

And then I tried to make it follow the mouse.  This was... not as easy.  As I'm sure I'll state a million times in this devlog, I'm not super familiar with cameras, especially in a 3D space.  So translating from screen coordinates to world location wasn't intuitive for me.  I've written the kinda code where it works but I'm not really sure how-- Unity's "screen to world point" function got me most of the way, but I needed to add some funky-looking math to adjust the received value to account for the camera angle.  Without this adjustment, the cursor would float off the ground near the top of the screen, but sink through the floor near the bottom of the screen.

After correcting this, I decided to go ahead and lock the cursor's movement to a grid, as well.  I figured one of the first player actions I'll add is placing things in the world, and as a player I always appreciate a placement grid so I can plop things down all willy-nilly and have it still look decent.  This should also theoretically make things easier to program later, as I won't have to deal with detecting multiple objects under the cursor when the player clicks.  The design document for this project is still pretty bare-bones, so I might change this later.

Even with all the Googling, I'm having fun.  I think next I'll start on the farming tools.  It's kinda hard to have a farming game without the part where you grow plants, after all!

Space Farm devlog 1

Howdy, internet people!  I've started a new game project, which I will call Space Farm until I come up with a real name.  If that working title isn't descriptive enough, Space Farm is a farming game set in space.  That's the bulk of the design document at the moment, to be honest.

I'll start keeping track of my progress here on my blog, partly to share with y'all and partly for my own convenience.  I'm a habitual note-taker and have found some of my old posts to be consistently helpful as I worked on GameMaker and Unreal Engine games-- hopefully this devlog will do the same as I get started in Unity.

A quick note on engine choice-- although I have a fair bit of experience in GameMaker, my last couple attempts at a project felt hindered by the development environment it provides.  I really wanted to start using the scripts feature as much as possible to make the code more modular/ reusable, but they didn't give me the level of control (or maybe flexibility?) I expected.  And so I tried UE4 for a while.  It seemed like it ought to have been a good fit considering how much I had played with UDK in school, but it just felt too heavy for this dinky little farming game.  Unity and C#, which I haven't really used before, will be my weapon of choice.  At least for now.

Ok, that's enough of a preamble-- let's get to what I've gotten done.  For this work session, I kept things simple so I wouldn't get overwhelmed by the switch to Unity.  First, and perhaps most importantly, I set myself up a repository I can save all my work to.  Right now it's just saving a copy onto another HDD on my computer, but since this machine likes to kill itself about once a year, I'll be considering better locations soon.

Second, I implemented a simple 2.5D camera and movement system.  Cameras are still kinda foreign to me after spending so long with GameMaker, so I had to do some Googling.  Some nice person on the internet had already posted their solution to exactly what I wanted, which might have helped a little too much, but got me up and running.  You can now move around the world in eight directions with the camera keeping you centered on the screen.  Fancy!

I went ahead and added some "dirt blocks" to the scene for fun.  They don't really do anything yet, but it's starting to look like something now.

That's all for now.  Like I said, trying to keep it simple at the start.  Next on my task list is interacting with the world, so that ought to be a little more complicated.

Game Maker Tip: Collision and Instances

Wondering why your collision code isn't working, despite the fact that your code is written exactly like the documentation suggests?  I was, too.  Five hours of my life down the drain, bashing my head against my keyboard in the hopes I'd hit the "fix my code plz" button we all secretly fantasize exists somewhere.  Bad news, I did not find this fabled button.  Good news, reading the docs until my eyes blurred did reveal this one snippet of information tucked away in the place_meeting function page:

#%&@#%

There it is.  "... this function can check... for collision... using the collision mask of the instance that runs the code for the check [because duh, why would the function itself let you decide?]"  Emphasis and commentary mine, of course.  I mean, how else would collision functions work-- by giving you a clear idea of what objects you're checking?  Or maybe the opportunity to set both objects?  Hah!  Foolish peasant, bow to the glory of the rabbit hole of obscured instancing!

Ahem.  Sorry about that.  Needed to get it all out.  To be a little more serious-- and hopefully helpful-- here's the problem I was having.  Since I love functions and want to offer both mouse and gamepad support for the project I'm working on, I decided to write a script to handle shooting.  The key press detection code is in the Player Object, and thus the Shoot script technically gets called by said Player Object.  So far so good, right?

However, I want to do some fancy shooting.  I made a sprite to act as a "cone of vision" that could be scaled depending on how much of a range the currently equipped weapon has.  So instead of shooting out a projectile, I want the Shoot script to detect any enemies that are under this cone and act on them accordingly.  I used the built-in place_meeting function to do this, as I remembered this function working pretty well for this purpose before.  Long story short, this did not work in my setup.  After much struggling, I finally realized that this place_meeting call was using the Player Object when it checked for collision with my enemies.  After some additional struggling, I figured out that this is the intended function of GameMaker and I had just glossed over the part of the documentation that stated this fact.

To be fair, it makes sense.  The place_meeting function only allows you to specify one of the objects you're checking for, so logically the code has to be getting the other object from somewhere.  Unfortunately, I would vastly prefer it not just assume the other objects is the one calling the function, and that the person writing the code is aware of this.  Clear code is happy code, after all.

Ultimately, I just added a with clause to the chunk of code checking collision and the issue cleared right up.  It also let me delete about 50 lines of code I had scrambled together trying to fix what technically wasn't broken, so now my code looks pretty again.  Hooray!

Senior Capstone: a Simple HUD or Screen Overlay in Kismet and Flash

Updated 16 June 2014

This tutorial covers a quick method of creating a very simple HUD or screen overlay using Kismet and Flash.  Assuming you have your image ready, this should take you about two minutes to put together.  You can use it as a starting point for a Kismet-based HUD if you'd like, but I'd recommend it as a means of prototyping or for simple screen overlays, as things will get messy pretty quickly.

A sample of what you can do with this method

Update 16 June 2014: Step Zero: prepare your UDK map

Thanks to commenter Glorius for pointing out that this does not automatically work right for the UTDeathmatch game mode, as I was using UDKGame for my project.  If you're using Deathmatch, the first thing you will want to do is hide the HUD that comes with it.  This is something that can quickly be done in Kismet, don't worry.  You just need the "Toggle HUD" node attached to an "On Level Load" node through the "hide" option, with the target set to "All Players."  Here's a picture of that for clarity:

Simple, but effective

Please comment below if this does not work for you for some reason.  It should not affect the pseudo-HUD I'm about to show you, but it should hide your ammo and map graphics if you're using Deathmatch and any other graphics from game modes that use an UnrealScript-based HUD.

Step one: prepare your image

In this case, I wanted a pseudo-HUD that would show the player how to equip the different items in their inventory once they picked them up.  My first draft was a sloppy .jpeg, while my final version (shown above) was done in Illustrator.  What program and file-type you use is up to you-- just make sure it's of the quality you want and something that will play nice with Flash.  I'm not entirely sure about scaling yet, so I recommend saving it at whatever size you want it to be on the screen.

Step two: making the Flash file

After you have the image ready, you'll want to drop it into Flash.  For this project I just went with their default canvas size, but you might want to alter it to be the right resolution or ratio for your image and game.  If you haven't used Flash before, you can just drag your image in from wherever you saved it on your computer.  Get the image place where you want-- again, for noobs like me, there are align tools under "Modify..."  When it loos good, hit "File > Export > Export Movie..."

This part I'm a little iffy about because my files derped when I moved my UDK environment to a different hard drive after the project was completed, so bear with me.  You'll want to create a new folder in UDK's Flash repository, which can be found at (wherever you put it)\UDK-(build#)\UDKGame\Flash  So you'll be saving your .swf files in UDK-(build#)\UDKGame\Flash\YOUR_FOLDER  Name the folder and file whatever you want, but avoid using whitespace in your filenames, as it can confuse UDK.

Step three: import the Flash file in your content browser

Hopefully you already know how to do this.  I don't recall it needing any special treatment, so just import it like you would anything else and save it in your project's package.  If you're not sure how to import things, open up your Content Browser and hit the "Import" button at the bottom of the window and then find the file.

Step four: putting it together in Kismet

This part is also pretty simple.  The logic is on level load, start up the "movie" we made.  Here's a diagram of the Kismet:

Yay Kismet!

In the "OpenGFxMovie" node, you'll need to use the drop-down bar to select the .swf file to open.  I just left all the other settings on default.  Now when you start up the game, your fancy screen overlay should show up!

Step five: polish and expanding the code

From here on, you're on your own.  Maybe you'll want to tweak the Flash file to look better, maybe you'll want to show and hide the overlay with a button press, or maybe you'll want to get fancier with the code and have it actually do something interesting.  My next little tutorial will cover how to put replaceable text into Flash files and edit said text in Kismet.

It's pretty hacky and doesn't do anything interesting on its own, but this is a very quick way to get something up on the screen without writing a single line of UnrealScript.  It suited my purposes perfectly, and I hope it'll benefit someone else out there as well.  If you have any problems or questions, please let me know.  It's been a while since I put this system together, so I might not have written the most precise instructions.

Happy deving!

Return to senior capstone scripting tutorial index

Guide: How to make Maya not blur the heck out of a pixel art texture

Updated 26 Jan, 2014

Hello again!  This is pretty much a more detailed copy/paste from this post about making pixel art textures for 3D models and using said models in UDK.  Since Googling my problem gave me three pages of useless information before I dug up the answer, I figured I'd write a fresh post specifically about this issue in the hopes someone else will be able to find it when they also Google the problem.  Luckily, it's a very simple fix once you figure out which option is messing things up!

Please note that I'm running Maya 2013, so I cannot say for sure this will help with older versions.

"Help!  Maya is blurring my textures so bad that my renders look like they've been smeared in Vaseline!"

This is because Maya is dumb and just assumes you want an ugly filter on any images you use in your shaders.  To remedy this, click on the shader you're using as your texture and follow its color node until you get to the image's settings.  At the top of these settings, there is an option called "filter type."  Set that bastard to "off" and you should suddenly have nice, crisp renders!

Default is "blurry as mud" it seems...

To get the same effect in your viewport, hit the "shading" menu in the viewport's options, click on the little box next to "hardware texturing," and set the filter there to "unfiltered."  Better?  Good!

Ooh, such a sharp texture now!

I hope this helps anyone who is looking for this information.  I'm not sure how I even managed to find it, honestly, as it was buried deep in an archived thread from a few years ago.  Now if you'll excuse me, I need to redo some truly terrible renders...

Updated 26 Jan, 2014  I cannot seem to find a good combination of settings in the render options that fit multiple resolutions.  For the above project using 128*128 textures, I think I just used Maya Software with "edge anti-aliasing" turned to the highest quality.  However, for my current project using 32*32 textures, Maya Software is leaving huge pixel-wide lines on the model, but Mental Ray is working fine with just about every setting I try.  I would recommend just trying them all until something looks good, unfortunately.  Let me know if you find a good "catch-all" rendering method!

Senior Capstone: Reveal

Hello again, internet!  After much hair-pulling and confusion, I was able to package my level into an .exe that actually worked!  I present to you the end results of my senior capstone project:

Project introduction

The actual level

An imgur album of work-in-progress and final screenshots

A fly-through video of the finished level

Overview of the art style and pipeline

Overview of how I made the HUD

Senior Capstone: Pixel Art and UDK

Updated 20 Nov, 2013
Updated 7 Jan, 2014
Updated 26 Jan, 2014

Some people consider Minecraft to be an ugly game.  I, however, am fascinated by the way it combines a 3D world with 2D pixel art.  In fact, I love that combination so much that I decided to try to implement it in my capstone project!  This has been a bigger pain in the neck than I could have possibly imagined before I started, so I would like to share some of what I have learned so far.  Please note that I am still developing this process, so your results may vary.  I will be sure to update this post as I glean new information, and mark said updates as best I can for anyone who might wish to revisit this post.

This guide covers implementing pixel art textures on low-poly, blocky models that have been made in Maya 2013, textured using Photoshop CS6, and imported into UDK.  I have not tried this process in other programs, so I cannot say for sure it is universally applicable.  If anyone is willing to give it a shot in traditional indie tools like Unity or Blender, please share your results!

An example of my current results can be seen below.  I also have an imgur album going which I will update periodically, for those who might be interested.

WIP screenshot from 4 November 2013

Part One: figure out your scaling

Scaling has probably been the biggest source of confusion for me.  Without approaching it carefully and methodically, you will end up with a mess of textures that don't appear to have the same sized pixels or are inexplicably blurry.  Trust me, I know from experience!

To get started, it's important to understand (or in some cases, establish) the relationship between the units used by your various programs.  Luckily, units in Maya and units in UDK scale one-to-one, so there is no real guesswork there.  Using these two programs together means you simply have to choose the size of one "pixel" in relation to this scale.  To keep things simple, I just went with a 1:1:1 ratio, meaning one pixel equals one Maya unit equals one UDK unit.  Easy enough, right?

Keep in mind that the default UDK player is 96 units tall as you begin designing and then blocking out your environment.  Make everything a power of 2-- or even better, divisible by a certain power of 2, like 16-- to ensure your models and textures will all be uniform.  Below is an example of the scaling of the player and a couple key meshes.  Precise diagrams will potentially save you a lot of time, but making a couple rough meshes and textures to see how things fit together is a good place to start if you're not sure what you want yet-- things look ridiculously huge in my diagram, but actually look and feel comfortable when implemented.

This is why I stick to pixel art, by the way

Part Two: modeling within your scale

Once you have a decent understanding of what size to make an object, you're almost ready to model.  Remember how earlier I said it'd be good to pick a specific power of 2 number to use for division?  This is where you'll first use that number-- I'll call it the scaling number for reference.  The best scaling number is one that makes it very easy to accurately model your object when snap-to-grid is turned on, but can also be used to the same effect with as many of your models as possible.  I highly recommend choosing such a number and just designing all of your models around it-- 16 has been working well for me, but your needs may differ.  Divide your width, height, and depth by this scaling number and write those results down.  If any of them aren't a whole number, you either need to adjust your design to fix it or choose a new scaling number.  Fractions kind of defeat the purpose of using snap-to-grid, after all-- you can get away with the occasional half, but whole numbers will make things less painful.

Use your calculated width, height, and depth to model the object.  Stick to the grid with every change you make.  Inserting and edge loop?  Align it to the grid.  Extruding something?  Align it to the grid.  Mending meshes together?  Align that seam to the grid.  It can be tedious at first if you're used to the freedom of organic modeling, but the blockier the model, the easier unwrapping and texturing will be.  That being said, you don't need to be overzealous with dividing your surfaces into grid units.  If your 4-units-wide object doesn't need inner edge loops, take them out.

Below is an example of one of my objects, a torch.  In-game it is only 32 units tall, so I used a scaling number of 4 to allow me to actually add some detail to the model.  Note that each piece aligns with a whole number of units in the grid-- the top piece is 2 tall, the middle 2 tall, and the bottom 4 tall.

Note that the top does need to be completely divided, but the side doesn't need as many
horizontally-running edges, thus they were omitted.

When you're done modeling, don't forget that you need to move your pivot and rescale your model.  For the pivot, I recommend placing it in a spot that will make it easy to place the object within UDK.  The pivot on this torch is kind of arbitrary considering the way I'm using it.  For my pillars, however, I placed the pivot at the bottom corner of one side, placed in such a way as to ensure snapping it to the grid in UDK will make the bottom meet my floor.  After you place the pivot, snap the entire object to the very center of your grid.  Then scale it on all axes by your scaling number so that it will become the size you want it to be in UDK.  I've been exporting my models as FBX files-- if you do, too, make sure that "smoothing groups" is checked in the export options.

Finally, import the model into the UDK editor.  If you need to make changes, updating the model is as simple as re-exporting it, right-clicking on the mesh in the Content Browser of UDK, and selecting "re-import."  We will most likely be using this extensively in the texturing phase.

Part Three: how the hell do I texture this thing?

This is the part of my overview where I still do things wrong from time to time, so please bear with me as I revise the section for clarity.

Remember that magical scaling number I keep carrying on about?  This section will make it clear as to why you might want it to be consistent for every model you make.  However, it may also confuse you as to what this number actually means, as it seems that our assumption that 1 UDK unit equals 1 Maya unit equals 1 pixel was not quite accurate.  I'll try to explain as best I can despite not fully understanding it myself.

Using our assumption of a 1:1:1 unit ratio, our scaling number becomes the number of pixels wide and high each unit square in Maya is equal to.  Below is an example using a pillar.  The background is a grid of 8 x 8 pixel squares in a 256 x 256 image.  In-game, this pillar is approximately 64 x 64 x 256 units.  I used a scaling number of 16 when modeling it, so I modeled it as a 4 x 4 x 16 and then scaled it up when exporting it for UDK.

Using the entirety of your UV space doesn't really work when you want things
a uniform size.  That's my story and I'm sticking to it.

If everything is 1:1:1, shouldn't one square on the grid be 16 x 16 pixels-- in this case, a 2 square x 2 square chunk of our grid image-- considering our scaling number was 16?  I thought so too.  Unfortunately, BSP seems to use a different scale, where each unit is only 8 x 8 pixels when compared to my 16 x 16.  In other words, pixels seem to appear twice as big on BSP as they do on your meshes.  If you're not using BSP, this is pretty much irrelevant and you can continue along your merry way without worry.  If, like me, you are using it, you just need to decide which way looks better to you.

To continue my explanation, I'll choose the scaling number 16 to be the correct representation of how many pixels high and wide a Maya unit square should be.  Open up Photoshop and make a grid image like the one shown, except using 16 x 16 pixel blocks.  Use this to scale your UVs so that each Maya unit square aligns properly with a square in said grid image.  Below is an example using a sconce.  In UDK, it is 64 x 48 x 64; using my scaling number of 16, it became 4 x 3 x 4 as I modeled it in Maya.  Each square in the grid image should be 16 x 16-- here it's 8 because I was doing it wrong and didn't realize it until I had figured out the inconsistency I discussed in the previous paragraph, so just pretend it's 16.  I modeled it as a series of Maya unit cubes since the design was simple.  Since our scaling number says each of those units should be 16 x 16, we needed to scale the UV map so that each unit matched the squares in the image grid, like so.

These UVs will be twice the size when I revisit this mesh, as I was scaling incorrectly-- the image grid
uses 8 x 8 when it should be 16 x 16.

If you run into a situation where your scaling number is different for a certain mesh, you'll need to keep this in mind while adjusting its UVs.  For example, the torch had a scaling number of 4, so each of its Maya units are 4 x 4 pixels.  Compared to the sconce above, where a Maya unit is 16 x 16 pixels, the units are 1/16 the size.

The sconce is on the left, and the torch on the right.  The torch UV is a fraction of the size of the
sconce UV, but the pixels in the end result appear the same size.

You may have noticed that I'm overlapping a lot of UVs here.  With some of my meshes, this will be necessary to ensure everything can be scaled properly.  With others, it's to save me time when I actually make the texture.  This is one of those decisions that depends on what suits your needs best.

When scaling and aligning to the grid image, be careful of the edges.  They should fall as precisely between each square as possible, or else you risk having the edges bleed a little because they'll be encroaching on additional pixels.  This is where UDK's ability to re-import a mesh with a couple clicks becomes very useful.  If your texture doesn't look quite right in your UDK preview because a UV is slightly askew, you can fix it, export the changed file to save over the old one, and then re-import it pretty quickly.  I did this a dozen times while working on my torch texture, as its parts were too small for my grid image to be useful and I kept misplacing the UVs.

Updated 20 Nov, 2013  I have discovered a way to make aligning the UVs a lot more precise.  Thanks to this tutorial on lightmaps from World of Level Design, I was able to set my UV editor grid to actually do something useful and represent pixels.  This information is at the bottom of their tutorial.  Once you have a pixel-sized grid set up, you simply need to snap all your UV edges to said grid.  If you used square/blocky models like I did, this will be super easy-- you can resize everything just by snapping instead of trying to uniformly scale all the UVs in one go.  Nifty, eh?  I'm still getting the occasional edge bleeding, but I suspect this is inevitable with UVs.

Updated 26 Jan, 2014  So it turns out that while snapping the UVs to the grid gets you most of the way there, snapping to pixels is actually an option in the UV editor and it seems to take you the rest of the way.  Once you've sized everything properly using the above technique, come back through for one more pass, this time with "snap to grid" turned off and "pixel snap" on, like so:

Note that "pixel snap" is inside the UV editor window

Once you have the UVs aligned so that they won't chop any pixels in half, you can save them out for use in Photoshop.  If you haven't already, don't forget to export the updated model and re-import it in UDK, or the UV mapping won't be there.  Here it is also important to pick a resolution that won't require stretching.  For example, I have one large mesh that is nearly 512 x 512 units.  Using a texture on it with a resolution of 256 resulted in blurry pixels because of the way the texture had to be stretched across the mesh.  However, the rest of my meshes so far have been fine with textures of a 256 resolution, as they are all 256 units or smaller along their 3 axes or have UVs that can be arranged to fit a 256 comfortably.

Hopefully I don't have to tell you how to use Photoshop.  Just give it a lovely pixel texture and save it out.  I am still not sure what the best file type to use is.  Some textures have looked fine using .TGA at 32 bits/pixel, but others suffered from noticeable artifacting that only went away when saved as a .PNG with no compression.

Getting the texture into UDK is just as easy as with any other.  There is one setting you need to change on each one, however.  Double-click on the texture in your Content Browser to pull up its info menu.  The option labeled "filter" needs to be set to "nearest" to prevent it from making your pixels all blurry.

The only setting I have messed with so far.

With a little luck-- and if you're clumsy like me, a lot of cursing-- you should now be able to add the texture to your model using a material and then step back and admire your handiwork!

A quick note on particles

I find particles to be a lot of fun, so I can't imagine skipping them in this overview.  Pixel art particles don't take much more than regular particles, really-- just remember to set the filter to nearest on the texture and you're good to go.  I personally have been using .PNG files ranging from 1 pixel to 8 x 8 pixels, adjusting the size as needed within the particle effect's options menu to make it look pretty.  If you haven't made a particle effect before or need a refresher, this really brief video series covered everything I needed to get a fire particle up and running.  My "flames" are just a tear-drop shaped red-orange-yellow thing and my "smoke" is just a 3 shades of grey block.

Simple yet effective, I'd say.

Wow, this was a long-winded post.  Congratulations for those of you who made it through.  I hope this helps someone out there get some awesome-looking pixel art into their UDK project.  If you have questions or comments, please let me know!

Updated 7 Jan, 2014  Rendering these models in Maya

If you've tried to render any of these models in Maya, you may have noticed that they are horribly blurry no matter what rendering settings you try-- in vain-- to change.  This is because Maya is dumb and just assumes you want an ugly filter on any images you use in your shaders.  To remedy this, click on the shader you're using as your texture and follow its color node until you find the file settings.  At the top of these settings, there is an option called "filter type."  Set that bastard to "off" and you should suddenly have nice, crisp renders!  To get the same effect in your viewport, hit the "shading" menu in the viewport's options, click on the little box next to "hardware texturing," and set the filter there to "unfiltered."  Better?  Good!  (I now have a blog post dedicated to this problem-- click here to see some diagrams showing where these settings are!)

Senior Capstone: Project Introduction

Hello again, internet!  It's been quite some time since my last post, but this time I was actually doing something useful between then and now.  That "something useful" is the focus of this post!

This is the final semester of my undergraduate career, thus the semester in which I'm to complete a senior "capstone" project that shows off all the fancy things I've learned in the past four-and-a-half years.  As I hope to eventually become a video game programmer, I wanted my project to focus on programming for a small game.  Believe it or not, the majority of my hands-on school-induced programming experience has been in the Unreal Development Kit, so I approached the professor who had taught me how to use it and asked him to be my advisor.

Our discussions led me to decide that the project should be a short level for an adventure game.  I had those old Flash-based point 'n' click games in mind when I started, but the idea morphed to include a more modern 3D experience, using a first-person camera and allowing for free movement throughout the entire space.  Navigating through the level consists of picking up and using items to solve puzzles.  At this point, these puzzles range in difficulty from putting an object in a certain place to comprehending a logic-based riddle.

My initial level design had a vague, needlessly open layout, but the puzzles I came up with gave me a good start for my revisions.  I haven't actually taken my school's official level design course, so the design I landed on isn't exactly a work of art.  However, my advisor said it would suit my purposes well enough, and I didn't want to argue-- after all, I was more interested in getting the Kismet together than anything else when I started.  Below is the sketch of my general level layout.  For those of you who aren't experts at deciphering scribbles, the map consists of three different ground heights, a few buildings, a few underground passages, staircases in varying states of disrepair, and a player path that sort of resembles an ampersand.  At least, the sloppy way I draw them.  The overall goal is to light the four magical beacons so you can enter the chamber of... erm, something.  I haven't quite figured out the details of the story yet.

This is still pretty accurate, actually...

The level is inside a spacious graveyard, but I'm not currently aiming for a horror game.  This combined with my lack of organic modeling skills encouraged me to decide on a low-poly, low-resolution art style.  As I spent a considerable amount of my summer working on pixel art, it seems like a nice representation of my skills.  If I ever revisit this project after its completion, I may change this approach; for now, it suits my needs well enough.

So far, the most fun I've had was while putting together the Kismet for the level.  Most of my design required relatively simple programming-- things like picking up items and opening doors-- but a puzzle that has you lighting torches in a specific order required some head-scratching and a couple re-implementations.  At this point I am calling on a few Flash files to add some fancy text to a puzzle, but am largely depending on the pre-built announcements of the UTDeathmatch game style.  I hope to replace this with my own solution before the end, even if it's just to replace the HUD with a player inventory display.

I have a small imgur album set up for this project, which I hope to fill as I get more assets finished and presentable.  Of course, I will be updating this blog with more information as I find the time.  My goal is to cover the major parts of this project in detail so that people other than me can benefit from the weird bits of things I have learned and will be learning while I complete this project.

Until next time!

Simple Turret Using UDK and Kismet

/* Long-winded introduction */

Hello, internet!  As I probably haven't mentioned, last semester I was in a course called Virtual Environments at my university.  For our final project, I ended up in a group with a guy who was very eager to make more than just an environment-- he had an idea for an interesting yet simple game level.  Since I like to pretend I'm a programmer, I immediately said I'd love to try some Kismet and see how game-like we could make the level in the few weeks we had to do the assignment.

The "level" we turned in was definitely impressive, considering it came from a beginner-level class that had just barely skimmed over some of the basics of Kismet.  I only feel comfortable saying that because the rest of the class said it was awesome when we presented it, by the way!  However, it was missing one of the most interesting gameplay aspects-- turrets.

Yesterday I started work to add them.  This is what I have so far.

Please note: this is a work-in-progress.  You are welcome to use this code as you see fit as long as you're aware that parts may not work right all the time or at all on your build.  I'm new to this, so I may not be able to answer all of your questions about this code or the inner workings of Kismet/UDK.

Note: the game type used in our level was UTDeathMatch.  I'm not sure if it's a necessary setting to make this stuff work, so I figure it's best to let you know just in case.

/* Turret details */

Our level's turrets were imagined to be rather simple-- player gets in front of turret, player gets shot; player shoots turret, turret falls over and stops working.  The best comparison I can think of is the turrets from Portal.  To accomplish this, I needed to main functions:

1. Shoot at player
2. Respond to getting shot by player

/* Kismet details */

Our first function is circled in red and labeled #1.  My Kismet is a complete mess, so I'll summarize.  The code begins when the player Touches the Trigger Volume I have placed in front of the turret.  Note: don't forget to set the Touch node's "max trigger count" to 0 like I always do!  On touched, it sets our "if" statement to true; if untouched, false.  If true, we go to a section of vector math that gives us a location to spawn projectiles.  For this mesh in particular, I want it to be about 150 units above the pivot point, where the pivot point is currently slightly in front of the turret's gun but level with the floor.  After that, the code gets the player's location as a vector.  This is necessary because the Spawn Projectile node can't have a Pawn as an input for some reason.  Now the PlayerLocation and SpawnLocation vectors are fed into Spawn Projectile.  I have chosen the rocket from the drop-down list in the node's settings, so a rocket will be fired at wherever the player was standing when this function was called.  I included a delay at the end of Spawn Projectile to keep it from shooting too rapidly-- if the player stands in the Trigger Volume, the turret will shoot rockets at him/her every two seconds until the player either leaves the Volume or dies.

Whew!  Seems a lot less complicated in my head!  This next part gets even hairier, so take a breather if that one wore you out.

The second function is the part that's messy and may not be working right.  I seriously doubt this is the best way to handle this, so please let me know if you have a better solution.  Note: the turret is currently set as a KActor-- I don't know if this code will work with any other physics setting!  Our first step, labeled in blue as #2, is actually quite simple.  Here we just get the turret's rotation when the level first starts.  This is so we have a point of comparison in the next step.  In the section labeled in orange as #3, we are telling our turret what it should do when it gets shot.  In this case, we want it to figure out if it was rotated far enough to be considered toppled over.  I put a brief delay after the Take Damage node to give it time to fall, and then get its new rotation.  The code looks like a huge mess here because, unless I'm just doing it wrong, vector math in Kismet is unnecessarily complicated.  It's really just checking to see if the difference between the new rotation and old rotation is significant enough by subtracting the two, getting the absolute value of the result (I had to code this node myself, mind you), and then compare it to a value I determined to be "far enough" (in other words, about 45 degrees multiplied by 182.044 to get the UnrealScript rotational units).  If the rotation of the X or Z component is "far enough," then the turret's Trigger Volume is destroyed and a message pops up letting me know it worked.  Note: you might notice that the Y component is there but not being considered-- that is because shooting the turret in just the right place long enough will cause it to rotate in place but not fall over, which will incorrectly trigger the "death" of the turret.  It looks like it should be the Z component doing this when looking at the turret in the editor, though, so I think it's a byproduct of creating the mesh in Maya, where Y is up.  I'm not sure about this theory, so let me know if you have an explanation!

/* Conclusion */

It always kinda surprises me when I get stuff like this working, even though it looks so simple when you're the one playing the game.  I think next I'm going to see if I can't add a dynamic trigger volume so it'll keep shooting you if you rotate it in place, and then a blinking light or something to make it more obvious which turrets are on and which are off.  I'm starting to think just diving into UnrealScript and making a new class for this would be the best way to finish it off, but I'm not sure how to translate some of the Kismet functions just yet.  I'll be sure to post an update if I do, as it'd be a lot easier to test out a new class than try to reproduce my Kismet!

Thanks for checking out my work.  If you have any questions or suggestions for improvement, please let me know.

Game Maker Tip: the Collision Event

Hello, dear readers!  I have been busy with life and school, and haven't had much time to think about, let alone update, my blog.  This ends today!  While I take a quick break from working on my final project for my Rapid Prototyping course, I shall take a moment to cover something I've learned about the collision event in Game Maker.

So I'm making a tower defense game, which means I need towers, right?  But wait, every time the enemy collides with a tower, they both die right away instead of dueling it out!  I have the enemy programmed to stop walking and hit the tower every x steps, but it's not working.  What's going on?!

The short answer is this: the collision event works differently depending on whether the object you're colliding with is solid or non-solid.  If you mark that object as solid, Game Maker will push the moving object back to its pre-collision position after they touch, as if the object actually bounced back slightly like it would in the real world.  If it's not a solid object, it'll leave the two "on top of" each other, meaning the collision doesn't really stop until something moves away.

What does this mean for my tower defense example?  Well, if I mark my towers as solid, the enemies will "bounce" back slightly when the two collide and will be able to stand there hacking away at my defenses.  If I  leave them as non-solid, the two will pretty much get stuck together and constantly recall the collision event until they both die.  Fun stuff, eh?

I hope this helps someone out there, as it gave me a lot of trouble while I tried to get my game up and running.  If you have any questions, concerning the collision events or just Game Maker coding in general, feel free to leave a comment.  I'm still pretty new to the program, but I might at least be able to point you in the right direction.  Happy developing!