I was setting up an HTML form today and I wanted to group some options together in a multi checkbox set, allowing a user to select multiple options in a category. I usually just give each checkbox a unique name and parse all of the individual values in PHP, but this has always struck me as an ugly way to handle this use case.
As I was looking up the syntax for an HTML checkbox, I found a lot of info that said I could simply name all of the checkboxes the same and it would group all of the values together like this:
But this doesn’t work. When you POST the values to PHP, you only receive the last item selected in the group. The annoying thing is that a lot of the examples online show this same syntax even though it’s clearly wrong. After digging a little deeper, I found this forum post with the correct syntax. Adding square braces to the checkbox name creates an array of the selected values in the group:
<?php
if (isset($_POST['chk_group'])) {
$optionArray = $_POST['chk_group'];
for ($i=0; $i<count($optionArray); $i++) {
echo $optionArray[$i]."<br />";
}
}
?>
Simple! I thought I should post this correct solution in the hopes that it might help someone else wade through all of the wrong information out there.
The proper way to build a game in Actionscript (or any other language) is to create a quick prototype and test the gameplay. Then, if the gameplay is good, you refine it. If it isn’t working, you go back to the drawing board and create another prototype. Large game companies often scrap ideas that aren’t working when the prototype is tested.
In reality, it oftens takes so much time to get the basic mechanics working that you would never consider scrapping it, even if it isn’t really a good game. But, it doesn’t have to be that way. Two issues that slow down game development are:
#1: Dealing with basic input/output, collision detection and all of the “simple” things that you need to make a game function. Coding these elements takes hours and has very little to do with making your game awesome.
#2: Fine tuning your game. There are usually several inter-related variables that need to be adjusted. The (slow) way to do this is to make an educated guess, set the values, publish and test. Then, adjust the variable values and try again.
The good news is that there are solutions to both of these problems. The solution to problem #1 is Flashpunk. It’s an open-source AS3 framework for building pixel-based 2D games. It handles a lot of the basic animation, collision detection, keyboard input and other issues so that you don’t have to do it. It’s a pure Actionscript-based library that compiles in FlashDevelop, which is free and open source, so you don’t even need the Flash IDE. I whipped up a sample “game” in Flashpunk below. This only took me a few hours, including the learning curve.
"But, I'm making an "immersive 3D RPG for iPhone" you say? So what? You can still use Flashpunk to do some quick gameplay demos and make sure that your basic gameplay is actually fun. Once you get the hang of Flashpunk, you can whip up a simple game demo in less than a day. It may save you a lot of time down the road. Go here to get the source code and then work through the tutorials. You can be making games by the end of the day.
Now, if you tried my game demo above, you are probably saying "this sucks! I can't even jump up to the platforms!" That's where my second time saver comes in. Minimal Comps is a set of basic Actionscript3 components that can help you with your prototyping. In the game above, I've added a game tuning panel made with Minimal Comps. To see it, right-click on the stage and choose "Show Testing Console." This will open the panel with several options. The first button toggles the collision hitbox visibility. If you make the hitboxes visible, you will notice a bug that I left in the game when you move the character to the left. By changing the values in the textfields, you can adjust the game gravity and jump velocity until the gameplay works and feels right. Minimal comps makes it easy to set up this testing panel for tuning your game in real time.
Prototyping in Flashpunk with Minimal Comps for real-time game tuning is a super fast way to test out a game concept. It'll help you spend less time on the annoying part of game development and more time doing graphics and level design. Good Luck!
As always, you can download the source code for my sample here. It's a pure actionscript project, so there is no FLA. If you use FlashDevelop, you can simply open the project file and start modifying things. If you use FlashBuilder/Flex, you're on your own. Here are a few random things you might want to know:
- It is important to note that Flashpunk does not make the game for you. You still have to write all of the code for your gameplay, so you must have some basic Actionscript 3 skills and some idea of how to code a game. If you don't want to code a game, you should stick with GameMaker.
- The documentation is not awesome for Flashpunk. The forums are a great place to get answers to your questions.
- Flashpunk classes are useful even if you want to build a game in the Flash IDE, but you will need to modify the way they are used. You may want to try them out in a pure AS3 project first, so you will know how they work.
- My sample "game" is not optimized. Feel free to use the source code as a basis for your own game setup, but a lot of things need to be changed to optimize the code. I've sprinkled a lot of comments in the code to help you out.
- This is not my original idea. It is a compilation of good ideas from the sources listed below. I just put them together so I could give you some source code.
FCK Editor is a free, open-source HTML editor that is commonly used in a variety of CMS (content management systems). It is often installed as a Drupal plugin and we use it in our own CMS at work. Unfortunately, it has a pesky default that converts image tags to input tags. If you add a linked image like this:
<a href=”…”><img src=”…” /></a>
it saves it as a linked input like this:
<a href=”…”><input type=”image” src=”…” /></a>
This can create CSS issues in some browsers because image inputs are displayed with a blue border. To prevent your image tags from being converted to input tags, you have to dig into the FCKEditor code and tweak it slightly. Every time I have to do this, it takes me an hour to find the code that needs to be changed. Hopefully, this will save someone else a lot of time and hassle…
1) Open this file:
editor/dialog/fck_image/fck_image.js
2) Scroll down to about line 223. You will see this code:
When you are trying to track down a bug in a SWF, it’s a common practice to add trace statements to the FLA. By tracking various values in the program, you can usually find the bug. Unfortunately, it only works reliably when you publish the SWF from the IDE. There are cases where this isn’t feasible. For example, if you need to see whether or not flashvars are being received correctly by your SWF.
This is where Vizzy Flash Tracer comes in. It is a standalone program that runs beside your browser and displays the trace output of your SWF. It can pick up the trace statements from a SWF running on a remote web server, which is perfect for testing things like flashvars or communication between a SWF and javascript. Simply fire it up, navigate to your web page, and watch the trace output. It has been indispensable for tracking down bugs in my Flash applications.
Debugging with Vizzy is more reliable and faster than Flash’s own remote debugging (which often crashes the browser). It’s already become an indispensable part of my debugging toolkit. In case you missed the link above, you can download it here.
If you are having trouble getting it to work correctly, check out this page of the wiki. I have also noticed that Vizzy locks up sometimes when I have Photoshop open. So, you may have to close photoshop to do your debugging.
