Extinction Plan: Alpha v3.6

Extinction Plan Alpha Version 3.6 has been released for Windows platform. The only major change is the inclusion of difficulty levels on the main menu. Selecting one will lock the game to that difficulty for now. This should be fixed by Update 3.7; I already have a workaround planned. I really wanted to get an update that lowers the difficulty from v3.5, it was fairly hard. Just remember, even though on death or return to menu it offers you to change the difficulty, it wont work. You'll have to simply restart the game and choose a new difficulty.

Here's the new info from the changelog:
- Difficulty Levels have been added to the main menu
- Defaults as "Normal"
- Enemy Damage = 100/hit
- Enemy Spawn Rate = 1/10sec
- Easy
- Enemy Damage = 50/hit
- Enemy Spawn Rate = 1/15sec
- Hard (Same as v3.5)
- Enemy Damage = 200/hit
- Enemy Spawn Rate = 1/5sec

Here's the download link (Windows Release Available Only):
https://drive.google.com/file/d/0B_f_zFzl7wjHU0paaHdmRW5yeXM/edit?usp=sharing

Extinction Plan: Alpha v3.5

Extinction Plan Alpha v3 Update 5 is now available for Windows platform. Linux and Mac to follow after testing. Some massive AI changes and a difficulty spike; with Difficulty levels to be included in a future update (by Alpha v4).

Download Extinction Plan Alpha v3.5 - Windows Only:
https://drive.google.com/file/d/0B_f_zFzl7wjHX0VpN241VThSQUk/edit?usp=sharing

Check out the Update video below:

Extinction Plan: Alpha v3.4 Update

Extinction Plan: Alpha v3.4 is now available for testing on Windows, Linux, and Mac.
- Controller support is back : Readme for information.
- Health GUI is now implemented again (still text based for now).

- On death, the main menu is now automatically displayed.

Get the newest Alpha Here

Extinction Plan Alpha v3.3

Here's the link to the Google Drive which features all of the Alpha Builds previously available, and now contains Alpha version 3.3. Go to the link, follow the folder to your desired platform, Download the zip, or 7zip on Windows; extract and play! No installation required. Works on 32 or 64-bit platforms. Linux, Mac, and Windows.

https://drive.google.com/folderview?id=0B_f_zFzl7wjHeGh5WDNIeDVrdTA&usp=sharing

Bouncing Back and Rain AI Core Implementation

After dialing back the projection of work for the week it's been easier to focus on a few of the smaller things. In that sense, the Androidbot has been removed for now; it was too difficult to deal with a new AI Core and re-scripting it, while simultaneously figuring out how to match the Animation controller to the new AI Core. Unity, it turns out, wont allow me to animate any of the IK rigs for the model inside of Mechanim without buying Unity Pro, so I'll have to reanimate the model inside Blender again and then re-import it. Legacy Animations also would not work from the way the model was rigged/animated/exported, it would all have to be redone anyways. There would be no sense in simply "making it work", I want to do it right; I see that as what will set me apart from other Independent Developers.

Since the original Robot model was still there, I added the new Rain AI Core scripts that I wrote to it and am now testing some of the commands I've written; as well as the new Navigation Mesh, Waypoint Route, and Waypoint Network. So far, the Navigation Mesh is established and working perfectly. I set a robot out to just wander around the map and it only got stuck once, allowing me to learn that two of my buildings had colliders which were set to "Trigger" mode; the player could have simply walked through them. Bug evaded on that one. The Waypoint Route is working fantastic, and after some quick help from the extremely helpful Rival{Theory} support the robot no longer clips through the ground, or falls over due to gravity. Those guys are seriously #1 in my book.

The Waypoint  Network is also working well, as long as the robot isn't programmed to wander randomly from the path. Although knocking the robot off the path will lead him to find his way back to the system automatically. He wanders just fine about 75% of the time, then every once in a while he looks for a spot just out of reach and has no way to get there. I'm fairly certain this is due to my Navigation Mesh allowing the tops of buildings as potential navigation points; it's definitely something that can be fixed without too much work from me.

