xxdriesxx-blog

[xxdriesxx-blog]

Moving to Wordpress

Sorry for the possible confusion, but I will be continuing my blog on Wordpress, due to lack of some features on this blogging platform.

[xxdriesxx-blog]

It's been a long time

After several months of inactivity I've decided to start posting stuff on this blog once more. I'm sorry for the amount of time between blog posts, but I've been undergoing some career changes and am just starting to pick up my normal routine once more.

During my period of inactivity I've been thinking about the posts I've been making and how I would like to continue with my posts. There have been several ideas I've been having:

Book reviews: I'll now start posting reviews about books I've been reading.

New programming language: I will no longer use C# as a primary programming language, since my focus has shifted more towards Java and open-source.

Indie game platform: I'm thinking about porting the work I currently have finished to Java, but I'm not yet sure.

Android: I've started learning about android the past couple of months, so I'll probably be making posts about mobile development too.

Next to these changes, I've decided that the blog will continue its journey the way it is currently progressing.

If you would like to see articles about a certain technology, language, or something else on this blog, you can contact me through the "Ask me anything" page as always.

[xxdriesxx-blog]

Binary protocols seem better now

I've made some progress on my Indie Game Platform and I am almost ready to implement my first very simple game plug-in for the platform. The only problem I'm currently facing is game sessions and plug-in data transport.

I would like to be able to transport more data at once concerning a game session, so that all information is in one place (or packet). Currently I am using a text-based protocol and the message will look like this:

GAME_SESSION_INFO:[HOST_NAME]:[PLAYER_LIST]:[GAME_NAME]:[...]

As you can see the text-based messages are becoming a bit too large when transferring more data.

The second problem, plug-in data transport, concerns not only the size of data that can be efficiently transported, but also the types of data.

For example, if I wish to create a game in which some kind of floating point numbers would be used, then I would need a string parser that can parse floating points, creating a lot of additional unnecessary overhead.

Too solve these two problems I've now decided to go with a binary protocol approach. The two things I now need to do are:

Decide on a binary packet structure.

Transform every message type into a number.

I hope to be able to show off the first basics of my platform soon.

[xxdriesxx-blog]

This is an interesting article that made me think about using UDP for my Indie protocol. I am not sure yet if I'll go with it, but for the moment I'll stay with TCP until the rest of the system is implemented.

[xxdriesxx-blog]

Adding word documents to svn using TortoiseSVN

I just learned about a neat feature within TortoiseSVN. I added a word document to my list of revision files and learned that you can compare different revisions of word documents to each other. TortoiseSVN simply opens the Microsoft Word revision manager for you and you can quickly review the changes that were made.

[xxdriesxx-blog]

By analyzing patterns in your choices during previous rounds, this Rock, Paper, Scissors bot will ultimately beat you. Its very interesting to see how the computer analyzes the previous data to determine what your next choice will be.

[xxdriesxx-blog]

An interesting article about several natural language processing techniques. Especially the ChatScript manner seems particularly interesting.

[xxdriesxx-blog]

The difficulties of file transfer

After several weeks of inactivity on this blog, I decided it was time to start working once more on the Indie Game Platform.

The first I thing I got to was the update procedure. I wanted clients to be able to dynamically update their plug-in files, without troubling the user of the platform.

To do this I made several improvements to the networking code of the platform in order to be able to create binary protocols, which was the simple part of the mission. The second more difficult part was creating the actual file transfer protocol.

I finally decided to divide my files into chunks of 100 bytes each. I then first sent a header to the client telling it how large the file is and what its checksum is, to be able to validate the file on arrival.

When the header was sent, I sent each chunk with its separate "chunk header" containing the length of the chunk. Each chunk needs its own header because the final chunk being sent, often doesn't have the same length as all chunks before it. It also allows me to change the chunk length on the server to a larger size, without having repercussions on the client side of the application.

I'm currently deciding what I will do next because there are still a lot of things I have to do before I have a working platform + plug-in. Here are some of the things on the to-do list:

Additional error handling

Code cleanup

Finalize the plug-in protocol

Finalize the plug-in interfaces

Create a plug-in

Finally I'd like to say that while this blog may look inactive sometimes, I will only update it when I have interesting things to say about the project. If you want more detailed explanations of the project, you can mail me about your topic of interest and I will probably blog about it. If you want an in-depth look on the source code, you can check it out from the svn at source-forge.

[xxdriesxx-blog]

The usefulness of binary protocols

Not so long ago, I made a post about the pros and cons of using a binary protocol instead of a text-based version. Based on these arguments I implemented my architecture primarily around text-based communication.

It only came to me a few minutes ago, when I was trying to get an update procedure in place, that it is difficult or even impossible to send files over a text-based communication line.

As a result I'm now trying to separate some of the networking logic, in order to make it possible to use both binary and text-based communication.

[xxdriesxx-blog]

Plug-in architectures and their problems

It seems that getting your project set up to work with a plug-in architecture isn't as easy as I thought. It took me some amount of time to get the correct solution configuration with which I would like to continue. My current setup works as follows:

