Click Here to Refresh

Today, I’m going to focus on the art of practising intelligently.

Practice Often

I consider this the most important piece of advice, yet also the most obvious, that I can offer you. You aren’t born with great mathematics abilities, you need to develop them! Scientists are learning more and more that the brain is very adaptable, and never stops changing. By practising calculus often,  you’re creating new connections, reinforcing good habits, and speeding up the logical thinking necessary to solve problems efficiently.

Like any habit, the more often you exercise it, the more your brain makes it natural. This means practising at different times of day, and practising on a consistent basis.

Practice Thoroughly

Textbooks contain thousands of problems for a very good reason; because you’ll need to drill the fundamentals of calculus into your head. It isn’t sufficient to understand why a certain theorem or law exists; you need to use it over and over again until you know it and understand it personally & intuitively.

In calculus textbooks, you’ll often have different types of problems for each chapter:

Problems that help you understand a theorem or technique

These are very important to do. They’ll let you know if you understand the basic premise of the chapter.

Problems that give you the opportunity to put it into practice

This is the meat of the chapter. It’s the drill that will commit the technique to your mind. Do all of these.

Problems that apply the technique to real-world problems

I personally don’t find these very important. They might be helpful if you’re having a hard time finding the practical application of a technique. It will probably be more helpful to kinesthetic learners.

Challenging or integrative problems

These are very useful as review problems. They will let you know if you’re ready for an exam, or to move on to the next chapter.

How to Practice

I follow these steps when going through the problems section of my textbook:

1. Start from the beginning
2. Do each problem one after another, checking to see if you have the right answer after each
3. If you make a mistake, redo the problem the right way. Otherwise, you’re not learning from your mistakes.
4. Don’t move on to the next problem until you 100% understand your mistakes in the last one
5. You may skip a question only if the answer comes very naturally to you

Don’t get frustrated from your mistakes. You have to understand that making mistakes is one of the most important parts of learning. In other words, you must make mistakes. Everybody, even the most gifted, make mistakes.

Also, try to always end a practice session if you’re too tired to concentrate well. Pressing on when you brain is not in an awareness state is like trying to clean a spill using a water saturated cloth. All you’ll end up doing is spreading the spill.

Conclusion

I hope I’ve helped you become a better math student. I appreciate any feedback.

For those interested, in order not to lose my SEO ranking for gamedevelopersweb.com, I followed these steps:

1. I exported all the posts/comments/categories from GameDevelopersWeb.com and imported into a local installation of WordPress
2. I reworked the categories and adjusted the theme to fit my personal website blog
3. I exported them from my local installation into MichelCarroll.com
4. Quickly after, I added a .htaccess 301 rule for each page and article on GameDevelopersWeb.com, including the root domain
5. I logged into Google Webmaster Tools, and advised them that the domain name change had been made

I’ve yet to see the results of this, so I hope the domain change will go seamlessly.

The Path to the Castle – Concept

First, let’s give ourselves an idea of what the path is going to need to be, so that we’re better prepared to code it.

Conceptually, here’s what its role is in the game:

• A logical set of way-points for the orcs to follow in order to reach the castle
• A logical separation between the orcs and the archers
• A visual path, so that the player knows where it begins and where it ends

Let’s try to keep the code as simple as possible, so that we don’t get tangled in our own logic. In my opinion, the simplest way to represent a path here is as a set of way-points. Here’s an illustration of what I mean:

The big dots represents coordinate points, which we’re going to represent logically as an array of points. The dotted lines mean that the points are connected sequentially in our game logic to form a linear path.

In order to have a nice background, and to not have to worry about rendering a castle later on, let’s use a static image background in which to display the game on. We need to keep in mind the size of the image when creating/using a background image, because shrinking/growing it might distort the image. I’m going to make my image 640 x 480, which will also be the size of my game stage.

Using my master programmer artistic abilities, I present to you with my map:

(if you find it too embarrassing, feel free to make/use your own)

Notice how I tried my best to keep the width of the path constant, so that we have an easier time mapping the way-points with the image later on.

It’s now time to get down to the code.

The Path to the Castle – Coding

First of all, lets move the image file into our project, and render the map to our browser.

Let’s create a new folder inside the root of our project called images, in which we’ll move map.jpg to:

Then, lets modify our existing code a bit to render the map using an Image class and a Bitmap EaselJS object. An Image object is equivalent to an img HTML tag; Javascript uses it to link to images. The Bitmap object is part of the EaselJS namespace; it’s responsible for knowing what to display and where to display it on the stage:

