File Size: 124.95kbThe final project in the Intro to 3D class I took was to design a bug and place it in a scene.
File Size: 144.79kbWell, it seems I'm 13 days late for Halloween.
Anyways, this is the final render for the first project in the Intro to 3D class I'm in. We had to make a LEGO man and give him some personality.
After 3 months of work in my free time, I am finally able to open up the 5th iteration of the BoogaTech websites and CMExpress system. The redesign appears only minor on the surface, but the control panel has been reworked from the ground-up, "pages" have been merged with "content items" for more flexibility (however, old external links to this site might 404) and everything works on a completely new template system that compiles files coded in a simplified template language into sets of PHP functions that should allow the site to load faster. The comment system has yet to be reworked and is missing for now, though it's not like anyone was using it before.
Right now it looks best in Google Chrome, and Firefox shows it mostly right. I don't know about Internet Explorer at the moment, but I wouldn't be surprised if it looks messed up.
In other news, school is back in. I wouldn't expect any major updates on my projects until mid-December, since as of the beginning of the semester, I am working on one of the senior animations at BYU. They plan to have it finished for post-production by Thanksgiving, and completed in time for the student Emmy's.
Update 10/22/2010: The comment system is back in, with added support of Gravatar avatars. I also modified the security image a little bit to make it more readable. The reply-notification-by-email feature doesn't work for now since I need to program CMExpress to handle multiple PHP email methods sooner than expected, as WebFaction doesn't support the one I've been using.
File Size: 593.61kbI drew this on the train back home right before Christmas last year. The train arrives in town at around 11PM, and it's usually pretty empty during the entire trip to California. It's also not one of the easiest of places to draw in.
So the Flash game that I was hired to do graphics for back in 2008 and 2009 has finally been released under the name "Shattered Colony: The Survivors!"

This is a sort of progress list of things that need to be done before I can work on releasing "Bridges of the Mertynn." The items will be color-coded as to their completion, and this list will be updated regularly.
Programming:
Tile Sets:
Player:
Other Graphics:
Levels:
Music:
Server Side:
Legend:
Started
In progress
Mostly done
Finished
File Size: 161.64kbThe first assignment for the Drawing for Animation class I am taking. The theme was "treecrabs of the lonely forest."
Now that school is out for a bit, I was able to get more work done on 60 Seconds to Deliver. Here's the previous to-do list with progress updates:
My contract with my current website's host runs out in a few months. I had decided not to renew it and move to a different host, since PowWeb's service has been going down-hill ever since they got bought out by some larger hosting company. Don't be surprised if there's any downtime during the move. Though with how well things have been staying up lately, you probably won't notice anything different until it's moved over to the new host.
An issue many of us have as Flash animators and game developers is protecting our work from appearing on websites that for some reason or another we don't want it to show up on.
Site-locking is the method of locking your Flash file so that it works only on the website(s) you want it to. There are numerous methods for site-locking your project out there on the web, but many are simple and don't protect against more devious content-lifters.
Most site-locking scripts are designed with the following logic: you want it to only work on mywebsite.com, so you make it so that it only works when mywebsite.com is part of the URL. This is pretty effective until someone places your file in a certain folder such as www.badwebsite.net/mywebsite.com/, or plays around with their sub-domains so that they have it working on mywebsite.com.badwebsite.net.
So how do we go about coding a site-lock that takes these problems into consideration? The first thing we'll want to do is get the URL that the Flash document is being hosted on:
var siteURL:String = root.loaderInfo.url;
The URL will be build of three main sections. The first is the transfer protocol. This is the http:// part of the URL. We'll want to strip that off our URL, though there are a number of different protocols each with different acronyms. To get around this, we use the split function to split the URL where the "://" part is.
var httpBits:Array = siteURL.split("://");We now have the variable httpBits, which is an array containing the split strings from siteURL. httpBits[0] will contain the "http" string and the second two parts of the URL after the "://" part is stored in httpBits[1].
So now that we've removed one part of the URL, we're left with the other two parts: the domain name and the folder(s) that contain your file. We only want the domain name, and we can get that by splitting our string with "/".
var urlBits:Array = httpBits[1].split("/");Now we have the array urlBits containing the domain name and each folder along the directory tree to your file. The domain name is stored in urlBits[0], but there is still one more step to take before we can compare the URL's domain name with our preferred domain name.
The domain name can be as short as domain.com, but it can also be lengthened by sub-domains, which can be named in ways meant to trick your site-locking scripts as presented above. We will need to split the domain name with ".":
var domainBits:Array = urlBits[0].split(".");Now that we have an array of domain parts, we can start comparing them. The real domain we want to check with will be stored in the last two entries in our domainBits array, so we can finally use them to check the website's domain name:
var i:int = domainBits.length;
if (domainBits[i-2].indexOf("mydomain") < 0 || domainBits[i-1].indexOf("com") < 0)
{
/* If the domain isn't the right one, your script to handle that goes here.
You could remove the display object containing your game or, if you're
using the Flash IDE and programming straight into the time line, use gotoAndStop
to send the player to a frame that loops back onto itself. Whatever you do,
you'll want to display some kind of message telling the user where they can
legitimately play the game or animation. */
}Here is the whole code built into a function that will return true if the website's domain name matches the one you specify or false if it doesn't match:
private function checkURL(URL:String):Boolean
{
var siteURL:String = root.loaderInfo.url;
var httpBits:Array = siteURL.split("://");
var urlBits:Array = httpBits[1].split("/");
var domainBits:Array = urlBits[0].split(".");
var myDomainBits:Array = URL.split(".");
var i:int = domainBits.length;
var j:int = myDomainBits.length;
if (domainBits[i-2].indexOf(myDomainBits[j-2]) < 0 ||
domainBits[i-1].indexOf(myDomainBits[j-1]) < 0)
return false;
return true;
}
This allows you to check multiple domains and handle them like this:
if (!checkURL(mywebsite.com) && !checkURL(somewhere-else.net))
{
stop();
}
I hope this helps anyone with questions about site-locking.