I've been playing with the Alpha version of Wick Editor off and on since the Wick Editor Game Jam announcement. Out of the gate, it had a lot of deal-breaking issues. Thankfully @luxapodular and @zrispo are very serious about making this game jam a great experience and have really stepped up.

They have been busting ass for the past week to get the Alpha Version up to stuff for the game jam. It's still not quite as intuitive as the other version, but if you are just starting with Wick, I would recommend sticking to the Alpha version because the other one will not have a lot of support going forward. The fixes they have released have changed the Alpha build from being unusable as a game development tool to being just good enough to make some fun, innovative stuff.

That said, there are still a lot of things the older "Live" version does better, so they've lifted the restriction on having to use the Alpha version for the game jam. They also extended the deadline to July 7 to make up for the rough launch.

There are a few more major updates that coming (as of the time of this post), but it's updated enough to at least start learning the basics. @luxapodular released a great tutorial video that should get most people started: https://www.youtube.com/watch?v=cvANBF43KsY&feature=youtu.be

If you've been keeping up with the Alpha's development, or breezed through the tutorial, you may be interested in some of the more advanced concepts and lessons I've come up with.

Helpful Hints

"this" context

If you read my last news post, I went into detail about how the "this" context works in Wick. The Alpha version handles scoping pretty much the same way. If you edit code on a frame, 'this' refers to the frame. If you edit a script on an interactive clip, "this" refers to the clip. If you edit a frame within an interactive clip's internal timeline, "this" still refers to the frame. To control the clip in that case, you can use "this.parentClip".

"script execution order"

When working with different scripts on different objects and layers, it's really important to understand the order in which they will execute.

Execution starts with your top layer, and works down. Each frame will execute it's 'Default' script, then it's 'Load' script, before moving down to the next frame.

Once each frame has called it's scripts, any scripting on clips will fire next. Again this will execute from the top layer down. First, a clip will execute it's 'Default' script, then it's 'Load' script. If your clip's inner timeline has any frame scripting, this will fire next, in the same order your root frames did. Once everything inside your clip has executed, the next clip will have it's scripts executed.

The 'Update' scripts will not start on any frame or clip until the last 'Load' script has completed. 'Update' execution works in the same recursive top-down order as the previous scripts did.

All other scripts are event based, and pretty self-explanatory.

Always be mindful of the execution order. If you create any global objects or methods multiple clips and frames will be calling in their 'Default' or 'Load' events, make sure you have defined them in a higher layer!

"Live preview quirks"

One of the neat features in the Alpha version is that you can test your game from any frame without having to start from the beginning. This is because the editor IS actually your game, it's just not firing any events until you hit the play button to test it.

One unintended side effect of it working this way is that any global values or clip propertied you set, stay set even after you stop testing your game.

If you start a new project, and put the following code on frame 1's Default script:

if (globalValue) {
  
  alert('globalValue is already set');

} else {

  alert('globalValue has been created');
  globalValue = 1; // note that I am only setting it if it doesn't already exist

}

The first time you test your movie, you will get an alert saying "globalValue has been created". The next time you test, you will get an alert saying "globalValue is already set".

Also note: If you ran this test, and opened another .wick file without refreshing the browser, globalValue would still be set.

If you reload the browser and start a new project, you can also see another way this quirk can be a problem.

On frame 1's Default script, pop this code in:

HelloWorld = "Hello you sexy Newgrounds fans!";

DO NOT test your game yet. Make a new keyframe at frame 2 and put the following:

alert(HelloWorld);
stop();

While you are still on frame 2, test your game. You will get an alert that says "undefined". This is because you haven't executed the scripting on the first frame yet, so HelloWorld is not defined.

If you go back to frame 1 and test, it will all work as expected. You can also go to frame 2 and test again, and since HelloWorld has been set globally, it will also work.

Start another new project. On frame 1, draw a circle and make it into an interactive clip. On the clip's Default script, put the following:

alert(this.internalValue);
this.internalValue = "Testing 123";

The first time you test your movie, you will get an alert saying 'undefined'. But after that alert, your clip will have an 'internalValue' property set on it, and the alert will say "Testing 123".

