Collegiate Adventures

Obviously, throughout my collegiate academic career, projects and labs were a part of the Electrical Engineering lifestyle. Returning to the University of Minnesota campus and conversing with some team members on said projects jarred some great memories and late nights of working on these sorts of things.

1) Calculator.java - it may seem innocuous and simple. It may seem utterly useless. And it was all these things, but it was really the first programming project I went through that felt complex enough for me to be proud of. The goal of this project was to create a Postfix Calculator. Essentially what this meant was to make a calculator in Java Swing that would take input like 3, 4, and + and spit out 7, for example. It honestly wasn't too hard, and creating the Swing frame was a fairly involved and interesting process. This is also one of the first times where a nasty habit of mine began to rear its ugly head: I am a code hog. I get on rolls where I will simply sit down and code for 5-6 hours at a time unheeded. This means I finish projects rapidly and sometimes when group members are not available to observe or help. This project specifically exemplified that, when I did a good 70% of the project before my group members were even involed. Oops!


2) The Magic Cubes - ah yes, our Senior Project. I have to explain this quite frequently to people who ask me about big projects I had completed during my time at the U of M. Essentially, they were intended to be an interactive piece of furniture, which was initially a large plastic couch. When the couch showed up and lacked transparency, we sent it back and instead ordered a set of three cubes which were intended to be lit from within as dual-purposed lightning and seating elements. These proved much more suitable for the task, and we set to work creating multi-coned inner pieces to which LEDs could be affixed, and the cones could (mostly) direct lights to a single side.

The LEDs we used had a ridiculous three watt power maximum. For power transformation, we used a single ATX power supply which peaked at a couple hundred watts, which was more than sufficient for our purposes; namely, fifteen of the KingBright RGB LEDs. The LEDs were driven by PWM generators made by Texas Instruments, which in turn were driven by Arduino microcontrollers. The Arduinos were ridiculously easy to figure out and program, even with the serial communications required by the PWM driver. Sensors were also integrated that could "hear" sound and "see" changes in lightning, allowing the piece to react to human interaction.

Regardless, the entire thing worked out pretty well, which a vast array of colors available for each side of each cube. It was fun to work on, but there were several long days and late nights trying to finish the stupid things. Matt Oehrlein managed to do some work on them over the summer, which can be viewed here.


3) GeneriQuest 4000 - another programming assignment that I worked on with some close friends. Our task was to author a MUD, a text-based network-enabled and multiplayer game, which was original and interesting. Obviously, the largest criteria was to create something that allowed several people to play using telnet clients. What we created was somewhat like the run-of-the-mill fantasy MUDs, with wizards and swords and MOBs.

The overall coding was certainly bloated and filled with the possibility of buffer overflow exploits, but the game actually worked and could be played to completion. From start to finish with three people, the game took about forty-five minutes. The classes, Wizard, Fighter, and Cleric, had to be meticulously balanced against one another lest one be overpowered and overshadow the rest. It was a lot of fun and a little strange to have a spreadsheet with different attacks available to each class, crunching numbers about scaling options. Also quite amazing was the beta testing phase. One incident which sticks in mind is when I was testing higher level behavior and buffed a character for Jason. Essentially it allowed him to kill a level one or two player in one hit fairly easily. Andy logged in only to be instantly cut down by a single attack from Jason. The game then became how fast could Andy run around and dodge Jason, who was hell bent on smacking the crap out of him.

Obviously, the game had some big flaws - for instance, the only way we could make fighting monsters even remotely fair for the monsters was to have them counter-attack whenever a player made an attack on them. This made the Cleric class fairly essentially, since they were the only one that could replenish hit points quickly. We also made (what I thought was) a cool tick system, where regeneration and attack rate were throttled by a counter, which I believe was on a two or three second timer. Players could only attack once per tick, and would regenerate health once every few ticks. We also hard coded the game map instead of making it more dynamic, which was certainly a mistake, but in retrospect we had spent enough time on it. We won the "most original" award from our professor, conferring to us ten bonus points, which clued us in that we may have spent exactly the right amount of time on the little C program.