For now, I think the only game-mode which will be updated for the Alpha 3 will be the Robot Overlord level; although as with the rest of the Alpha Builds, all of the old content/game modes are going to be left in-tact. This will mean there will be an Alpha 3 Robot Overlord featuring the new AI Core, and the old one from Alpha 2. The options on the main menu will be changed to reflect this.

My sole goal for Alpha 4 will be to have Androidbot re-animated and implement him with some new attacks into the Robot Overlord game mode. If this proves to be a simpler undertaking then I assume, I will use the rest of the time to spruce some of the game up, and maybe animate/script some of the other monsters into the game world. After this weeks disaster in development though, I don't want to get ahead of myself again. I have 5 more months to achieve my original 6-month to Beta goal, there really is no reason to overdevelop at this point. I think going from not knowing Animation, Rigging, AI scripting, or AI Path Navigation scripting, to implementing all of those into a video game in two weeks will be satisfying to me as a developer; and give me the foundation to easily expand on that knowledge and implement more enemies easier throughout development.

Remember if you are following this blog or project: 3 weeks ago I had roughly ZERO experience in making video games, and I grow more knowledgeable by the hour. That's what 100 hours a week practicing something will do. Do I consider myself a great developer? No, but I hold myself to great developer standards; standards which most companies no longer meet in today's market. I never want someone to be able to call me lazy, regardless of whether they like the finished product or not. That's my only goal in the end, to have a product that people are amazed was made by such a small team (1 developer and a 3D modeler).

Week 3 and an Ambitious Undertaking: I Bite Off More Than I Can Chew

Week 3 was going to be a hot development week. I was working with some new tools, rewriting all my scripts, and effectively rebuilding the game 100% from the ground up. I wanted to get 300sq.m. covered in city, I wanted animated enemies, I wanted Raycast weapons, I wanted Health scripts that can be accessed by trigger events without needing to reference the health script on each enemy directly, I wanted to get a general aesthetic for the game set in place, and I wanted to start modeling and texturing around that aesthetic.

I rebuilt the scripts, got 200sq.m of city covered, animated a new android (to replace the robot), created 2 new weapons, and started flushing out a general theme (which I told 3 people about in gross detail, more on that later); and then everything went wrong. I'm not talking hard to handle, I'm talking output-crushing difficulty spikes in development. It all started with a Quaternion Angle calculation, one that took the better part of an entire day to write and instantiate; all over the angled trajectory of the spray pattern of bullets off of mesh surfaces.

I was told, that the easiest way to accomplish an on- hit animated particle effect was to simply create a particle effect, and then when a raycast hits have the particle effect rotate to "look" back at the camera and then instantiate. But this looked sloppy. Bullets spray wouldn't ricochet back 180 degrees and fly towards you, not unless you were going to be looking straight at the wall. Not acceptable. That was my first mistake. As an indie developer who does EVERYTHING other than the modeling of the enemies (I even rig them and animate them myself once I get them from Julius), I needed to see when it was good enough for now; mark it down in my to-do list and then go from there. I, of course, didn't. 5 hours later it was working great. Bullet collision spray works in an almost natural way; mirroring the angle of the raycast's trajectory and then calculating that mirror to fit the mesh plane and rotation of the hit-point. That also put me 5-hours behind.

Now, I had finish the android's animation and figured it wouldn't be difficult to simply swap the enemy model from the old game model robot with the new one. Yeah. Right. Unity, without the Pro version, doesn't support IK in Mechanim. What good is an animation program, that can't animate? Not very good. No problem, I had already made the animations in Blender and could easily just import them into Unity; in fact, it should have done so already because the FBX file contained them already. Yup, but for some stupid reason Unity can't find the head bone of the rig, even though it had found the parent neck bone, and the head bone was the next bone on the spine in the hierarchy. It took me a little while to figure that out, but now my animations were working in Unity on my android. Except my AI script is set to move the character, and I had created the animations with movement. Even the one I didn't Mechanim was still adding a movement to it. This meant I was doubling up on the movement, so I just removed the forward movement from the AI script.

