Some times one have to turn python modules into executable files to be distributed into a computer without the Python environment. Normally this would be a pain, but with cx_freeze this has become a breeze.

I’ll just list out the steps here in Windows for reference.

1- Install cx_freeze on your computer. The easiest way to do this is with the following command (note that you have to have pip, which comes prepackaged with Python 3.x).

Ensure that pip and python is on your PATH environmental variable

$>pip install cx_freeze

2- Navigate your command shell to the directory of the module. Say, I have a module emailparser.py in the C:\Users\User\Github\emailutil folder.

use the cd command in your shell to change directories.

3- Use the cx_freeze module to transform your python file to a executable.

Ensure that the directory of your cx_freeze script (most likely in Python\Scripts)...

Volume One : Prologue

“Alright then, let’s start!”

Start what, exactly?

I could not stop myself from ranting at the voice that suddenly entered my ears.

Being forced to wear these earphones just narrowed down my movement range.

Completely a fish out of water, I was brought here unsuspectingly, locked in a room with a huge conspicuous glass window, and then made to sit in front of a microphone that hung from the ceiling. This microphone was different from normal Karaoke microphones, being the more exquisite kind that hung from the ceiling, I guess. Sitting on the chair, no matter what I do, I cannot ignore the microphone that hung just a little lower than my sight.

In this situation, what should I do?

“It’s already started!”

A human voice was transmitted over the earphone again. I think this was the person at the other side of the mirror talking.

These guys are really so lively...

Writing web applications can be a chore. With all the languages (minimum of HTML/CSS/JS) you need to learn just to write a single web page, with a little PHP thrown into the mix when you need to do server side computation, the simple dynamic web page can get hairy pretty badly.

Jquery solved a lot of problems on dynamic DOM bindings but on the server side, PHP leaves a lot for us to consider. Why can’t we just use one language to solve them all? A fast, compiled language that has huge libraries for us to use, easy to use and port to another server. Now that’s what we want, right? Is Python Django, Ruby on Rails, PHP Cake the answer to all of this?

No.

Fast and compiled? PHP. Easy to use and port, Python and Ruby.

But for both to be present at the same time, neither of them meets the mark.

Enter Clojure

Clojure is a modern lisp hosted on the JVM, with ports to JavaScript and CLR...

I started playing with Hoplon for a while now, but I have only started to look at it seriously as I wanted to practice on Clojure.

Getting Hoplon with lein was easy, but the guys over at tail recursion preferred to use something different for their task system, which was boot.

The newer boot faced a few problems over at my windows machine.

Apparently this problem was documented as a bug on windows, and so I had to revert to a older version of boot, which was boot.jar.

It took me some time to realize that it was used the same way as the newer counterpart, the only difference was I haven’t got it to display all the logs on my console.

Just run this:

$ your-file-path> boot.jar development

And it will silently begin working in the background.

After sometime manually creating zip files and manually moving the files to the appropriate folder for sometime, I just realised that 7zip has it’s own command line interface. Yay! Windows did not provide a command line interface for the zip (not sure where the program is, even), so I couldn’t write batch files to automate the process.

7 zip, in my opinion, ranks in the top-tier of free compression software. It supports many formats outside of zip, along with a simple interface, it is essentially just download and zip/unzip your stuff.

The reason for the compression was that the game without compression is going to be horribly big for the game and that a base game, with all the patches is needed. While the patches were made with the free patch maker, it did not have a command line interface.

At first, I used Python to write a prototype using subprocess.call to call 7zip and datetime...

After a brief stint at svbtle, I guess it would be time to move some of the posts to blogger again. One of the things you’ll notice when writing in svbtle is that it’s more like a private repo of text than a blog, though without anyway to back your text up except by manually copying them, or writing a script to download them, both extremely meddlesome. Another thing was that there was no comments, no buttons, nothing to distract you from writing. While I do enjoy that kind of environment, no comments just leaves out part of the blogging experience – interacting with your audience. I guess that’s the main reason I’m moving back to blogger. :P

Though I’ll prefer writing in markdown in svbtle, then maybe copying it back to blogger, since my bandwidth is so lousy that the minimalist design embraced by svbtle actually made it easier to load than the full blown editor in blogger.

June 16th. The day of reckoning. We’re going to launch a community alpha release on that day, so everything should be as prim and proper before we step out to the world and say, “Here’s the game!”.

And that includes the dev base, which also includes the codebase. Just a week before, we’ve got Lee, who is an indie Unity3d dev, with plenty of experience come and help out. While he haven’t contributed code yet, he has already provided valuable experience into improving the game. :D

After some back and forth, I was finally convinced to port the entire codebase from Boo to Csharp, for two reasons in particular, NGUI, the future of Unity GUI (may change in Unity 4.6 though) and the main inclination of the community of Unity3d development. I still have misgivings about C sharp as a language (LINQ, and compiler type inference, in particular, as I have to use them in place of comprehensions and...

Wasp failed. I guess that’s not surprising since I didn’t really had a firm understanding of the PhotonNetwork. Apparently, something to be sent over the network could either be synchronized using RPCs, which by itself is pretty simple to use if it’s the same object in every player game, or using PhotonNetwork.Instantiate then using the PhotonStream object to send things over to other people.

It took me a few days of head banging and nearly going into depression to get that right. After that light bulb moment, everything else just clicked into place. It was quite a new way to separate what was offline and what was not.

Eventually I separated each player to be a black box and the battlefield to be the common ground. Of course, that was the theory but I still needed something to communicate with other players outside that black box, like chat or starting the game, so that will have to...

Web-based Attachment of Synchronized Photonviews.

I guess I should write the idea down while I still have it. :P

Currently the PhotonNetwork has their own instantiate system that works the magic to create a GameObject and assign an unique ID to it. However, while I can use PhotonNetwork offline mode, but everything will get messed up when I try to check the Photon Views somehow and try to get the players to Lerp towards the system positions. It’s terribly laggy, but I guess I haven’t checked my code much.

The real problem is that I need to manually assign the Photon View to every Object that I think needs to have it. The work could be offset by the use of prefabs but there may be hundreds of model needed and this is heavy work… I need the game to be clever and assign the Photon Views automatically.

I dismissed the idea of having both the hovercargo map and the battlefield map on...