Infrared and Tamagotchis

So I decided I should mess with those darned tamagotchis again after discovering my local walmart had v4.5 tamas on "sale" for $15. I bought one, brought it home, and got busy. First, I set up my ir reciever on my breadboard as usual. I then plugged it in and fired up xoscope. It lets me use my soundcard as an oscilloscope. Luckily it has a rather nifty feature; It can detect a change in the signal (like the start of some interesting data for example) and freeze the display. Apparently, back when I was messing with this last december, I had my LED in backwards so I couldnt pick up anything.

So, now that I had some captured tama data, I saved it off into a file and started writing some code to parse it. I started off blundering around trying to figure out how to turn that data into 1s and 0s. At first, I thought that the "on" pulses were 1s, and that the "off" pulses were 0s, and that the differing lengths of 1s simply meant that there were two 1s next to each other. So I wrote some code to read that sample data and produce some binary, find "magic patterns" that might mean something (repeated patterns), as well as producing a mnemonic form by representing common patterns with letters.

That led me to realize that I had a sequence that was like so: 0101...1010
That obviously means nothing, but I soldiered on. I noticed that there were some areas of doubled 1s that didnt fit the pattern. I attributed this to static/corruption in the samples.

Then I did some reading. Turns out IR transmits:
a start bit, which I had observed as a really long 1, and just had my script note it as "1111"
zeroes, which I had thought were the "off" areas, but really were the shorter of the two types of "on" pulses.
ones, which I had thought were the "on" areas, but really were the longer of the two types of "on" pulses.
and "off", which I hadnt even thought of. Turns out "off" is the "off" areas. It occurs between all digits in the stream. so instead of 010101101, I really had: _0_0_1_0, or 0010.

After re-writing my software to recognize this (and cut out that magic code finding bit) I was suddenly faced with a binary representation of the binary data my v4 tama spit out while in "Other" mode.
I have yet to make sense of it.

Now I can read tama data. Yay.

Now how do I write it back to the tama?

Well, turns out you have to send a 38-40khz signal, silenced between bits, and the ir detector on the device should pick it up. Should.

I wrote another little python module to generate sine waves for me, and through some rather simple math, I'm able to generate what should be the correct signal. The thing is, that sound cards can only produce about 20khz. Luckily there is a technique that allows one to transmit summed signals so that their combined signal adds up to their collective hz. My code provides for that, but for some reason, the tama wont respond. Perhaps its because I dont have data to send back from a genuine <v4 tamagotchi, and only the "compatibility mode" data from a v4. I'll have to try with the v4 data.

You can find the latest code here: https://launchpad.net/irbinarisizer

I've still got a bit to go with it yet, but it should shape up nicely.

At the very least, I might duplicate the efforts of the LIRC project and make my computer into an expensive remote control.

Blogagotchi transition

After some consideration, I've decided to move my blog over at blogagotchi.com to here. This is mostly due to my picking up of Tamagotchi "hacking" again. They will be backdated.

Ever onward, Ever upward

After a week of playing with jME, generally not actually moving forward but more ona tangent, I've added a nice skydome found on the jme wiki, as well as background music.
I've also added a kind of cheap zoom, whereby a user can change the perspective of the camera by scrolling the mousewheel. I also added this snap-camera-to-terrain feature, which I have disabled at the moment because I find it rather limiting, but intend to add a keypress event to enable it, probably M or somesuch.

The one thing I wanted to do after getting one animation playing is to change antimations and play several at once, especially focusing on the animation blending afforded by the md5importer.

So then first up, multiple animations, playing at once, and changing between several.

After that, we just have to have it move about randomly, probably according to a locomotion definition somewhere, probably in xml and via http://javaboutique.internet.com/tutorials/config/ .

Regarding things not code related, we have storyline and other such frivolities to contend with. So here goes my initial idea(s):
The player plays the part of a hamadryad, a nymph forever bonded to their tree.
This particular dryad is actually a new creation, brought to life by a moderately powered druid. After a brief introduction by the druid that created the dryad, during which a seething racial tension seems to be in play; the druid disliking the dryad because he feels that another druid should be doing the job the dryad is about to be charged with.
The dryad's sapling is then planted in the centre of a vast desolate, deforested plain and ordered to rebuild this area of the forest.
The player first has to care for his tree, and coax the first fruit from it. This should take no more than 10 minutes at most. The tree has an uncanny ability to purify soil immediately under its branches, and as such, opens up a nice little circular
Once it's able to produce fruit (which provide essentially one-shot magical spells), the dryad goes on to wrangle his first animal. I'm thinking some sort of vole or mouse.
The first trick is to convince the animal to stay by providing a suitable habitat and food source for it. In the case of mice, this would be suitable cover (lots of grass), and suitable food (lots of grass). Lack of predators helps.
After getting his first animal and plant, the druid will come back and tell him to keep it up (in not so encouraging words) and give a quick overview on reproducing plants and animals. This should be complete with a discussion about the Voles and the Trees (birds and the bees). You know, "You need at least two of something to reproduce them. Mix em together, and a little while later, you get another one. Careful not to breed em too close. You wont like the result."
After reproducing a plant and an animal, he returns and tells the dryad to keep attracting and breeding plants and animals. As they do so, they'll gain experience points and be able to purchase new spells, plants, animals, tools, hardscape, and terrain elements (waterfalls for example).
After getting several species of each, the tree will quietly start to expand the area with which the dryad is free to experiment with.