If you use global variables or add properties to Wick objects, you need to be very aware of this quirk when testing. The Wick team is planning on adding a way to test your project in a new, sandboxed instance, like the old Live version did. Until then, make sure your scripts are defining all your properties, and that you test your game from whatever frame you need to have everything reset properly.

And for the love of god, do NOT use SetInterval loops right now. They will keep running after you test your game, and if you aren't clearing them anywhere, they each time you test you will add another loop on top of the one that's already going.

Asset Management

In my last post, I also shared some experimentation I did with ways to manage assets and minimize memory while doing so. I've been playing with the same concepts on the Alpha version, and have another example of how you might build an asset library. This time I incorporated clip recycling.

In my experience, there is always some cpu overhead whenever an engine like this creates an instance of a game object. This example lets you store clips in recycle bins so when you need to use them again, they are already created.

Just like last time, you'll want to make a Default script that handles all your assets on frame 1 of your top layer. Here's the script I came up with (full of comments about what everything does). If you don't really care how it works, you can just copy/paste it and scroll down for examples of how to use it.

// This object will handle our clip library
library = {
  
  // this is the total number of each clip type that can be stored
  // in the recycle bin.
  max_recycled: 10,




  // all our clips and their meta info will be stored here
  items: {},




  // clears everything out of the library
  flush: function(name) {
    if (name) {
      delete library.items[name];
    } else {
      library.items = {};
    }
  },
  
  // clears recycled clips from the library.
  flushRecycled: function(name) {
    if (name) {
      library.items[name].recycle = [];
    } else {
      for(var i in library.items) {
        library.flushRecycled(i);
      }
    }
  },
  
  // adds a clip to the library (or returns false)
  add: function(name,clip) {
    
    // all clips will try calling this method by default
    // so this will return false to let the calling clip know
    // it is not the master copy.
    if (typeof(library.items[name]) !== typeof(undefined)) return false;
    
    // if we get here, this is the master copy. We need
    // to store it and create a recycle bin for it's type.
    library.items[name] = {clip:clip, recycle:[]};
    
    // and now this clip no longer needs to be on our stage at all.
    clip.remove();
    
    // return true so the calling clip knows it is the master copy.
    return true;
  },
  
  // removes a clip from the stage and stores it in the
  // appropriate recycle bin (if there's room) so it can be reused.
  // Note: clips will have a native recycle() method added to them
  // via addToFrame, so you shouldn't need to call this directly.
  recycle: function(name,clip) {
    
    // can't recycle things with no library records
    if (typeof(library.items[name]) === typeof(undefined)) {
      // just remove it
      console.warn('Attempted to recycle a clip with no matching library record: ', name);
      clip.remove();
      return false;
    }




    // used to tell the calling script if this was actually added
    // to the recycle bin
    let recycled = false;
    
    // Put it in the recycle bin if there is room
    if (library.items[name].recycle.length < library.max_cached) {
      
      // if clip has a recycle event handler, call it now.
      // I do it here in case you need to access the parent frame or
      // anything before the clip gets removed.
      if (clip.___custom_events.recycled) clip.___custom_events.recycled.call(clip);
      library.items[name].recycle.push(clip);
      recycled = true;
    }
    
    // remove the clip.
    clip.remove();
    
    return recycled;
  },
  
  // gets a copy of the clip and adds it to the desired frame.
  // if force_new isn't true, will attempt to use a recycled copy.
  addToFrame: function(name, frame, force_new) {
    
    // can't add clips that aren't in the library
    if (typeof(library.items[name]) === typeof(undefined)) return;
    
    let clip;
    
    // see if we can use the recycle bin...
    if (!force_new && library.items[name].recycle.length > 0) {
      clip = library.items[name].recycle.pop();
      
    // create a new copy of the clip
    } else {
      
      // Clone the clip. Note: clip must be on a frame to clone it
      frame.addClip(library.items[name].clip);
      clip = library.items[name].clip.clone();
      library.items[name].clip.remove();
      
      // tell the clip what it's named in the library
      clip.___libname = name;
      
      // add a native recycle method to the clip
      clip.recycle = function() {
        library.recycle(this.___libname, this);
      };
    }
    
    // add the clip to the frame
    frame.addClip(clip);
    
    // if the clip has an added event handler, call it now
    if (clip.___custom_events && clip.___custom_events.added) clip.___custom_events.added.call(clip);
    
    // return the clip reference
    return clip;
  },
  
  // This method lets you apply methods from a single object, to
  // any copies of your clip. It should help keep memory optimized and
  // let you organize your code however you prefer.
  applyMethods: function(clip, methodObject, onEvent) {
    
    // if this is a recycled clip, we can skip all of this.
    if (clip.___custom_events) return;
    
    // we have a few custom methods that aren't native to Wick
    // this sets those up.
    let custom_events = ['added','recycled'];
    clip.___custom_events = {};
    
    // check our methodObject for all it's values
    for(var i in methodObject) {
      
      // if the value is 'extend', we treat it like a
      // class extender and just apply all the values verbatim.
      if (i === 'extend') {
        for(var e in methodObject[i]) {
          clip[e] = methodObject[i][e];
        }
      // if the value matches one of our custom events, store
      // it in our custom object
      } else if (custom_events.includes(i)) {
        clip.___custom_events[i] = methodObject[i];
      
      // anything else, we just assume is the name of a
      // native Wick event, and set up an onEvent handler
      } else {
        onEvent(i, methodObject[i]);
      }
    }
    
    // This clip will already be on the stage, so we call
    // the 'added' handler (if it has one)
    // to ensure it gets initialized properly
    if (clip.___custom_events.added) clip.___custom_events.added.call(clip);
  }
};

