Project: EMI/Magnetic Field Detector

This project is a general purpose magnetic field detector that is very useful for pinpointing sources of EMI (electrical noise), tracing wires behind walls, etc.

The circuit is a modification of one made by VK2ZAY, all credit goes to him for the excellent design:

https://www.youtube.com/watch?v=8anfmp_pTJM

Schematic:

Final assembly as hand-held tool:

Some notes on assembly:

I used metal can transistors (to reduce noise) since I had them on hand, but you can use any NPN with decent gain.

The original circuit used a 9V battery, but they're expensive, not rechargeable, and have pretty poor capacity. I replaced this with an 8.4V rechargeable pack made from a couple Li-ion cells from an old laptop.

I used a 33mH inductor instead of the original circuits' 5mH; this seems to increase range/sensitivity considerably. If you have an even higher value one available, it would certainly be worth trying.

I added a simple bargraph VU meter IC to give some visual indication of signal strength. This lets you see signals that are above the range of hearing. This can be any bargraph IC, does not need to be BA6144.

The variable resistor is used to set the bargraph meter sensitivity. You can use this to zero the meter in high noise environments.

Uses:

One major use of this circuit is in tracing AC wires behind walls. It helps to have something noisy, like a CFL bulb on the other end of the circuit.

It can also be used to detect EMI sources, both at a large and a small scale. For instance, finding which power adapter on a circuit is generating radio interference, or determining which components on a circuit board need shielding.

You can also detect fixed magnets. They will not produce a tone, but if you swipe the sensor passed them, you'll hear a blip of static.

Improvements:

There is no reverse polarity/short circuit/low voltage protection for the battery back. Since the Li-ion cells can easily deliver 10's of amps and destroy transistors, there should really be a fuse or current limiting circuit. The cells themselves can be damaged be running them down below 3V each, so there should be something like a TL431 low battery indicator.

High frequency signals are inaudible over the piezo speaker. One solution to this would be to build in a variable local oscillator/mixer before the audio amp.

St. Louis Game Jam!

I got back a few days ago from my first game jam in St. Louis. Wow, what a neat experience!
For those who don't know, a game jam is a short (in this case, 48 hour) game-making marathon. You show up, find out what the theme of the jam will be, and try to come up with an idea that can be turned into a game. Everyone then splits up into team and gets to work.
If you are a gamer and have ANY amount of skill in coding, drawing, Photoshop, writing, or sound design, I highly recommend you check out one of these. It will really open your eyes to what designing games is like and to just how much a few people can get done in a short time span.

We ended up making a point & click adventure game with hand drawn graphics. You can check it out here:

http://globalgamejam.org/2014/games/imagine-2

Those who know me from El Camino will recognize my, uh, "style" of animation in certain parts of the game. :)

Chexmod Wrap-up

This post will serve as a wrap-up for the Chexmod project. After several years, I decided to put out the current beta of it, because it was unlikely it would be finished any time soon. If you haven't read my others posts on Chexmod, it's a Chex Quest themed Source engine modification made by myself and a friend of mine, Seth.

Screenshot:

Download:

https://dl.dropboxusercontent.com/u/55950000/chexmod_b1.rar

Follow the instructions in the zip to install it. You'll need Steam and Source SDK base 2007:

I consider Chexmod a failure, due to the long development time, the small amount of content in the released version, and the limited response.

Here are some things I learned about game design over the course of this project:

Even the smallest team must use SVN.

SVN (SubVersioN) lets you turn your game directory into a fancy shared folder that works over the Internet. It lets you incorporate new files from other team members into the game, while keeping everyone up to date with the game's source code.

Even if you don't need to share source code, SVN is absolutely necessary. Let's say a recent code change breaks multiplayer in your game, and you don't realize that until you go to do a beta test with the rest of the team. If you can identify the problem and quickly fix the code, SVN will let you push a small patch to everyone else in a matter of minutes, turning the code problem into a small hiccup.