After a while, the player might be invaded by another dryad or a human or an orc whose land they encroach on. For example, an orc raiding party might send in their worgs who'll run through, killing animals and destroying plants. If the player doesnt/cant fend them off, they'll tire and run off. I expect to have some sort of plant-based defensive measures, not to mention foot soldiers like bears and wolves. I expect the wargame aspect to be a VERY small part of the game. I do however, expect multiplayer and visiting dryads to be a larger part of the game.

More musing on the far future and idea of Sylva next week.

(Grab the code by using `bzr branch lp:sylva`)

Java is *almost* as good as Python.

So I didnt finish the client for xmlrpc-cardgame. When I do finish it, it might be in Java. (If you want to help out, as always, feel free to email me.)

As promised, I was going to pick up Sylva again when summer struck. I'd taken a break from programming to sorta clear my mind for a month or so and have now decided that summer's already here. Hence, Sylva's back on my plate. After much consideration, I decided to put the C++ engine Matt assisted me with on the back burner. The time it would have taken me to develop Sylva in C++ outweighed the point, which firstly was to let me learn a new language and evolve my programming ability a bit, and secondly to develop something semi-playable, over the course of the summer. If it took me 3 years to finish, it'd be pointless.

As such, I decided to try again but in a different language. I checked the TIOBE index and weighed the pros and cons of each of the top-10.
From the bottom up, my opinions:
Ruby (2.640%): "This will do me no good. It's a slightly different Python."
JavaScript (2.927%): "This thing will not be web-based. It'd need a java applet to be playable."
C# (4.058%): "No Java+Mono kthx."
Python (4.899% ): "I already know Python."
Perl (5.548%): "Yes, it's more than capable, but it's source is unreadable to me."
(Visual) Basic (9.787% ): "No BASIC+Mono kthx."
PHP (10.206%): "Not web based. Dont want to make a PHP desktop app."
C++ (10.806%): "Too much work for too little. Plus I wanted a different language."
C (15.513%): "WAY too much work for too little. Plus I wanted a different language. I'd also like a little object orientation please."
Java (20.890%): "It's kinda slow, but then again so is Python. And I get thousands of frames per second in a very basic C++ scene, so if Java is 10 times slower, I'd still get hundreds of frames per second."