To use the library script, you need to create an interactive clip to represent a game object, and a JavaScript object containing any code your asset needs. You can simply code for the baked in Wick events like 'update' and 'mouseclick', or use the 'added' and 'recycled' events that the above library script will add to the mix.

Here's an example JS object that will make a clip start at the left side of the screen, move right, then remove itself when it reaches the end of the screen. Just for fun, we'll also make it remove if we click on it.

FlyingThing = {
  
  // We could use Wick's "load" event, but that will only fire the first time a clip is
  // created.  "added" fires any time the library adds the clip to a frame.
  added: function() {
    this.x = 0; // start on the left
    this.y = root.height / 2; // center vertically
  },

  // this will use Wick's baked in 'update' event
  update: function() {

    this.x += 20;

    // check if the clip has reached the end of the stage...
    if (this.x > root.width) {
      // Our library script adds a recycle method to any clips it creates!
      // This will remove the clip from the stage, but keep it so we can reuse it later.
      this.recycle();
    }

  },

  // uses Wick's 'mousedown' event
  // TIP: mousedown/mouseup work better than mouseclick if you are trying to click moving objects
  mousedown: function() {
    // remove the clip if we click it.
    this.recycle();
  }

}

So now we have an object with scripts that can control a clip. The next step is to create an interactive clip. For simplicity sake, just make a circle. On your clip's Default script, put the following code:

if (!library.add('flying_thing',this)) {
    library.applyMethods(this,FlyingThing,onEvent);
}

There's a few things going on here. The first line calls library.add, and passes a string (flying_thing) and a reference to the clip itself. This tells the library we will be referring to this clip as 'flying_thing' when we want to create instances of it.

When the library script creates clones of our clip, this script would run again, which is why it is wrapped in an if statement. Once a clip name is set in the library, calling library.add will return false. When this runs on our master clip, it will actually remove the clip from the stage and keep it in memory. You don't have to worry about hiding it, or keeping in on a super long frame like the example in my last post.

The next line of code only gets executed the first time a clip is added to the library. This line tells the library to apply the methods in our FlyingThing object to the new copy. We pass a reference to the clip, the behavior object, and the onEvent method. That part is important, because the library needs to be able to run onEvent to set any baked-in wick event handlers.

So now we have a 'flying_thing' asset in our library. Make a new frame, and put the following code on the Default script:

onEvent('keypressed', function () {
  // check if spacebar was pressed
  if (key === " ") {
    // add a copy of our flying_thing to the frame
    let thing = library.addToFrame('flying_thing', this);
  }
});

Now, whenever we push the space bar, our script will call library.addToFrame(). The first parameter tells it wich asset we want, and the second tells it what frame to add to. In this case we just use 'this' for the current frame.