In comparison, if you try to use Dropbox or Skype or something, you'll need to zip up a rather large DLL or EXE, wait for it to upload, then wait for everybody on the team to download it before continuing.

Here's all you need:

Open source SVN client: http://tortoisesvn.net/downloads.html

Free SVN hosting: https://www.assembla.com/home

Know the programing language and development environment you'll be using before you start making the game. Games are complex beasts, don't expect to learn how to write code “as you go”. For instance, Chexmod is built on the Source Engine, which uses C++ that compiles through the MSVC++ IDE. I spent many hours trying to figure out problems that would have had obvious solutions if I had learned C++ prior to working on the game. I also was not aware that the debugger could be tied into the game while running until recently. This would have vastly simplified development earlier in the project. Since I jumped into the game as a coding novice, I made many mistakes early on that took (literally) years to undo.

If you are building on an existing code base (IE: a mod), keep track of your changes in the code. It is easy to discount the importance of doing this if you are the only coder on the project. However, some bugs don't show themselves immediately, making it vitally important that you tag ANY major change that you make. Use something unique that it not written elsewhere, that you can search for later on. For instance, write “CHANGECHANGE” rather than “CHANGE”. If you know something is broken, but don't know why, mark it with “BUGBUG” or “FIXFIX”. If you fix something but had to write some really bad code to do it, mark it with “HACKHACK”.

These simple identifiers will help you go back to sections later and roll back changes in your code.

Have a release schedule. Even if it just seems like you're working on a silly game for your friends, you may want to release it online at some point in the future. Give yourself a time limit. Six months, a year, it doesn't matter. This will vastly improve the amount you get done between playtests.

Chexmod had this problem, I never really thought about putting it up online until a few months ago. It took 3 years for me to release an unfinished beta, don't do what I did.

In a previous blog post, I mentioned a strategy of making game assets as quickly as possible, with no regard for quality, in order to flesh out the game and have something to playtest. This does not work. Well, it works for a week or two; then you realize everything looks terrible, and it doesn't matter how great your code it. Perhaps this would work for a larger team, if one person did the temporary art, and somebody else did better versions of everything later. However, when it's just you going back and doing multiple passes on your own work, it ends up being frustrating and demotivating.

Once you know what art assets you need to make, take your time and make them look nice to being with.

Finally, perhaps the most obvious lesson:

Make a design document. This can be as simple as a prioritized list of ideas. It's easy when starting out to ignore this step and rush to the part where you start actually doing things. The problem is, if you approach it like this, you'll end up spending a lot of time on code/content that will not be used. If a gameplay element is going to take a lot of effort to code, you should build a prototype of it and playtest it extensively, rather than spending the time to make it prefect first. The biggest waste of time in the Chexmod project was on stuff was not used in the game. This is because there was never any sense of what systems/ideas were the most important to the project.

Avoid doing this. Make a document outlining what you want the game to be, and build it.

Amplifier & Monitor Repair

I fixed a couple of electronic things today, posting about it here in the hopes that others may find it useful.

The first was a Kenwood amplifier. The remote control stopped working with it. There didn't seem to be anything wrong with the remote itself, so I decided to take the lid off and check the infrared receiver box. This turned out to be a real pain in the ass; they bolted the knob things to the case, the front panel is attached using those easily broken flat wires, and there were about 2 dozen screws to take out.

Refer to the dimly lit picture of the guts of the unit strewn about my dirty carpet:

 

Anyways, I got it all apart and found the infrared thing, it looks like this:

 

Flipping the board over, I found that the 3 pins going to that were soldered very poorly, not making good contact to the traces.

 

So I resoldered the pins, now it works. Yay.

Then my monitor broke. It's an Acer AL2216W. For the past couple weeks, the LED kept turning this dim red color and it was really hard to get the screen to stay on.

I took the lid off and removed the metal panel over the back. I had to take out the screws and bolts for the power plug and video plugs to be able to do this.

See the circled thing? That there is a high voltage capacitor; if you ever go to fix any sort of monitor, once you get it apart, find this big capacitor and short the two leads out using a screwdriver.