loadGame = function() {
	var canvas = document.getElementById('main');
	stage = new Stage(canvas);

	var mapImg = new Image();
	mapImg.src = "images/map.jpg";

	var mapBitmap = new Bitmap(mapImg);
	mapBitmap.regX = 0;
	mapBitmap.regY = 0;

	stage.addChild(mapBitmap);
	stage.update();
};

After refreshing, you should now see the map render on your browser.

Now, using an image editor, I’ve determined where our path coordinate points are going to be . Essentially, using the pixel coordinates (x,y), I took note of where each node is situated. Here they are, in Javascript list form:

var coordinates = [
	[200, 0],
	[177, 127],
	[289, 152],
	[480, 100],
	[566, 131],
	[575, 250],
	[362, 262],
	[78, 310],
	[80, 394],
	[288, 400]
];

Using this list, and a simple looping function, lets render lines where the path is going to be, so that we can validate that the waypoints are accurate. Here, I’m creating a line for each pair of coordinates. Each line is a separate shape that needs to be added separately to the stage in order to render correctly.

Think of the Graphics object as the computer’s pen. Here’s what I’m doing step by step:

1. I change the thickness (setStrokeStyle) of the pen to 1
2. I move the pen to a new location (point 1), without actually drawing (moveTo)
3. I put my pen down, and give it a red color (beginStroke)
4. I draw all the way to point 2 (lineTo)
5. I commit the Shape to the stage (addChild) before drawing a new one

var g = new Graphics();

for(var i = 1; i < coordinates.length; i++)
{
	var s = new Shape(g);
	s.x = 0;
	s.y = 0;

	var point1 = coordinates[i-1];
	var point2 = coordinates[i];

	s.graphics
		.setStrokeStyle(1)
		.moveTo(point1[0], point1[1])
		.beginStroke(Graphics.getRGB(255,0,0))
		.lineTo(point2[0], point2[1]);

	stage.addChild(s);
}

stage.update();

I put this logic right after the code that renders the map, so that the lines appear on top of the map, and not under.

Here’s what should be the results:

Success! Our coordinates are very accurate!

Conclusion

Now we’re ready drawing orcs, and make them follow the path. This is going to be the next part. Until then, feel free to try it out on your own using what you know so far.

Here’s the source code of my project at this point: Source Code

Among the existing sets is Latin Prefixes & Roots. Since I’ll be studying biology next term at school, I figure learning  Latin prefixes will give me an edge. Rather than memorizing all those terms, it might help me better understand where they come from instead. Good deal.

I mocked this up while I was getting my hands dirty in NodeJS. If I had to do something similar now, I would probably go with Socket.IO.

Command-Based Architecture using Comet

Game Concept

Orcs are coming to destroy your castle. You must train and position archers to slow their advance until the cavalry come.

Game Elements

• Orcs come in waves.  At the end of the wave, if the castle is still standing, the player wins.
• Orcs come in different varieties: slow, fast, strong, weak, gold loot.
• Archers come in different varieties: strong, long range, slowing effect, cost.
• Orcs follow a predetermined path leading to the castle.
• Archers stay from one round to the next, but can be sold back for half its cost.
• Archers can be positioned anywhere on the map not within X feet from the path.

Now that the requirements are put down on paper, let’s make a quick sketch of how this game is going to look like.
This will give us some insight on which visual elements will need to be defined, and their relationship to one another.

After some quick white-boarding, the game’s concept is much clearer in everybody’s mind. This is often a good way of brainstorming an interface and game flow, especially for visually dominant people like me. If you don’t already have a white-board in your office, I strongly recommend you purchase one.

Please note that for the sake of simplicity, I’m not putting a lot of emphasis on the game assets, such as the images. In other words, I know I’m a crappy artist, give me a break here…

Setting up your project

I’ve chosen to use WebStorm, an IDE specializing in Javascript. You can, of course, use whichever environment you’re comfortable with.

Important!!

In order to correctly run this application, it’s going to need to be accessed through a web server (even your localhost will do). The reason for this being that the application will fetch image files in a different way than a normal HTML website. What I did was download an use WAMP, an easy to install Windows linux server. I then moved my project folder inside C:/wamp/www/, and access it through the address http://localhost/tower_defense/.