IMPORTANT NOTE:

When your library script is run, it creates a global variable. Any time you add an asset to the library, that reference will stay in memory, as will any recycled copies, unless you run your game from frame 1 again. Running from frame 1 will re-declare the library object, leaving the old one for garbage collection.

You don't need to test your game from frame 1 unless you have made any changes to your clip or its behavior object. If you test your game, and see old versions of things, this will be what happened.

Also, if you haven't run the game starting at frame 1 at all, but test from a later frame, the library object will be undefined and cause problems.

So, lets just go ahead and test our game from frame 1 to be safe. When your game is ready, go ahead and hit the space bar a few times. You should see a copy of your clip move across the screen each time you hit space.

Cool right?

But that's not all this library script can do. You can add a 'recycled' method to your behaviors and maybe use that to update a score. You can add 'mousehover' and 'mouseleave' events to change the view of your clip.

The other cool thing you can do is extend the clip itself and add new methods and properties. You do this by adding an 'extend' object in your behavior object.

Let's say my game was going to have multiple ways to "kill" an object. I would probably want a single function that handled the object's death. I would start by adding this to our behavior object:

  extend: {
    killMe: function() {
      // here I could play a sound, update a score, whatever...
      this.recycle();
    }
  }, 

And then I would update our existing mousedown method to use our new killMe function.

  // uses Wick's 'mousedown' event
  // TIP: mousedown/mouseup work better than mouseclick if you are trying to click moving objects
  mousedown: function() {
    // remove the clip if we click it.
    this.killsMe();
  }

Now anything else that can kill the clip could do so by calling clip.killMe().

You can see a similar demo in action if you download this .wick file and open it at https://alpha.wickeditor.com/

This demo also shows how it plays with different layers, so you can get an idea on how you'd handle foregrounds and backgrounds.

ANOTHER NOTE:

The Wick team is planning on adding some sort of library management in the future. Don't be surprised if this library becomes obsolete. Either way, it was a fun experiment, and may be useful to people using the current build for the game jam!

I've been playing with Wick Editor a bunch, trying to get some simple Newgrounds.io API widgets working in advance of the Wick Editor Game Jam.

Edit: The Newgrounds.io widgets are available for download now!

One of the appealing things about Wick Editor (besides being 100% free) is how similar it is to older ActionScript 2.0 versions of Flash, but it's definitely lacking a few things, and has a bunch of quirks.

So I wrote up a couple chapters/tutorials for using Wick Editor that may help people used to working a certain way in Flash, or other game frameworks.

Understanding "this" context

One of the most jarring things for me was figuring out what the 'this' scope refers to in different places.

In AS2 Flash, you could select a MovieClip and put code directly onto it with functions like onClipEvent(load) and onClipEvent(enterFrame). Within this code, if you used 'this', it would refer to your MovieClip instance.

In Wick Editor, you can do just about the same thing. You can put code directly on a Clip using 'function load()' and 'function update()'. Just like in Flash, using 'this' will refer to your Clip instance.

Now, if you were to try putting code on the timeline of your respective clips, you hit a major difference. If you add scripting to a key frame within a MovieClip, 'this' still refers to the MovieClip instance.

In Wick Editor, if you put code on a key frame, 'this' actually refers to the frame itself, not the Clip. To reference the clip from code on a keyframe, you instead need to use this.parentObject.

This is important to remember, especially if you put code on multiple key frames and expect it to reference code from older frames. Using 'this' on a Wick Frame literally only refers to that frame.

Let's say on frame 1, you use the following code:

this.alert_text = "Hello World";

Then on frame 2, we call:

alert(this.alert_text);

The alert will say 'undefined', because each Wick Frame is a separate object.

If you instead do this on frame 1...

this.parentObject.alert_text = "Hello World";

... and this on frame 2...

alert(this.parentObject.alert_text);

You will get the expected Hello World result.

Scoped Variables

Flash never really had global variables. If you wanted something to be universal, you would set it with _root.varName = "value";. Also, any variable not attached to an object, or _root, had to be declared with var varName = "value";

Because Wick Editor really just uses JavaScript, there's a bit of a difference in variable scopes and how to use them.