If you don't discharge it, and then accidentally touch it, you'll get a nasty burn or possibly die.

 

Ok so I removed the power board and took a good look at it. One of the capacitors stood out. See that crud at the top? That's electrolyte that leaked out of the vent. Once a cap does that, there's no way it can hold as much charge as it's supposed to.

 

So I busted out my desoldering iron and removed it.

 

Whenever you replace a capacitor, always check the ratings. In this case it is 10 volts at 2200uF. 10 volts is the maximum it can store; it will only store as much as the circuit requires. In this case, this part of the circuit only saw 5 volts,so this was OK. The important thing is to make sure the capcitor you pick to replace it has the same, or higher ratings. If it's lower it wont work or will explode.

 

In this case, I found a 16 volt x 2200 uF one in my parts bin. You could just as easily buy one online at Mouser. Notice how it's next to the heatsinks? That means you should get one rated for the high temperature, which is denoted by the color of the case. In this case, I should have replaced it with a black cap, but I used a blue one because it's what I had on hand. (Do as I say, not as I do!) Honestly if that part of the circuit regularly goes higher than 185*F there would be bigger problems than just the cap..

 

I put it all back together and now it works. Woo.

Cyclopticus model/Chexman ingame

Got the cyclops flemoid model made by Seth into the game, it replaces the manhack.

Here's a Max render:




Ingame:


The Chex man is also ingame now, unfortunatly I haven't figured out the animation system yet so he just idles:


also his eyes are just a tad too far apart so he's stuck with a permanent derp face :(

Next up will be the Large Zorcher viewmodel, then I'll try to fix up some of these previous problems an make a video of everything!

Chexmod Progress

Here's what's been added to Chexmod since that last post.

Flemoid exploding animations:

Basically flemoids explode when they take enough damage.  Since they're slime-based monsters, they can "reform" a few seconds later and continue attacking the player.
Eventually the engine will recognize when a flemoid was killed with an energy weapon, and play the animation where they actually disappear.




This system creates a number of benefits:

1. Gives us an excuse to have projectile weapons and not just zorchers in the game
2. Opens up possibilities for gameplay when you have an enemy type that can only be killed with certain weapons
3. Fits with the story better, in terms of what weapons would actually be on hand


New guns:


Pepperbox:

Antique gun that will originate from the history museum level.




Spamcannon:

Full auto shotgun carried by security guards, found on most maps.



Large Zorcher:

Not finalized yet, but it will probably take out most flemoids in one hit like in Chex Quest.




Also:

The Chex man:

WIP, example model from Mudbox combined with a few primitives.  He looks pretty damn creepy.




More updates coming soon!

Chex Mod

Quick rundown:

Back in 1996, General Mills thought up a marketing idea to have a Chex-themed video game distributed on CDs in boxes of their cereal.   Surprisingly, the game was actually really well done and very fun to play.  It ran on the (at that time) state of the art Doom engine, and was my first introduction to first person shooter games.

Here's a screenshot from the intro and the gameplay to give you an idea:

Anyways, recently I got all nostalgic about this game and thought "how cool would it be to have this on a modern engine?"  The Doom engine was cool back in the day, but now you realize that everything in that game was represented by a flat picture the size of a postage stamp..  So I started working on some simple models and code editing for Source (half-life 2 etc).  With just a few rudimentary changes, it became immediately apparent that it would be possible to capture the feel of that old gameplay!  I got a friend onboard who knows 3DSMax and Photoshop a lot better than me; he is making the creature models and environment textures while I am doing the code/engine junk, maps, and weapon models. 

The major idea has been to create as much new content as quickly as possible, regardless of quality.  Get the gameplay down, get the old weapons and enemies in there; don't worry if it looks crappy, there's always time to go back and fix it.  I get the impression that a lot of mod teams go for making a smaller amount of high quality content and never really get done.  So far we seem to have a good strategy, here is where we are at, about a week and a half after I first thought of the idea:







And this is at 2 weeks, with working AI, showing the self-illumination mapping: