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 :/

So I got stuck on Sylva.

So I got stuck on Sylva. The last thing I remember is AABSP Trees. Though, I did manage to add support for md2 props, so one could theoretically load up a hundred rocks, though it might get slow without those AABSP Trees handling occlusion (?).
I mean, that's kinda cool, right?

Also, Matt got terrain loading from a file working, and it is awesome.

So, then what else do I need to do to move it forward? (Each further out in the future than the last)
* Animated Props (Animals walking around, etc.)
* Physics/Gravity?
* Simple AI (walking around, eating plants, etc.)
* Saving/Loading the world
* Loading things on the fly (Debug menu, here I come.)
* Growing plants
* Terraforming
* Plants make seeds, plant themselves, and/or are dispersed by animals eating them
* More complicated AI (animals eating animals)
* Animal reproduction (not genetically at this point)
* (At this point, it should be usable as a screensaver, resemble a game, and self-sustain over time.)
* Points system
* More Content (Animals, plants, objects, etc)
* Networking (Multiplayer, visiting from other players, chat/IM, etc.)

In other news, I've made a little template for 3rd ed. style D&D adventures in OpenOffice.org, and it's almost partially usable. I started working in latex, but I spent a loot of time doing really stupid stuff, and I figured I could get it done in a fraction of the time I'd spend laying it out in latex. Not to mention latex's interface for people who just want to add content is kind of...lacking. Latex is great and all, but I just want to get the darned thing done already.
I do plan on releasing it sometime soon, once I hash out a sample adventure. Maybe Paizo will hire me on or something :P
(All kidding aside, freelance work like that would be really cool xD)

So Crystal Space is an abomination.