So now the android can walk around, follow my waypoints and so forth. It clips through objects because it doesn't have a collider attached. Attaching a collider caused the animation to get stuck on literally everything (the ground, 0.25m size increases...) wont work. So I change the collider to a capsule collider and everything seems to work fine, until it runs into something that allows the collider to push the android up; then he never comes back down. Fine, I'll attach a rigidbody to the android and he should be good. He'll walk over stuff, and then fall back down. And fall down he did. Almost immediately, and then sat there spinning in circles. Alright, box collider then. Hitbox is messed up now from being a square. Adjust it. He starts getting stuck on everything. Yup. Fine then, no rigidbody and a sphere collider with downwards force being put on it. Feet clip through the ground, can't go up slopes. Just choose to remove it all for now. So none of that works right. I can make the android walk around on flat ground, but any slope kills it. So now I have to decide if I want to flatten the slopes of the city to make it work right. It's on the back-burner.

I start researching themes for the game overall; and decide on a period based science fiction theme, starting with the 1970's, then releasing some later full conversion content levels that would be the 80's, then the 90's; and possibly the 60's. I start working on some textures, and weapon ideas that would fit the theme. Ray Guns, Laser Beams, Destabilizers, Mini Nukes, Rocket Launchers, that sort of thing. Start sketching out some general aesthetic idea's of a 1970's futuristic city; not that there is a specific idea, using more of a compilation of idea's. I reanimate the android to look like a guy in a suit, giving the mesh a "jiggle" overtop of the rig so it doesn't move in a natural way. I create some billboard-like effects, which make rockets look like they have a hand-animated 1970's CG fire-trail (it looks two-dimensional from every angle, and auto rotates to "face" the camera) cool stuff. I send the file to a good friend of mine, who talks with me for about 2 hours about the vision of the game and getting a feel for how I envision it to be once it's a finished product (months from now). I get some great feedback from him, and took as many notes as I could.

Then I get into a meeting with Julius and pitch it to him; total shut-down. It doesn't fit the aesthetic of what he was creating with the enemies. Scrapped. So now we go into discussion of what the game should look like; there is no real general consensus other than a city that has giant monsters and other enemies rampaging it. I get told Doom 2 type city textures, and more hell-gates and stuff. Alright. I start going back through Doom 2 to get a feel for the description. I see it, and I love it. First thematic pack can be based on what we already have the assets mostly created around; I have zero problem with that. But now, everything needs a full redesign. I designed the city around the idea of having a retro-futuristic look, now I get to go back to square 1.

So now I'm 2 days from when I wanted to drop a new Alpha (I try and get one done a week) and I have, essentially, no city again, no animated enemies, no weapons (just scripts), and a whole lot of work to do redo. To "finish" the first level, I still need:

1. Enemies that are animated, that follow a waypoint script, with variable attack scripts worked in (wander->chase->attack->chase->wander) with hit-detection, and health.
2. An attack for the enemies to do, be it a raycast laser or a projectile.
3. Buildings that are textured properly.
4. Particle effects to mask the building "being destroyed" falling through the ground.
5. Raycast that also has an add force/velocity script attached.
6. Explosions that also have an add force/velocity script attached.
7. To redo my explosion radius script so it never produces negative damage.
8. A flushed out way to create the enemies on the playing field (hellgate, dropship, tractor beam...)
9. All of my UI elements re-added and updated for new gameplay mechanics.
10. Environment assets (trees, vegetation...)
11. Lighting completed
12. Sound
13. A level script telling the game when you're "won".
14. Player data to be saved from one "level" to the next.
15. Weapon and player upgrades.
16. A weapon model.

It's just going to be a long road. I went into this week with a high-output thought process, but at this point I'm just crippled. I'm trying to get focused and start work again, but other than the scripts, I'm essentially having to scrap everything that got done this week; right down to the animations on the android. It's just being written as a total loss in my book. I didn't realize the scale of this weeks undertakings, but next time I'll make sure to dial it back a lot; better to get everything done really early and have to think of things to accomplish, then to force output. It's just too much stress for one person.

Understanding and Implementing the Debug.Log Function

When writing a script, and you are doing something which interacts with the game world, you should add the Debug.Log command to the end of your lines. This will return whether the line in the game is working the way it should be. Creating an object? Debug.Log it. Destroying an object? Debug.Log it. Shooting an object? Debug.Log it. This allows you to make sure that everything happening in your game is happening the exactly the way you want it to; and if it isn't you'll know why (or at least have a better example of where the error is coming from).