I like keeping my file hierarchies simple and standard. Generally, I’ll keep all my source files inside a folder called src, and I’ll have a folder called vendor in the root of my project where I’ll put all third-party libraries inside. You can download the EaselJS library from either their Github repository or directly from their website. You can then place the contents of the library inside a folder called easeljs inside vendor.

This being a Javascript project, we’ll only need one HTML page to display the canvas. Per convention, we should call that one index.html.

Here’s a quick look at the file structure so far:

The index page will need to reference both the EaselJS library as well as our own game code. EaselJS ships with a minified file  containing the entire library. One of the reasons they do this to make it easy for programmers to include it in their project. The minified file is contained inside the lib folder, and is called something similar to easeljs-0.4.2.min.js (yours might be a different version).

Lets also create a blank Javascript file inside src called main.js which will later be responsible for initiating the game, and putting all the game components together.

Lets modify the index.html file to include both easeljs and our main JS file:

<html>
<head>
    <title>HTML5 Tower Defense</title>

    <script src="vendor/easeljs/lib/easeljs-0.4.2.min.js"></script>
    <script src="src/main.js"></script>
</head>
<body>
</body>
</html>

So far so good. To complete the setup, lets initiate a canvas, and draw a shape into it using an EaselJS function to make sure our pieces are working well together.

We’re going to add a canvas to the index file, call it main by setting it an ID. We’re all going to run a function called loadGame on body load. Here’s what it will look like:

<body onload="loadGame()">
    <canvas id="main" width="800" height="600"></canvas>
</body>

In our main.js, we’ll create a loadGame function that will simply initiate the canvas scene and draw a circle inside of it.
Don’t worry if you don’t understand what’s going on in this function yet; the tutorial will go more in depth in the later posts.
This is mainly used as a test to make sure the setup is correct.

loadGame = function() {
    var canvas = document.getElementById('main');
    stage = new Stage(canvas);

    var g = new Graphics();
    g.setStrokeStyle(1);
    g.beginStroke(Graphics.getRGB(0,0,0));
    g.beginFill(Graphics.getRGB(255,0,0));
    g.drawCircle(0,0,3);
    var s = new Shape(g);
    s.x = 100;
    s.y = 100;
    stage.addChild(s);
    stage.update();
};