Any variable you set without a 'var' or 'let' declration, will be a global variable. (TECHNICALLY, it's attached to the Window object, but for all purposes, this is considered global).

If I write the following ANYWHERE in my code...

alert_text = "Hello World";

...I can access that value from any frame or object, no matter what (at least after it's been set).

If I write

var alert_text = "Hello World";

It's only accessible by whatever scope it's written in, or anything below that scope. If I wrote it at the top of a script on frame 2 of my timeline, only code in that frame could access it. If I put any functions in that same block of code, they can access it as well. If I put it within a function, code outside of that function would not be able to access it.

Examples:

var outer_value = "outer";

function test_inner() {
    var inner_value = "inner";

    alert(outer_value); // alerts 'outer'
    alert(inner_value); // alerts 'inner'
}

test_inner();

alert(outer_value); // alerts 'outer'
alert(inner_value); // alerts 'undefined'

Extending Clips

One big thing lacking from Wick Editor is a way to attach an external script to a clip, like Flash's 'Export for ActionScript' would let you do. There's lots of ways you could work around this, but you always want to keep duplicate code and memory management to a minimum.

One way to do this is to write single functions for controlling objects you intend to use in multiple places, such as a game enemy.

Because there's no support for external js files yet, I found the best way to do this, and keep things organized, is to create a layer and a single key frame for every object I want to write code for.

So I might add a layer and name it "Enemy1 Code". Then I'd add a keyframe on frame 1 and add this code to it:

Enemy1 = function() {

    // prevent this stuff from running more than once.
    if (this.extended) return;
    this.extended = true;

    // fires when the sprite is loaded
    this.load = function() {
        // start at the left side of the screen
        this.x = 0;
    };

    // fires every game tick
    this.update = function() {
        // move the thing sideways, just to show this works.
        this.x += 10;
    };

};

Now I would create a new Clip. It would have to be on a lower layer, or later frame to ensure the above code had a chance to run. I would double click the Clip to edit it, and on it's first frame, I would add this code:

Enemy1.call(this.parentObject);

If you test your game, your object should see your Clip slide across the screen.

One thing I figured out is any code you put in a Clip's first frame will execute before it's load and update methods. If you put the code on the clip itself, this isn't always the case.

So what we are doing is using JavaScript's call method to execute all of the code in the global Enemy1 function, using the Clip instance as the 'this' scope, before the Wick engine calls it's load or update methods. When the Clip has loaded, those methods are ready to go.

That worked pretty well, but I realized if I ever wanted to clone this Enemy1 clip, it would create new versions of the load/update functions for every instance. This could mean a potential memory leak, and we want to avoid that.

The next thing I did was move those into static functions attached to the Enemy1 function object, and just reference them in the main Enemy1 function. Since we're referencing static functions, they won't need to be created for each instance anymore:

Enemy1 = function() {

    // prevent this stuff from running more than once.
    if (this.extended) return;
    this.extended = true;

    // fires when the sprite is loaded
    this.load = Enemy1.load;

    // fires every game tick
    this.update = Enemy1.update;

};

// these always exist, and won't need to be re-created for every instance
Enemy1.load = function() {
    this.x = 0;
};
Enemy1.update = function() {
    // move the thing sideways, just to show this works.
    this.x += 10;
};

Faking a Library

One glaring omission to how Wick Editor currently works is the asset library only holds your image and media files. In Flash it contained all the Graphics, Buttons and MovieClips you created, and you could attach names to them so you could dynamically add them to your stage.

Wick doesn't have anything like that right now. The best you can do right now is make all of your clips, and hide them off-stage somewhere, cloning them as needed.

Using this method, you want to make sure your "library" of clips aren't executing any significant code, but make sure when you clone them that they behave as expected.

I figured a great way to do this is to create a master LibraryAsset function that could handle registering clips and creating new instances with a subclass attached.

I ended up making a little demo where a bunch of space ships fly across the screen at varying scales and speeds.

To start, I made my global LibraryAsset function:

/**
 * name - The string name you will use to get clones of the asset
 * clip - A reference to the actual Wick Clip
 * subclass - A reference to the subclass this asset will use when cloned
**/
LibraryAsset = function(name, clip, subclass) {
    
    // only add a clip once
    if (LibraryAsset.assets[name]) return false;

    // make a reference to the subclass we'll be using
    clip.subclass = subclass;
    
    // make me invisible, just to be safe
    clip.opacity = 0;

    // store a reference to the clip by name
    LibraryAsset.assets[name] = clip;
};


// stores references to our library assets
LibraryAsset.assets = {};


// Use this to get a cloned asset, by name, with it's subclass applied.
LibraryAsset.get = function(asset_name) {
    
    // throw an error if we try getting an undefined asset.
    if (typeof(LibraryAsset.assets[asset_name]) == 'undefined') {
        throw('Invalid asset name: ' + asset_name);
    }
    
    // get a reference to the asset clip we want
    var asset = LibraryAsset.assets[asset_name];
    
    // create a clone
    var clone = asset.clone();
    
    // make it visible
    clone.opacity = 1;
    
    // apply the subclass so the clone actually does stuff.
    asset.subclass.call(clone);
    
    return clone;
};

Then I made the subclass to control my space ships:

Ship = function() {
    // reference our static functions to save memory
    this.load = Ship.load;
    this.update = Ship.update;
};


// on load, we want to set a starting position, scale & speed.
Ship.load = function() {

    // set the starting position
    this.x = -100;
    this.y = randomInt(0, project.height);
    
    // scale our ship and set it's speed
    var scale = randomFloat(0.5, 1);
    this.speed = 30 * scale;
    this.scaleX = scale;
    this.scaleY = scale;
};


// on update, we make the ship move right until it's off-screen, then reset it
Ship.update = function() {

    // move the ship
    this.x += this.speed;

    // if it's off-screen, call our load function again
    if (this.x > project.width + 100) {
        this.load();
    }
};

Next I drew my space ship and made it into a Clip. I double clicked that to edit it, and on the first frame I added the following code:

LibraryAsset('ship', this.parentObject, Ship);

This basically told my LibraryAsset function that I want this Clip to be called 'ship', and to use my Ship subclass to control it.

If I test my game at this point, I basically have a blank screen because the LibraryAsset function hides my ship, and it isn't using the subclass at all right now.

To finis the demo, I added this code to the root timeline:

for(var i = 0; i < 20; i++) {
    var ship = LibraryAsset.get('ship');
}

This gets 20 copies of my ship asset WITH the subclass applied. When I test my game now, I have a screen full of ships zipping across as intended.

You can see my working demo and grab the .wick file at https://www.newgrounds.com/projects/games/1327369/preview

Hopefully somebody finds my experiences with Wick Editor useful and is inspired to make something cool for the game jam!

#aftertheweekend

And so we reach the final Monster Monday of 2014.  Follow me on Twitter (@Psycho_Goldfish) and RT this week's monsters to your followers! And be sure and follow these great artists here on NG!!!

This week's picks:

http://www.newgrounds.com/art/view/thespazicat/good-ol-nosferatu
Good Ol' Nosferatu by @thespazicat

http://www.newgrounds.com/art/view/m-vero/sinister
Sinister by @Daverom

http://www.newgrounds.com/art/view/kkylimos/the-dimorteli-brothers
The DiMorteli Brothers by @Kkylimos

http://www.newgrounds.com/art/view/deathink/chuckenstien
Chuckenstien by @deathink

http://www.newgrounds.com/art/view/farturast/halloween-2012
Haloween 2012 by @FatrurAst

I forgot to post last week's Monster Monday picks so I'll toss them in here:

http://www.newgrounds.com/art/view/jazza/this-is-halloween
This is Halloween by @Jazza

http://www.newgrounds.com/art/view/xaltotun/pumpkin-golem
Pumpkin Golem by @Xaltotun

http://www.newgrounds.com/art/view/jakubias/mountain-of-goats
Mountain of Goats by @Jakubias

http://www.newgrounds.com/art/view/pkshayde/r2-d2-zombie
R2-D2 Zombie by @PKShayde

http://www.newgrounds.com/art/view/thepsychosheep/dasha
Dasha by @ThePsychoSheep

So I totally dropped the ball on Monster Monday this week, because I have other shit to do.  But I'm making up for it today with Wicked Wednesday.

Here's a taste of what I'll be posting on twitter today (follow me @Psycho_Goldfish):

http://www.newgrounds.com/art/view/liransz/wickedly-drawn - You should totally be following @liransz she has tons of great halloweenish art in the portal.

http://www.newgrounds.com/art/view/hungercat/xenomorph - @Hungercat also has a nice collection of monster art.

http://www.newgrounds.com/art/view/jackaloftrades/scorching-the-evil-snowman - @jackaloftrades brings us this Christmas-o-ween classic.

http://www.newgrounds.com/art/view/theshadling/hatred - Because @theShadling can indeed draw more than boobs damnit!

http://www.newgrounds.com/art/view/mindchamber/demonic-p-bot - @Mindchamber even includes a short story with this pic.

http://www.newgrounds.com/art/view/wolfenheim/demongo - Any Samurai Jack Fans out there? @Wolfenheim has lots of great fan art you should check out.

http://www.newgrounds.com/art/view/sabtastic/grasp-of-the-dead-hand - @Sabtastic brings us her take on one of the scariest moments in ANY Zelda game ever.

If you have any favorite monster/halloween themed art to share on the Twitters, post it with the hash tag #WickedWednesday and I'll try and re-tweet you.

I've also announced an epic contest with an amazing prize for this year's PsychoGoldfish Day:

http://www.newgrounds.com/bbs/topic/1352573/3#bbspost25264576_post_text

Every monday for the duration of October, I'm planning on showcasing some of the great monster-oriented content we have here on Newgrounds.  Follow me on Twitter (@Psycho_Goldfish) and either retween my posts or add your own with the #MonsterMonday tag!

Here's some monsters for this week:

http://www.newgrounds.com/art/view/splosh999/swampish

http://www.newgrounds.com/art/view/gcs-wt/omden-moden

http://www.newgrounds.com/art/view/splosh999/coookiiieeeeesssss

http://www.newgrounds.com/art/view/letal/second-photoshop-painting

http://www.newgrounds.com/art/view/rickmarin/the-monster

With the current boom of popular indy games being produced on Steam, Mobile, and the latest game consoles, I am often remonded that many of these games owe a lot to classic browser games for creating and/or popularizing new or overlooked genres.

One of my guilty pleasures these days is playing endless runners on my tablet.  Games like Jeypack Joyride and Zombie Tsunami are a lot of fun, but I can trace my love for the genre back to Dino Run and Canabalt.

What brower games made you guys fall in love with a new game genre?

So now that the fancy new blog stuff is working, we are also ready to debut CONTENT EMBEDS!

Currently this only works on movies with video files and audio submissions.

To embed something, look below the video/audio player for the embed icon. (If it's missing, the author doesn't want theor movie embeddable)

Copy paste the size you want (Note: Large and Medium movie embeds will be scaled down to fit the width of a blog post.)

And violla! 

ICookAtHome.net

So I started playing Transformers: Fall of Cyberton yesterday and I am having a really hard time staying away from it and getting any work done.

The story so far is great, and there's almost a seamless transition when you switch from the autobot campaign to the decepticon. Its all just one continuous story told from both perspectives.

I find myself nerding out a lot, so many fun moments so far. For example, in the later Optimus Prime levels you have to haul ass in truck form to reach some objectives. On the way you can just run down decepticons and they go flying. I found myself re-enacting this scene from the transformers movie, complete with the aerial transformation/flip attack and an awesome rendition of "You got the touch"

I also re-created optimus dying... a lot...

There's also some fun easter eggs. In one place you can sit down and watch TV while your base is being attacked because NOBODY MAKES ME MISS MY SOAPS!

There's another fun one where a door switch transforms into a retarded dancing robot that had me laughing pretty good.

The characters play mostly the same, but the unique special abilities they get vary enough to really change the play style for each character's levels.

You can't get into cover Gears of War style, but you CAN switch your gun arms, so you can use cover without needing to be glued to it.

I'm not even half way through it yet, but I'm hooked. And I haven't even wet my dick in the multi-player yet.

This is definitely a must own for transformers nerds, and anyone who enjoys a good 3rd person shooter will have a lot of fun with it too. Maybe I'll see some of you on XBL.