For this tutorial, we are going to create a self-destructing cube object, and debug whether it has destroyed itself properly, along with the name of the cube in-game. This allows us to not only know that it is working, but if the script is applied to other objects, we will know which ones it is working on and when.

Create a new cube GameObject, and add it to the game world. Placement doesn't matter.

Create a new C# script and name it SelfDestruct.

Open the script in MonoDevelop.

Above the "void Start( ) { }" line, add a new string "public float duration = 1f;"

This makes a new public float called duration and sets it to be equal to 1.

Now we wont be using the "void Start( ) { }" function at all, so skip over it.

Inside your "void Update( ) { }" function we want to add a string that will decrease the "duration" float to 0. We do this by simply adding the line:

"duration -= Time.deltaTime;".

This tells our script to take the preset time (which we set to 1 already) and remove 1 for every second. You must add  ".deltaTime" after the "Time" command, since "Time" is calculated per-frame; ".deltaTime" normalizes the loss per-frame over the course of real-world time.

*The function "duration -= Time;" would remove 1 from duration every frame, instead of every second.*

Now that we have a timer setup for duration, we need to tell the script what to do if the timer reaches 0.
We do this in the most simple way possible; using an "if" statement.

Below the duration timer line you just wrote, we want to create a new line:

"if (duration <= 0 ) { }".

This tells our script to do something (which we will define inside of the { }) if the timer is equal to or less than 0. You could add a script to make sure that the timer stops at 0, but since we are going to be destroying the object anyways, it would just be unnecessary scripting.

Now inside of the brackets, we want to tell our script what to do when the timer is 0 or less. Since we know we want to destroy our object, we will use the "Destroy" command.

Inside the { } brackets of your "if" statement, add the line:

"Destroy(gameObject);"

This tells the script to destroy whatever is inside the parentheses. In this case, we have defined that as "gameObject", which denotes the object the script is attached to.

We have now created a timer, setup a countdown for the timer, and told the script what to do if the timer reaches 0. Now we want to make sure that the Destroy function is working properly. So we have just one more line to add inside of the "if" statement brackets.

Below the "Destroy" line, add the following new line:

"Debug.Log("Destroyed: " + gameObject.name);

This line tells the console in Unity to display the message "Destroyed: " along with the name of the gameObject which was destroyed. This message will only appear once the "if" statement has run.

That's it, you should now be able save the script, and drag it to the cube you created and start the game. One second later you should see a message in your console that says "Destroyed: Cube" or whatever you named the cube. If you encounter an error, or the script doesn't work, make sure that it looks like this:
-------------------
using UnityEngine;
using System.Collections;

public class SelfDestruct : MonoBehaviour
{

public float duration = 1f;


void Update ()
{
duration -=Time.deltaTime;
if(duration <= 0)
{
Destroy(gameObject);
Debug.Log("Destroyed: " + gameObject.name);
}
}
}

-------------------
The code above works, and was written and tested by myself.

This is obviously a primitive implementation of the Debug.Log function, but it's an easy example, using real functionality. There are many different types of things you can Debug.Log; some of which have specific functions which can be called in different ways. None of which I'm going to discuss, as there are too many functions and uses to go in-depth about and I wanted this to be an easy tutorial.

Scrapping Code and Rebuilding

Building games is a learning experience. Constantly evolving in methods and efficiency, it's easy to look at code that you have scripted and see the time you put into it, blinding yourself from the lack of efficiency it may be having on your project. Taking the time to go through and rewrite code, especially when you have noticeably been having to script around it, can help your project just as much as writing new code.

I'm scrapping about 90% of the code I have written up to this point. It's fluff, it's inefficient, it's difficult to put into use. I have no issues with doing this. It's not as if the code means nothing; when I look at it, I see hard work and time. A couple hundred hours worth of time to be a little more precise. But it all is for nothing if it doesn't evolve with the project. As I grow as a developer, so must my process, and that means my scripts need to grow to fit that process.

I never try and look at scrapping anything as a bad thing. I've never once let myself feel as though "all that work was for nothing". I look at every line as a learning experience. When I wrote it, it had a purpose. I was using those lines to create something from nothing, and in-exchange it gave me the knowledge to better understand what I was creating as a whole. An understanding that continues to grow even now, as I rewrite my games past.