If when you visit the web adresse (http://localhost/tower_defense/ in my case), you see a small red circle, your setup is complete. If not, open up the Javascript console (Ctrl-Shift-J in Chrome), and verify that the page isn’t throwing any errors.

That was the first part of the tutorial. Let me know in the comments if you have any comments, suggestions, or need help.

Here’s a link to part 2.

You may download the source code here: https://github.com/MichelCarroll/SimpleEaselJSGame

Here’s the game embedded inside the page, as a demonstration of how easy HTML5 games are to publish seamlessly on the web:

Basically, this method is meant to insure that adequate time is spent on the most important aspects of game development. Also, by keeping the iterations as short as humanly possible, I’m injecting as much feedback into the loop as I can.

The first step, the design phase, lets the developer plan out the next feature of his application (or the basic outline if he hasn’t already done so). I estimate that this part shouldn’t last longer than 25 minutes. This step should ideally begin with a mini-brainstorming session, followed by filtering the most captivating feature out, and expanding on it. It should focus on the user experience, and not the technical aspects. However, a gut feeling of whether it’s a small enough enhancement will definitely come in handy to keep the iteration short.

The second step is the planning & redaction of a set of function tests to ensure the correct functioning of the feature. This forces the developer to imagine and expand the end result before committing to it. I anticipate this step to take 15 minutes. According to TDD (or test-driven development), this is an essential exercise in order to forge a perfect user experience. Also, the test will make sure that the feature isn’t broken when come the time to add more. However, an iteration might be chosen to re-work/replace a feature, in which case perhaps the functional test will be re-worked itself.

The third step is the planning & redaction of a set of unit tests to ensure the correct functioning of the individual units inside the application. I anticipate this step to take 10 minutes. This step, like the last, forces the developer to be proactive, and to imagine the simplest set of objects that should be required to accomplish this goal. This is also a TDD practice. At this point, the developer should have began imagining how this feature will fit into the application, and its exact implementation. However, the thinking should remain abstract, in order to make the application easy to understand to prying eyes.

The fourth step is to finally start implementing the feature into the application, and make the new function & unit tests pass. According to TDD, at first, the developer’s sole purpose should be to make the tests pass, no matter how simplistic the code chosen to do so might be. The relevancy of this is to keep the implementation as simple as possible, and not code things that don’t need to be coded. I’m thinking that it should take around 10 minutes.

This fifth step(s) of the method are the refactoring steps. This step is repeated 4 times in a row, each lasting 5 minutes. During the phase, the developer sets out to make the code more robust, clean, and separate the responsibilities where they belong. Now that I think about it, this step should definitely be clocked at no more than 20 minutes, but can be divided in smaller cycles (2-4 minutes), or bigger cycles (6-8 minutes) depending on the size of the re-factor.

The sixth (and my favorite) step is to play the game! If the developer isn’t ready to take his creation out on a test run, he should perhaps rethink his initial purpose in creating a game. Plus, this lets him see the application from the user’s perspective, which will let him better design the next feature when come the next iteration. Even if the game is small/simple that that point, I think it’s important to at least spend 10 minutes playing through the actions, and giving yourself feedback on the strong points/weak points of the game. One should focus on having fun at that point, but also imagine possible improvements to the game.

The developer should ideally move directly to the feature design step after having test-played the game. The reason for this is that the game experience is still fresh inside the developer’s psyche, so designing the next feature will definitely be more effective. A break can be taken afterwards.

Hope you enjoyed this!

We just don’t see the benefit until it’s staring at us in the face!

You’ll be glad to know that I’ve found a cheat code to achieving life goals. Read on if you’re ready to change your life for the better!

The Secret? The Same Way Video Games Keep You Hooked

Remember the last time you completed a level in a video game? Satisfying, isn’t it?

Can we apply the same mentality to personal goals? Yes!

I’ve developed a technique inspired from video games. Let me show you how it works:

The Principle

Our goals get forgotten about because the value is too far to keep us motivated. Video games know excellent techniques to keep you playing to the very last level.

Here are the primary ones:

• Visual progress bar
• Incremental rewards
• Specific & achievable goals

I’m going to introduce you to a goal achieving strategy that uses all 3 of these elements.

1. The Mighty Progress Bar

When you’re doing the right thing, video games let you know right away. Most games use a progress bar to do this.

When you can’t see progress being done, your brain sees the goal as either being 0% done, or 100% done. We’re all wired this way.

However, progress is always incremental! And making progress obvious is the key to giving yourself immediate feedback. This is why progress bars are so effective.

Here’s a basic progress bar I currently use for one of my goals:

2. The Incremental Reward System

Visually showing goals being achieved is motivating, but not as much as obvious rewards.

The brain also needs to be constantly reminded of it’s purpose. That’s why good game designers use rewards to keep players motivated.

I’ve added 3 incrementing rewards. Here’s my updated progress bar:

Your rewards don’t need to be excessive, but they need to be convincing.

Ideally, these rewards compliment the effect of achieving the goal. IE: the mountain bike is enjoyed more fully in a fit & exercised body.

Take that, evasive mind!

3. The S.M.A.R.T Goal

S.M.A.R.T is an acronym for the most important characteristics a goal must possess in order to maximize it’s power:

S pecific
M easurable
A cheivable
R ealistic
T ime sensitive

Video games are no fools when it comes to defining goals. If they were, the players would quickly get confused, discouraged, or annoyed, and leave!

Isn’t that what often happens to personal goals?

Don’t fall for it. Be smart! (pun intended)

Instructions

Use this tool wisely – You may actually get what you wish for!

1. Choose 2 Goals to Begin

By choosing too many, you risk overwhelming yourself. Oh, and remember to make sure your goals are S.M.A.R.T!

2. Draw a Huge & Fancy Progress Bar on a Big Paper, or Whiteboard

Notice that I didn’t mention using a computer/PDA? That’s because our brains have an extremely short attention span when it comes to computers/gadgets.

Trust me. Offline is better for our purpose.

3. Fill in your goal, units of increment, and progressive rewards

Think long & hard about your rewards. Make sure you will deliver the promise.

4. Display the bar where you’re sure to notice it everyday.

The office or bedroom is often a good idea.

5. Make marking down progress a daily ritual

When you get a part done, mark it as soon as you can.

6. Always deliver your promised reward

Very important! If you skimp out at that glorious moment, you risk losing motivation & momentum.

In Closing

Please comment out your thoughts & feedback. I really wants this strategy to work for well for me as for everybody else reading this article.

If I can get enough positive feedback, I will post a second part to cover more information & scenarios.

Cheers