After bashing my head against it and blender2crystal, I cant for the live of me get anything to _move_. I've tried making it an npc. I've tried adding pclinearmove. Nothing works. I'd get on IRC and ask the devs, but my internet wont let me stay online longer than about 5 minutes, and I doubt they'll answer within an hour after I ask.
If I can get a theoretical creature moving about, I can move forward. Otherwise, a friend of mine insists I should start from scratch and make it in C++.
So why should I?
Well, it'd be fast. Blazingly fast. It _is_ C, after all.
But it'd take a loong time to write. It'd be months before I get back to where I am now. Which is "Crossplatform, easily loading object/uv/texture data, move the player around, basic physics, and lighting."
I'm sure lighting comes basically for "free" with pure opengl, as well as movement.
However, loading object/uv/texture data is another story I'm sure. I'd like to use a library that supports Collada. I hear screams of anguish about xml. Know what? Fuck you. How else would you store all the data possibly present in a scene? Binary data? Like Blender? Ever try to access any of that data _not_ through blender? It's a pain in the ass. You end up with another library to read that garbage, instead of just parsing it with whatever xml parsing libraries you already have. How else is one supposed to store scene data than in a hierarchical manner. You derive from class Human. Humans derive from class Animal. Animals derive from class Organism. Etc. Life is hierarchical. Get over it. And besides, it loads it once, when the game starts. Speed is not, I repeat, *_NOT_* an issue here. Crysis takes nearly a minute to load its maps, and they're _huge_. This little crappy game isnt going to be nearly that big.
As for Crossplatform-ness, that is only really possible if we use standard C++, though not particularly hard, per se, it comes "for free" with Crystal Space.
Basic physics are a little hard to get running in Crystal Space from what I've tried. I tried and failed to get feesiks running. However, my friend has been working on a little ODE demo type program, rezzing boxes and such so that they collide with each other. It's really snazzy.
But what would I need in the future?
Terrain/heightmaps, bone animations, sound, off the top of my head.
Sound can be handled with openal and as such isnt a problem. (And isnt really related to 3d aside from the 3d-audio aspect)
Bone-based animations. Apparently the library Crystal Space uses, Cal3d, has an exporter for Blender, my tool of choice. (http://oomadness.tuxfamily.org/en/blender2cal3d/index.html) "Cal3D also provides an automatic level-of-detail control" --Cal3d FAQ I like the sound of that. Though I'm not quite sure how it'll tie into opengl, but I'm pretty sure it wont be that "hard". So then instead of having opengl import the collada file, we can just have cal3d import its file and go from there. Though, we wont be doing this until the rest of the stuff is done.
Terrain/heightmaps couldnt be that hard. I mean, all it is is a mesh that's deformed depending on a greyscale image. It isnt effected by gravity, though it does collide. I'm sure ODE has nice tutorials and sample code for this kinda thing, so no worries here.

(A few hours later)

So my buddy says g3d is all that. And that we're going to definitely be using it. He's anti-cal3d because "it makes too many files!!" or somesuch. Oh well, we'll worry about bone animations when we get that far I guess, and in the meantime, we'll just use md2 or something.
(A couple hours still later)
So I played with it a demo a little and it looks pretty good already :P
Lens Flares and all.

Anyway, I'll finish this off and give an update in a couple days.

Crystal Space And You!

So my latest foray into programming has led me to a toolkit called "Crystal Space 3D". Well I'll come right and say it. I don't know much C++. And with that out of the way I can then begin my hour long rant about how hard to use it is.

Well, it has a Python binding via swig, and it's quite nice. I like it. So I started work with one of the samples, tweaking it to what I wanted. I added different key bindings, as well as a first-person camera control. Sort of. It worked, except for if you moved your mouse in a circular motion, it would roll the camera some degrees. Annoying. So after a couple (few) hours of trying different things to get it to work, I finally gave up.

And that's when I discovered Blender2Crystal. I thought it was just some crappy exporter plugin that just dumped the contents of my blender meshes to some xml format. I was WRONG. Turns out it's one heck of an IDE for Crystal Space games. AND it's what the Apricot team is using.

So basically you just build to your hearts content (and remember that you should keep stuff as low-poly as possible) and hit "Run" and in a couple seconds (it has to cache lighting and such) you're off and running. Literally.

Now I can get on with actually making my game instead of bashing my head against quaternions and matrix transformations.

Anyway, about the game. I had an idea for a game, roughly inspired by various gardening/animal raising/farming games. Basically:

You are a druid in a some-time-post-stone-age era. You've been charged with caring for a patch of land. You gain points by growing plants in your land, getting animals to enter your land and reproduce, inviting other animals (plants invite deer invite bears, etc.). With those points you're able to buy levels or spend them outright. If you buy levels, those points are "locked in". When you level up, you gain things like better land, better spells, better tools, etc. With those higher levels you also unlock other things for "purchase" with your points.
When you spend points outright, you can purchase things like animals, seeds, plants, and various hardscapes (Cairnstones, statues, lanterns, etc)

It is an open ended game and as such will never end, your land forever expanding, gaining more and more creatures, plants and other things.
Due to its open nature, "mods" or as we like to refer to it in the open source world: "content" are extremely easy to make. Or at least it will be. Each object (animals, plants, etc) will be in their own file, and will be linked into the main .blend, or loaded programmatically. From there, you can assign a value to it, and it'll appear in game.

Also, as a secondary feature, I plan on having it work as a screensaver, loading up your map, optionally saving your "progress". In short, you end up with a pretty screen saver with deer and bunnies wandering around a pretty forest.

Perhaps when it's "done" I'll add downloading of new content from a website or something. Who knows.

Anyway, this project will be dubbed "Sylva" from the latin "Sylvan" (see http://en.wikipedia.org/wiki/Sylvan )

It will be GPLv3, and maintained locally in a git repository, pushed periodically to a bzr repository on Launchpad.

If you're interested, I can find something to occupy your time. I'm in need of Python programmers, Texture-ists, Model-ers, and generally any possible skill you may have. I'd love to have you aboard.