They say that art is never complete. That an artist will never look at their work and see finality. You must consider yourself an artist as you script; being critical of your own work, and constantly seeing where it could be improved upon.

Nameless (Alpha Version 02)

Nameless 02a (Version #02 Alpha) 

Changelog:
https://drive.google.com/file/d/0B_f_zFzl7wjHaWlIamRHT0xNTnc/edit?usp=sharing

Windows: (16mb - x86 & x64)
https://drive.google.com/file/d/0B_f_zFzl7wjHV29tM1VfcTVHbzg/edit?usp=sharing

Linux: (31mb - x86 & x64)
https://drive.google.com/file/d/0B_f_zFzl7wjHSU9hQ1VtWVNZdUU/edit?usp=sharing

Mac: (12mb - x86 & x64)
https://drive.google.com/file/d/0B_f_zFzl7wjHdWFCQThZZEI0Mzg/edit?usp=sharing

Prototype and ProGrids Level Building Tools

I was looking for a good grid system today, and while browsing the Unity Asset Store I stumbled across Prototype. At first glance, I passed on it. I didn't really get the jest of mesh deformation in Unity; I have Blender, and it was working alright for the little bit of level editing I had been doing. Then I found ProGrids. Watching a tutorial for ProGrids I realized the potential of the combination; real-time mesh deformation, collision detection and trigger detection, in any-shape you could need with just a couple clicks of the mouse. No putting in coordinates, no more centering objects up; no more worrying about calculating the correct points for my vertices. I could control a cube object almost as well as I could in Blender, right from Unity; no exporting and importing.

I started looking further into the software suite called ProBuilder; essentially Prototype, but with the ability to also add Textures, Lighting, Export Objects, and quite a bit more. Quite a bit more in functionality, but also in price. Instead of the $15 for Prototype it was $95, and the use was generally the same; one is made for complete projects and the other is made for designing layouts and then replacing the Prototype models with completed objects from a 3D modeling software. Being low on funds, and still needing to pick up ProGrids for $15, I chose Prototype. I figured the extra $15 wouldn't hurt, and if it was worth the money I could save up and splurge for ProBuilder at a later time.

All I could think of was the fantastic objects I could now create in Unity. The buildings, the structures; roads would have sidewalks, buildings would have stoops, buildings could look like buildings with ease. I imagined how simple the process of creation would be by combining my software mediums; I didn't imagine hard enough. After just two hours I had a multi-tiered Subway tunnel and entrance mapped out, with colliders on the stairs to make them smooth, hand-rails, a road, a median, a sidewalk; it was literally the first time since I have used Unity that my project looked and felt like a video game. Like a quality title in the making.

I haven't played with everything it's capable of yet, and I can't imagine the level of overwhelming freedom of creation I will feel in a few months when I buy ProBuilder, and simply start adding textures to a world that's already created. I do not know why this software isn't built into Unity. I don't know why Unity can't do all of this without the plugin; it sure as hell would increase the quality output of Unity projects exponentially. I don't need to know why, I spent the first $30 on software for development and so far it's been the best money I've spent in years.

Nameless (Alpha Version 01)

I wanted to post the links to the Alpha 01 release of Nameless (tentative title). For now, destructible buildings have been removed to be re-scripted from the ground up; but I encourage you to check out the pre-alpha test #006 to understand how it will work (roughly, there's a reason it's being re-scripted). Remember, this is only the first-alpha build; it's only the bare essentials of what you would consider a game. The enemy AI has no pathing, it simply runs towards you; score is essentially pointless and only counts up with a timer. The GUI needs an overhaul. It needs a main menu (priority #1 for version 2), it needs music and sound effects. Enemies need their collision detection fixed. Lots of work left to do, but it's only been roughly a week; let's see where it goes! Give some feedback below. Negative feedback is fine, but we can't fix what's wrong if you only say something negative without a reason! Want to see some features implemented? Want to know how something was done? Leave a comment and I'll look into anything you ask (pertaining to the game).

Nameless 01a (Version #01 Alpha) 

Windows: (19mb - x86 & x64)
https://drive.google.com/file/d/0B_f_zFzl7wjHYzlMMks5Rzh6TG8/edit?usp=sharing

Linux: (30mb - x86 & x64)
https://drive.google.com/file/d/0B_f_zFzl7wjHTE1ZSjY5UURoek0/edit?usp=sharing

Mac: (12mb - x86 & x64)
https://drive.google.com/file/d/0B_f_zFzl7wjHdGJPZkVfUzZLOXc/edit?usp=sharing

Pre-Alpha Test #006 Footage

Creating a Simple Unity Level in Blender

This tutorial will cover the process of creating a simple, 3D level to be used in Unity Projects using Blender. This process is perfect for anyone looking to make a Dungeon Crawler, or a First-Person Shooter Arena level. This is the same process I used to create my buildings in 'Nameless Alpha v01', but the possibilities are only limited to your own imagination, and the time you want to spend creating your project. This tutorial will not cover texturing, although I will make a new tutorial for that at a later point; for now we just want to make it work.

Remember that at any time, if you make a mistake you can use 'Ctrl + Z' or 'Ctrl + Shift + Z' to undo and redo respectively. If you run into any issues with hotkeys not working properly, make sure your mouse cursor is over the 3D window and then try again. The mouse cursor is the largest, most user-unfriendly part of Blender.


Getting Started

We want to create a new scene in Blender. Pressing 'Ctrl + N' to bring up the new scene menu, then 'R' to reload the starting scene.

With your cursor over the new 3D view window (and not any of the side menus) press 'A' to deselect the cube, and then 'A' again to select everything in the scene (Pressing 'A' will select and deselect everything in a window)

Now press 'Delete' to bring up the delete menu, and then 'D' to confirm the deletion process.

Pressing 1, 3, or 7 on the Numpad will toggle between front, right, and top perspectives (respectively). We want the top perspective; so press 'Numpad 7' (make sure 'NumLock' is on and your cursor is still over the 3D window if you have any issues).

Now that we are looking down on the X and Z axis from the Y, we can start creating the level.


Creating a Plane

We want to make sure before we move on that the 3D cursor is centered at (0,0,0); we do this by pressing 'Shift + S' (to bring up the cursor menu) and then 'R' to snap the cursor to the center.

Now that the 3D cursor is centered, we can add an object. Pressing 'SpaceBar' will bring up your quick menu. We want a Plane, so type "plane" (you don't need to click in the search box, just type) and hit 'Enter (Return)' to create a new plane object.


Scaling the Plane

Press 'S' to scale the object; taking into account the plane starts as a 2x2 area, remember that scaling by 20 will result in a 40x40 plane. For this example we will use 20 to keep this tutorial in-line with the previous tutorial to create a uniform area that will spawn different "rooms" in each designated space upon scene load.

We now have a 40x40 plane, which we will use as the base of our level. 'Mouse Scroll Wheel Down' to zoom out (making sure your cursor is over the 3D window if you have an issue)


Subdividing the Plane

From here we want to designate the playfield inside the model. To make the level as uniform as possible, we will use the Subdivide tool. In order to use this tool we need to put Blender into Edit mode. This is easily achieved by pressing the 'Tab' button to toggle between Edit and Object modes.

You can press 'Space' to bring up the quick menu, type "sub", then push 'Arrow Key Down' to highlight the Subdivide option, and hit enter. Alternatively, on the left hand side of the screen is a menu called Mesh, with a sub-menu called Add, with the Subdivide option nested inside. Either of these methods will split the plane into 4 pieces, as well as bring up the Subdivide menu on the left hand side of the screen (under where the Mesh menu was located).


More Subdivisions Through Cuts

Now, we need more parts than just 4, so in that Subdivide menu is an option called "Number of Cuts", it should currently be set to 1, this tool allows you to divide as many times as you want up to 10 per "face"; we want to set it to 10 for this example.



Remember, you will have spaces equal to "Area / (Cuts + 1) ^2". In this example we have spaces that are 3.636363^2 (repeating of course), but we will simply round that up to 3.6364^2 (This number should look familiar if you read the "Calculating Block Sizes for Surrounding a Uniform Pattern" tutorial). If you are going for efficiency, do not ever round higher than the thousandths place; the more places, the more accurate your calculations are going to be later.

Now we have an area cut into 121 equal spaces, and we can start mapping.

Press 'A' to deselect everything.


Changing to Face Selection Mode

On the bottom of the screen, you have 3 parallel options (which look like cubes with orange sections on them); "Vertex select" is currently highlighted, and the one on the far right is "Face select" option. This is the one we will be working with. Click it and each of your 121 spaces should now have a small black box in the center of them.


Designating the Floor Panels Using Faces

With your cursor back over the 3D View window, press 'B' to activate the area select tool.

Select the blocks you wish to make floors from by holding 'Left-Click' and highlighting the black box in each area (if you hold 'B' during this process it will stay active after 'Left-Click' is no longer held). If you select a wrong block, simply repeat the above process, using the 'Center-Mouse (Scroll Wheel) Button' to deselect blocks.

Extruding the Floor Into Negative Space to Create Walls

Once you have a pattern you like, look on the left side menu for a tool called "Extrude Region" (located above the Subdivide option). Clicking it will allow you to move the floor up and down, since we are making floors, we will go down. Type the size you wish to adjust the height of the floor to, remembering that since you are going down, we want to go into negative space. For this example, we will use -4. Press 'Enter' to confirm the transformation.

Press 'A' until everything is deselected.


Optional: Adding an Entrance/Exit

Now, if you are going to need an entrance (or exit) you will want to select one of the very side faces on the newly formed wall using 'Right-Click', and press 'Delete', then 'F' (or select Faces from the delete menu) to delete the wall's face from the object. This allows the player to enter or leave the object.


Moving the Object Out of Negative Space

If you have made all the changes you want, the last thing we need to do is move the object out of negative space. To do this, simply press 'A' until everything is selected, then press 'G' to grab, 'Z' to snap everything to the z-axis and move it up as many units as you went down during the Extrude process by typing the number (remembering you are now working in positive space, if you went down -4, then you would move it up 4 (not by -4 again).


Saving the Object to Import into Unity

'A' to deselect everything, and then 'Tab' to re-enter "Object Mode". You must be in object mode when you save  in order for it to be placed properly in Unity.




Steps for Creating a Uniform-Position Prefab in Unity

1. Import the file into Unity.
2. Create a new "Empty Game Object" and move it to position (0,0,0).
3. Put the model you just made into the Hierarchy and change its position to (25,0,25).
4. Add a "Mesh Collider" to it.
5. Drag the positioned model into the Empty Game Object.
6. Rename it to whatever you want.
7. Save it as a prefab so you don't have to repeat steps 1-6 again.

Calculating Block Sizes for Surrounding a Uniform Pattern

Placement is on a 50 x 50 grid. (x,z)
Assume all blocks have a y factor of >0, and then forget about the y-axis.
Gap size will be 3.6364 units (based on a 40x40 grid split into 11x11 equal sections)

It doesn't generate walls here, so we make a uniform pattern

Purpose of all this:
We have a 40x40 pattern which uses uniform entrance and exit placement, which needs walls placed around it. We also need those patterns to snap to our 50x50 grid system to be generated and placed in the game world using a spawner. This is also how I created the buildings in my Alpha game, I simply made a bunch of patterns, instantiated them into the game world using a spawner script I wrote, and then generated a roof overhead using another spawner script I wrote. This allows the buildings to change every round, while still keeping a uniform to the placement. Simple stuff.


to calculate the size of blocks on the x-axis to gap

From the inside of the room everything looks fine

50(width) - 3.6(gap) = 46.3636 (space required)
46.3636 / 2(blocks) = 23.1818(block size)
23.1818 / 2 (position = size/2)
(+)11.5909 position from 0x


to calculate position of block from 50x side

50 - (+)11.5909 (total space - position)
(+)38.4091 position from 0x

From the outside, not so much; this is due to "normals"

to calculate the z size of x-axis blocks

50(length) - 40(playfield length) = 10 (space required)
playfield must be centered at (25x,25z) to be uniform
10 / 2(blocks) = 5(block size.z)


to calculate position of x-axis blocks on the z-axis

0z + 5(block size.z) / 2 (position = size/2)
(+)2.5 position from 0z


to calculate position of x-axis block from 50z side

50 - (+)2.5 (total space - position)
(+)47.5 position from 0z


to calculate the size of blocks on the z-axis to gap

50 - 10(2*5 (2 x-axis blocks with width of 5z) = 40
40 - 3.6364(size left - gap size) = 36.3636
36.3636 / 2 (size left / blocks) = 18.1818
18.1818 / 2 (position = size/2) = 9.0909
9.0909 + 5 (adjustment for x-axis blocks)
(+)14.0909 position from 0z


to calculate the position from 50z side

50 - (+)14.0909 (total space - position)
(+)35.9091 position from 0z


to calculate the x size of z-axis blocks

50(length) - 40(playfield length) = 10 (space required)
playfield must be centered at (25x,25z) to be uniform
10 / 2(blocks) = 5(block size.x)


to calculate position of z-axis blocks on the x-axis

0x + 5(block size.x) / 2 (position = size/2)
(+)2.5 position from 0x


to calculate position of z-axis block from 50x side

50 - (+)2.5 (total space - position)
(+)47.5 position from 0x

Now we have a perfect box, built around a uniform pattern. There are a ton of uses for this, you'll simply have to be creative enough to find them.

New Development Blog

Because I'm sick of clogging up my Facebook with updates about a project I'm sure most of them don't care about!

I spend (literally) over the last day trying to get my Alpha Engine ready for a public reveal; I ran into some major, unfortunate issues right before I built the Pre-Alpha Test #006. This led me to start looking into a lot of my older code (I say it like it was forever ago...) and in doing so I realized that a lot of the code wasn't even formatted in a way that was easily readable. I've spent the last few hours now just going through all the game scripts (all of which I wrote myself) and cutting out the fluff, or optimizing where I can. Remembering I had built entire weapons off of a 'velocity' damage system, that when I converted to 'tag' damage I simply "made it work" rather than take the time to do it right. It became apparent that I had a lot more work cut out for me than I had even dreamed of.

Taking a few scripts that I had written in Javascript, simply because I found the Java references and didn't feel like looking for the C# alternatives; or heaven forbid I port the code over to C# myself. Then again, I amazed myself temporarily earlier when I needed a door model and so I booted up Blender and made it with only looking at the screen to add the texture. Not on purpose, I was eating a salad and couldn't be bothered with what I instinctively though of as trivial-baby-shit. It's not that anything I've accomplished is outstanding, or technical in any shape or form, but a week ago I couldn't even navigate Blender. At all. It was like going to a foreign country and not knowing how to speak the language and being there alone. The truth is, I didn't know how to accomplish almost any of what I wanted; I knew what I wanted though, and I had the determination to go for it. It's been 20 degrees below zero in my town the last week, there was nothing I would rather do than accomplish a goal.

As I began working I did what many before me have done, I watched online tutorials. I followed along, but I didn't simply follow the bouncing ball. Every time I heard something like "now we are going to..." I would immediately pause the video and see if I could figure it out myself. Self discovery is a large part of my personal learning process, watching and recycling information isn't a strong suit of mine. Eventually I got to where I wouldn't return to the video for 6-7 hours. I had enough information to start putting the game together, even if it used placeholder art, and the scripts were wonky; I hit play and 5 out of 10 times it would simply work the way it was supposed to. I felt accomplished, and motivated, and I took that motivation and I mixed it with copious amounts of caffeine.

The next day I was still working, and I didn't want to stop. All I could think of was that this was a feeling I had been trying to find for the last couple years; like I'm doing something substantial. Now don't get me wrong, obviously I don't believe my game is breathtaking; but once all is said and done I will have a product, which from what I've heard from others, is pretty fun; a product that I can hand to my daughter, and watch her get a little bit of joy out of it. A product that when friends come over, we can play it together; and my dream is for them to ask what game it is and where I got it. Well, considering all my friends already know about it, it's a far fetching sentiment; but I think you get the idea. I'm trying to do something that more companies should do, make something that I think is fun, because I'm my target audience. Although I hope people want it, that would be a literal dream come true.

99% of my posts aren't going to be like this, but I feel like a first-post should always be personal; after all, you might be coming back often!