For all the Java people out there, you might be surprised to know you're going to get Phasers in the future. Get ready for battle. Unfortunately, Proton Torpedo's didn't make the cut. Sorry.

On a side note, I've been working on a little virtual machine. So far, it is incomplete although there is only 1 part left to do before I probably make a 0.1 release, it works.

Documentation on the overall structure of the virtual machine and some benchmarks are here:
http://thoughtpolice.stringsandints.co m/misc/vm_notes.html

From the benchmarks, you can see it runs FizzBuzz 10,000,000 times in about 12 seconds when compiled with gcc -O3 -fomit-frame-pointer and when there's no output buffering to cause an I/O bottleneck. If compiled with output enabled, there are almost no speed improvements regardless of compiler flags since printf takes most of the time.

The resulting code of the VM when using gcc -O3 is quite desirable and efficient since it (largely) eliminates branch misprediction using direct jumps to register values, while instead there are just a lot of 'jne/je' instructions if compiled with say, -O0 or -O1.

I'm probably going to code up a C version of fizzbuzz without output as well to see how it compares to native C. I expect to be dominated.
Addendum: I wrote an C program equivalent to my example bytecode program - or as close as I could get it. Excellent results: With gcc -O3 -fomit-frame-pointer it can do 10,000,000 iterations in approximately a half a second. Major smackdown, right there.

I'll probably be blogging on my other blog about this in the future, in case you want to keep track of it.

I'm graduating High School on Friday, finally. After 4 years it wouldn't matter if I walked a stage or was mailed a slip of paper, it's just nice (and strange feeling) to be done.

What this means is that I get a present. Namely, I'm getting a MacBook for a graduation present. The major drawbacks are simply present to all laptops: keyboard and screen real estate. The screen will probably be a 13" (so not a Pro,) and the keyboard isn't ergonomic which all programmers love.