In the directory in which the executable for the server monitor is located I've create a directory called plug-ins. I wanted all my plug-ins to be created in this folder, while the assemblies they are dependent upon are still in the main executable directory.

My first idea was to build the plug-in and then copy it over to the plug-in directory. There were two problems with this approach:

Every time you build you have to copy the plug-in over to be able to test it.

The assembly the plug-in is dependent upon has to be in the same directory.

The second one took me some time, but it seems that when you add a reference to a dll file in your project, you can configure some properties. One of these properties is the the "Copy local" property, which determines if the plug-in is copied to the dll's directory when it is being build. I set this to false.

The second step in this process, because now your plug-in won't build, is to reference the dependent dll in the main server's executable directory. In this way the plug-in is dependent on the same dll as the server uses to activate plug-ins.

The first part is actually really easy. It is just a matter of going to your plug-in project properties and then the "Build" tab. In the "Build" tab you can change the output path of the project's build. Change this to the plug-ins directory. You should now have a working plug-in project set-up.

As always if you have any questions regarding this or any other of my posts, feel free to contact me through the "Ask me anything" page on my blog.

[xxdriesxx-blog]

Richtextboxes in WPF

It seems that the Richtextbox in WPF does not work in the same manner as the Richtextbox in the Windows Forms libraries. The main difference is that the Richtextbox in windows forms had a classic Text property and was difficult to work with if you wanted to give the text some more layout.

In WPF you can make use of the Document property which contains an instance of a FlowDocument. This class allows for an easy manner to layout your documents contained in the Richtextbox.

It took me a while to figure all of this out, but once you now that you've got to use the Document property instead of a Text property, everything became a lot clearer to me.

[xxdriesxx-blog]

Binary vs. Text-based protocols

I've been thinking about making the protocol for the game platform binary instead of it being text-based. Here is a comparison of the pros and cons I've thought of:

Pros:

Smaller network overhead.

Better for larger data structures.

Cons:

Reduced readability.

Improved complexity

Conclusion:

Since I'm not currently working with large data structures and network overhead doesn't seem to be a problem, I'll keep on going with the text-based version of the protocol. I'm also not very fond of the improved debugging complexity a binary protocol will add to my application.

[xxdriesxx-blog]

New user interface, new name, new goal ...

Since I am going to extend the capabilities of my server I decided to create a new user interface at the same time because the old one started to feel a bit dated. You can view an image of the user interface below this paragraph:

I created the interface using the WPF framework which allows you to create rich user interfaces for applications. As you can see, the interface is not very extensive, but it's a lot better than the old one.

You can also see that I changed the name of my project. First I called it "Brain Game Library" since it was supposed to be a game library only. I've renamed it to "Indie". My new goal with this project is to create a platform on which you can run simple games.

The ListBox to the right is still inappropriately called plug-ins, but I'm going to rename it to "games", since it is supposed to be a game-only platform at the moment.

I will of course continue to extend on the Hangman game until I've added all features I promised it would have. This game platform is just an extension on the Hangman project, to keep things interesting.

[xxdriesxx-blog]

About the lobby system

Not so long ago I started work on the lobby system for my Hangman game. Since I am planning to do more games with the same code base I wanted to be able to reuse the lobby system in other games. Therefore I decided to change the architecture of the project around a bit to allow me to create a single lobby for all my games.

You might wonder how I am going to handle this. The answer is simple: plug-ins. I'll create a basic system in which you only have the lobby and chatting options. You can then extend this basic system using plug-ins. These plug-ins can have their own networking protocol, user interface and their logic is almost completely separated from the lobby code.

The advantage of a plug-in system is that I can create a single platform on which all my games can run.

I'm now going to refactor my code to adhere to these new architectural constraints. As soon as the plug-in architecture is in place and the Hangman game is working once more, I'll release version 2 of the project.

[xxdriesxx-blog]

Cluster-chaining name generation

The cluster-chaining algorithm is very alike to the markov chain algorithm. Therefore I will not cover it. This was the last naming algorithm I had planned to cover, so if you have any improvements or questions feel free to comment.

I will now try to implement the name generation in the Hangman project after which I will extend the Hangman protocol to have a lobbying system.

[xxdriesxx-blog]

Syllable-based name generation

The penultimate algorithm I'll discuss is the syllable-based name generation algorithm. It is one of the simpler, yet more effective algorithms that exist for name generation.

Explanation:

The algorithm requires two parameters: a list of "first" syllables and a list of "second" syllables. It will then randomly pick a first and a second syllable and combine these into a name.

Advantages:

Very simple to implement.

Returns a lot of valid names.

Disadvantages:

You need a lot of "first" and "second" syllables to generate a lot of names.

Often there are still weird names in the results.

Remarks:

Provided that you put some time into the creation of a decent dataset, I think this is a very good algorithm (certainly if you look at how simple it is).

Output:

Syllable-based name generation (output)

As you can see there are a lot of valid English names in the output list.

Reference:

Roguebasin

[xxdriesxx-blog]

Finite state name generator

The finite state name generator I found information about on the web, seems to be just using Markov Chains, so I won't cover this one. The next one on the list that I'll certainly cover is the syllable-based generator. Stay tuned for information about it.