In the end, I decided to go with Java. Just cant argue with that percentage (though admittedly, it's not particularly accurate). After I discovered Java Monkey Engine, I was sold.

After a little while fighting with version 2 (which I could tell was a real upgrade over version 1 from the little time I spent with it) and the examples provided on their wiki, I finally switched over to "latest stable" version 1 jars. Got it all set up in netbeans, and it's been a breeze since. My only hangup was adding physics. Turns out I had to add it to my classpath as well as adding it to the "Libraries" section in the netbeans project. (I did mention I was a Java/Netbeans newbie, right?) It's been a little over a day, and I already have:
Lighting
Camera
(Acceptable) Controls
Skybox
Terrain
Static Model Loading (animation to follow shortly)
(Bounding-Box based) physics (I want trimesh-based physics in the future)

Most of those are just 10 lines or so "flipping the switch" to enable them in my application.

It's rather neat, instead of giving you one "Game" class to derive yours from, there's several different derivatives, for example, I started out using a class called SimpleGame. It basically sets up a very simple game for you, the only thing it does is set up the camera and controls, the rest are up to you. Though most methods are on the order of 10 to 20 lines for each "feature". (The secret is that it handles all the threads such as rendering and updating the scene for you. You have to override these if you derive from BaseGame.) For example, when I decided I wanted physics for no real reason, I had to change from SimpleGame to SimplePhysicsGame. Since it derived from SimpleGame, pain was zero if I recall correctly.

The project's page is up at https://launchpad.net/sylva and you can grab the source by using `bzr branch lp:sylva`.

XMLRPC Cardgame Client

Before I can pick up Sylva again, I'm trying to get this client for my XMLRPC Cardgame Server done.

The idea behind it is that it is a Cairo surface that, when something changes on the table, an svg string is changed to change the display of the window. For example, a card gets added to the table, so an svg representation of the card is added to the main svg, then the cairo surface is refreshed, showing the card on the table. The only problem with this, is that it has no inherent ability to detect if a particular element of the surface is clicked, as it's just one big image. However, I plan on adding bounding boxes and such as detected from the svg's canvas size. This should work, even with the rescaling feature I have set up now.

However, before I add the click detection to the svg elements, I'd like to replace that menubar at the top of the window with a right-click pie menu. I'm going to be using Don Hopkins' piemenu.py module he wrote for the OLPC Sugar project, since it's the only real pygtk implementation of piemenus available. For now, it's just a matter of adding it...Oh wait, there it goes. Okay, then now it's just a matter of making it do the right things when clicked, and then hiding that menu bar, and then showing it if the user hits "alt".

Once that's done, next thing up is working on the gui. Specifically getting card info from the server, and showing that data in a meaningful manner.

XMLRPC Cardgame client/server

No, I havnt touched Sylva since I posted last.

I've been working on a little client/server project lately, using XML-RPC and Python. It's my first foray into unit tests and I have to say, I'm quite pleased. Not only does it provide a use-case for each function, but it also assures me I didnt break something horribly. (Which I did once but the unittests caught it.)

Anyway, the idea is that it is able to handle any game where you move bits of data from one area to another. IE, Cards. You have a deck, and a discard pile, and a hand, etc. which you put cards into, then move them around. It doesnt enforce any rules, and even has unix-y permissions. It's great for Nomic cardgames, as well as cardgames like Dvorak or even my own baby, Libre. It's coming along nicely, and I should be done within the week(?) barring Finals interfering and such. I'm aiming to have at least the server done before I have to devote my Summer to Sylva. The worst part is, the client's still not done even once I finish the server :P

See https://launchpad.net/xmlrpc-cardgame for the bzr branch.

Python and XML, my two loves in life.

I'm a big fan of Python. I'm also a big fan of XML. I also happen to like card games and am utterly frustrated by the complete lack of a card-game player/server that meets my needs. In short, I need something that I can throw cards of any shape, size, or content at and it not fall over.
Apprentice is okay, but it's closed source abandonware.
OCTGN is alright, but their newest version isnt _fully_ open source to keep the shuffling part a secret. And its written in .NET...not optimal.
Firemox is getting close, but its documentation is lacking, and the fact that I cant use Ubuntu's default JRE to run it is a pain. Also, its errors are less than helpful when writing up the XML files for the rules of your game.
There was a little program written in Python (and using Twisted too) that was made to play WoW:TCG. It's on the right track but it's really alpha quality. (I'll come back to this in a minute)

So, in a fit of rage against Firemox and their error "A card is broken, Fix it.", I decided to write a Jabber bot to play referee for card games. That idea didnt last long, but it did lead to an XML-RPC based server. As with all projects, the architecture has evolved as my old, crappy ideas get pushed out of the way in lieu of new, better ideas.

Anyway, the idea is to define a set of functions for the server to handle. Then a client can depend on a server having those functions. Always. Then client-writers only have to worry about what the "spec" says rather than what the server actually does. (This is where that WoW:TCG client comes in. It can be re-written to use those xmlrpc calls and use its shiny interface for good instead of evil :P)
It's abstraction, and it's good. After about a day of hacking on it, I have a reasonable skeleton for the functions, as well as logging in and out. Presence will come in the days to follow, as well as getting down to the actual "card game" bits.

Yes, yes, I know I very well could have used Jabber for that presence junk. And yes, I will probably have a "message_user()" function in there too. However, that will be rather simple compared to Jabber, as it has to support transporting messages over multiple servers, etc. Mine only has to worry about who's on the server it knows about. The independent servers cant, dont and wont talk to each other. Maybe the third time I rewrite it, who knows ;)

Sylva is on the back burner, but on the forefront of my mind. I probably wont get to touch it till this summer, but by then I'll have all sorts of ideas. The one that's highest on my list at the moment is "Loading objects and scene settings from a file." I neglected to mention that one in my previous post. But it's quite important. I would _love_ for that stuff to be randomly generated, but without settings, it's going to be a rather static random world :P

And yes, I'll be moving Sylva to Launchpad when I start working on it or maybe sooner. HG is great and all, but it really requires you to have your own public server :/