Luckily, these guys sell nice docking stations (for $150...,) so when I'm at home and I want to develop, I can have a nice, big 24+ inch screen and a sweet ergonomic keyboard to work with. Of course, being on the road and able to develop is very important, but at my house, yeah, I'll take the better keyboard + screen (not to say MacBooks have shitty keyboards/screens or anything; It's just a really, really kick ass investment by the standards of most programmers.)

I got accepted to a college.

News at 11.

UPDATE 03/04/08: tests are over and I am gaming hard. Also, my sister is the ultimate awesome, because God of War II kicks total ass and she bought it for me.

My SATs are this saturday; I'm worried but I think I'll pull through high enough to get into a college I've looked at so far.

But, after this, serious hardcore gaming is what's going to happen. Now that I have a 360, and my still always-faithful PS2 (for 7 years now,) I ask you people, what do you recommend?

Currently on my list of "games to beat" is (as in I have all of these games in my possession and I will beat them with time):

- Final Fantasy
- Call of Duty 4
- God of War II
- Final Fantasy V
- Mass Effect
- Ace Combat 6
- The Darkness
- Crackdown

On my list of "shit to get":

- Final Fantasy X (already beaten but I want to level my characters up more)
- Shadow of the Colossus (beaten, but always a good game)
- Final Fantasy VII
- Final Fantasy XI
- Ninja Gaiden II (BEST DAY EVER)

Games I am already done with so they don't need to be recommended:
- Devil May Cry 4
- Assassin's Creed
- Ninja Gaiden Black
- Halo 3

If you guys have any good recommendations, they're all appreciated, because after these tests I am putting the keyboard down to whoop ass for a while.

Yay. Give me money or I will beat you to death.

PORNO AND LOTTERY TICKETS FTW.

A good friend of mine went into the US Air Force today, and he left me in charge of his Xbox 360 because he is that kick ass.

In any case, I am happy. I've mainly been playing Devil May Cry 4 and Mass Effect, but once Ninja Gaiden II comes out, it will be the greatest shit ever.

EVER.

So I've been experimenting with various things and learning more and more. Here's a short list of a couple of these:

1. Types. I've been reading Benjamin Pierce's book "Types and Programming Languages." While some of the mathematics are a bit beyond me (not by any insane amount though, it's a really easy to read book to be honest,) the overall subject if fascinating and definitely worth a look if you're seriously into CS. You don't need to understand all of the math to really get anything out of the book, I've already learned plenty and it generally makes a lot of sense.

2. My IRC bot. The development branch is quasi-stable with updates being applied periodically. You can get the development branch on linux by running:

$ git clone git://repo.or.cz/infinity.git

Notably do to some horrid linker and package dependency issues, testing the dynamic core is tough for me right now (although I know the exact issue which causes it, meaning it might not be a problem for you.) I'll have to find some solution before making an official release, although I am fairly confident that it should work. The branch from this point on should normally build just fine, and it should also operate correctly as well in most all instances. What mainly needs to be done is the quit-server functionality and reboot (which like I said, will need some work...) But other than that most everything else is fairly stable.

3. Ideas on future work. Notably I have a file on my desktop called "ideaware" which is a textfile full of ideas to program in various languages, to keep myself busy if I ever get bored. A couple of these are:

* A version control system
* Distributed IRC Server
* Javascript Implementation
* Forth compiler & environment
* Small games
* IRC/SILC client
* Text editor
* MapReduce implementation

There's more, but I think those projects are really enough to ponder and think about for the future already...

I need something to work on. The movie `Idle hands' reminds me of this.

Basically right now I'm occupying my time with Erlang. Currently, the idea is to make a small, online, party-based rougelike (see: nethack or ADOM.) The server will be written in erlang for obvious reasons, i.e.

* Cheap concurrency for free
* Fault tolerance
* Scalability and distribution

Right now, with only 300 lines of code and utilizing the awesome Erlang/OTP Infrastructure, I've already got this much set up:

* Scalable and distributed. The game server can occupy a large amount of computers in a single network. There is one master node which does things like load balancing, aux. node administration, the lobby server, keeps a writeable copy of the database, etc. etc.. All connected players however, are more likely than not connected to an auxiliary node, which is simply a node who's only purpose is to keep clients connected while also keeping with it, a RAM-only copy of the database. Copies of the database are replicated across nodes and whatnot in real time (this is something you get for free,) so after a quest with your party, anybody on any other node in the entire server will see the items you got and whatnot. :) This is really the only synchronization we need. Periodically, the master will flush it's copy of the DB to disk for persistence. Master crashes? You might lose a couple items, but probably nothing insane.

The term 'node' is somewhat loosely defined, though. The master node can also be an auxiliary node, in the case of a single-computer server. Elaboration: Multiple nodes can be on one computer, although the typical setup will probably be one-node-per-computer.

* Load balancing. The master does this by itself, and when it gets a connection from a client, it chooses a node which it finds suitable for connections. So, nobody gets thrown onto an auxiliary server with too many players, but they're all a part of the complete 'server' anyway, since auxiliary servers are totally transparent! (it's just a redirection, in essence.)
* Auxiliary node administration. They can be added and removed to the cluster at will, very easily.

Of course, this all sounds impressive, but there's so much more to go:

1. Protocol.
I have not yet devised a protocol for the system. Luckily, Erlang is excellent at protocol programming, and so I feel I should be able to represent map data and whatnot with a lean amount of data and whatnot.

In order to make the game protocol easily accessable to other languages (in the case of clients,) I'm thinking I will write a C library to give that compact representation more ideal form, so you can just interface with the library for your own purposes.

2. Map generation
Not yet invented, entirely. There's probably a couple resources on the 'net, though.

3. Database infrastructure.
Not designed yet, but considering how the game will be played, I don't think this will be too hard to set up, just a bit of time will be needed. It has to include everything about the player in general: login credentials, the user's characters, friends, items, spells, level, etc. etc.. This is what's going to take time to think of.

4. Monster system.
The monster system will take time. Right now aside from your typical monster AI, I'm really thinking of the idea of monsters genetically getting stronger as you progress and get higher levels and do more quests. Basically given two monsters of similar characteristics (say, both mammals or magical; defining these parameters is also a part of the monster system,) every once in a while the server may genetically create a new monster with similar properties of both when you create a game, etc. etc.. As time goes on, these new creatures that're created are put into the game database and are further altered to be of appropriate strength and whatnot when you create a level. A really interesting approach would be to define 'mating rules,' but I'm going to have to do more research on this.

5. Gameplay
Here's the tough part. Once I get all the very primitive infrastructure set up (such as the database, lobby, aux nodes and the auxiliary node manager) and working pretty generically, my ideas are to simply spend a week of my life playing some rougelike's to find out exactly what makes a rougelike so addictive. Get some general ideas.

This is still hard though, because it requires splicing this 'tried and true' formula with a different gameplay schematic, that is, multiple users. To keep it manageable, though, I think the default player cap to a single quest/game will be about 8.

6. Lobby server
This shouldn't be hard, but it's not in the design or code yet. This really shouldn't be to hard, when you register a new game to be opened, let the lobby server know about it. When you look at the lobby, query the lobby server about all open games, and when you click to join a game, update the lobby's info about that game. Once there are a proper amount of players scheduled to join one game, simply do some normalization according to stats of the users, the quest, difficulty of the quest, etc. and generate the map data and gogogo.

7. An actual client.
In the essence of a Rougelike, my plans are to write the very first client in Haskell utilizing something like an ncurses interface. Naturally, this won't be portable to windows. So if anybody on earth is interested in writing say, a python client for windows after I get the server off the ground, that would be super, super awesome.

Those're my ideas. Any comments appreciated. If you have any words of advise or good will, they're also appreciated. I wouldn't hold your breath for the game, but I'm having fun working on it and it should be interesting. At the very least I can get someone else to tell me how the code sucks, how to improve it, and I'll have learned something from the whole process of writing it. You can only be a better man tomorrow by learning of your mistakes, today, after all...

My IRC bot is finally alive. While it's not released in its newest form yet, you can experiment with it (when I happen to be online) at irc.freenode.org on the #ngprogramming channel. You can also get a snapshot of the source from http://code.haskell.org/infinity/snaps hots/

As of right now, most of the major issues seem to be fixed and the bot is running very well so far (code reloading works beautifully, even across multiple servers.) There's a bit of a corner case I'm going to fix in the (very) near future hopefully as well, but for most purposes, I would say it's 'stable.' Hopefully I can consider it "ready for release" sometime by the end of this month or so.

Fun stuff. Now that this project is coming to bear some fruit, I'm going to look at other crazy stuff to work on. Stay hooked on this space.

Recently I've been working on two things:

1. Getting Haskell binaries to run on the bare iron, that is, with no operating system.
2. My IRC Bot some more.

Notes:

1. Getting GHC binaries to load via GRUB is very feasible although it will require a reimplementation of certain libc functions and whatnot. I can probably crib many of them as its under a GPLv2 license, but it'll take time to port everything to where I can link it statically and boot off a disk from it.

The first version of the kernel code I'm aiming to support is this:

http://paste.lisp.org/display/48713

You should notice I never have to write any threading code. By utilizing the GHC Runtime System, we get a lot of stuff free and cheap like threading, data parallelism and software transactional memory. So getting the RTS to run on the bare iron gives you a substantial amount of code to work with from the start.

More on this as it goes along (probably slowly.)

2. My IRC bot is now being worked on some more. I've gotten the logger framework filled out. I'm working on a State mechanism for plugins so they can preserve state inbetween reboots, etc.. This will be exposed through an API that will be built on top of some monad transformers for plugins (so I can restrict plugins to certain operations only, that is, using monads as a form of security.) Through this same API I can expose functions to send data over the wire and whatnot. I also have a monad I made up for the main execution of code that'll make changing around inner and stacked monads a lot easier (see here.)

More on this sometime in the future. Hopefully I can get more interesting parts of the bot online and then I'll have to work out this silly hot-code-load situation...