3:07 pm
Internet Explorer 6 has been in use for a whopping eight years, during which time the internet has grown both in size and in usability. So here we are, with 25% of people still using IE6 which hardly even begins to support modern CSS techniques.
For a long time, designers have found different ways to target IE6 and its slightly improved (but still seriously lacking) predecessor, IE7, and feed them different CSS to fix any bugs that the browsers have with normal, up-to-date styling. A popular trick is to use IE’s conditional comments to give IE6 and/or IE7 a different stylesheet. This works fine, except that it means that you need to make two stylesheets for your designs. There is a way that is less widely known that exploits the star-html hack combined with CSS 2.1 selectors to differentiate between IE6 and IE7. It looks like this:
element {
/* Standards-Compliant Properties Here
}
* html element {
/* IE6 Properties Here
}
*+html element {
/* IE7 Properties Here
}
Basically, IE6 and IE7 both think that there is an element above the html element, which is nonexistent in other browsers. So the * html selector is used to target IE6 and 7. To single out IE7, a CSS 2.1 selector (*+html) which is unsupported by IE6 can be used.
The CSS-only technique is a lot less of a pain than using a separate ie6.css file for all of your hacks. Anyway, that’s just a helpful hint I just figured out.
12:30 am
I just wrote a post about how to make sure that someone using your contact form is human, which utilized a validation image. While this is effective, it requires the user to spend an annoying 10 seconds deciphering the text and typing it in. Web Design From Scratch has a very clever solution.
The trick is to use javascript to make sure that the user is interacting with the form, by waiting for the user to focus or click on the form itself. Once it sees that the form has been interacted with in a human-like way, it sets a flag in a hidden input field. If the person browsing is not using javascript, then a <noscript> tag is used to show a normal CAPTCHA form which is checked by PHP only if the other input flag returned false.
Sure, there are other ways (the “hidden” empty input field) that work just fine, but this is certainly a clever way of going about it. It exploits a real difference between spambot and human.
11:28 pm
I just started making a flash game, my first one in a while, and my first by Cyclonic Studios. I decided that I would organize this project as well as I could. My previous games, while not being very good (you can play one here), were also terribly unorganized and I found that after I had finished them, it was very hard for me to go back and change things.
So this time, I am putting loads of effort into designing everything to be well and sensibly made. Here are some things that I am focusing on.
1. A Solid Game Idea
It is of upmost importance to know what your doing well before you start. You should know how the game is going to look, how the player is going to play the game, and how you are going to make everything work. Before you sit down at your computer and start coding away, you should make sure that you know those three things. How things will look, play, and work.
2. A Solid Game Engine
When you start coding your game, you have to decide how organized everything will be. I find that making a game engine is a good way to keep things organized. Here are a few musts for a game engine:
- A Global Class. A Global class is great for object oriented programming and is basically a class that every single object you make has a reference to. With this in place, you can call functions and access global properties even from a remote object that couldn’t normally do these things. For instance, if the enemies in your game split into more enemies when they die, it would be useful if all you had to do was add a few lines to your enemy “die” code to add more enemies. Just a simple
global.makeEnemy(blah,blah,blah); would do the trick, and also make it so that every single other instance of every other class could see that a new enemy was made.
- A UI Class. Just a class to handle all user interface stuff. When I’m making games, I use lots of code to make my interfaces faster and easier to manage. The UI class makes code-based interfaces much simpler, because you can easily show menus, pages, etc. with just a function call. Example:
ui.displayMenu(blah,blah); or ui.menu.addButton("Play",function() { play(); }); (I use that last one all the time; its surprisingly useful). And even if you don’t build most of your menus with code, a UI class also makes it easier to display menu sprites and movieclips.
- A Display Class. When you make a game with lots and lots of sprites, movieclips and bitmaps, a single class that draws all of them makes your code much cleaner. Its especially great for people like me who don’t want all their objects extending Sprites, which takes up more memory and is, in my opinion, a shortcut. Instead, you just have one class extending a sprite, Display.as.
3. A Solid Sense of Patience
Once you’ve got your idea and your engine, its time to start making your game. I think that coding games is very enjoyable, but inevitably you’ll have some times when patience is crucial: fixing that bug, drawing this button, and doing everything else that just isn’t…well, fun.
Anyway, happy game development!
