A long time ago (well, not that long, it was 20 weeks ago) I published the game Vortex which I made at school. Thanks to some of my co-developers I can also proudly present the trailer. Press play to view the trailer.
If you want you can also download the full 1024x768 trailer with all the details than right click on Trailer Download and choose "Save as..."
Download the trailer: vortexTrailer.mpg (164 MB)
I like using the train to get from A to B. I have been travelling from home to school and to my jobs for almost eight years. Since I have a laptop (the last seven years) I also like to work in the train, be either story writing, programming or reading. However it often happens that other people use the train as well and it often gets crowded. Of course the polite thing to do is to close your laptop and put it back in the bag, but in truth nobody wants to do that. The last few weeks I have been spending quite some time in figuring out how I can prevent that from happening and here are my findings. Of course if it gets crowded you should still make room for others.
First of all, pay attention to the stations you pass. People often don’t like to walk a lot when they are on the station so they try to place them to the door that requires either the least amount of walking when they either enter or leave the train. For example if the entrance of the station are always at the back of the train (or the majority of the stations) than the front should be less crowded than the back.
Second tip, everyone wants to have two benches completely free for themselves, as the majority feels uncomfortable of entering somebody else his personal space. So when they enter a wagon they will often walk in a bit before figuring out that all benches already have at least one occupant. Their next choice would be where only one person is sitting. And then where there are only three people sittings (Dutch trains only have four seats). What you should do is try to get the first spot available. When people walk in they will see you and will automatically try if there is somewhere else an empty place. In the end the chances are big that you will only have neighbor. If you want to have more effect from this tip, try to sit to where one person is already sitting.
Third tip, sit near the path. People don’t like to disturb you (or jump over legs). Think of it as blocking the path. To maximize this tip you could also put your bag next to you (preventing the person from sitting down without asking you to remove it) and as finisher you should be working (disturbing you is then unwanted). However at this point you should consider yourself extremely rude.
The basic idea of the third tip is that people prefer not to sit directly next to you or on the opposite site of you, if possible they want to sit diagonal of you. So if you have the first empty spot and sit near the path, the last position to be occupied will be the one next to you.
Of course all the above tricks don’t work when it is really crowded and you should always make room if someone asks, but this way you have a little bit more personal space when working in the train.
Sometimes I want to store some data, but at the same time I want it inaccessible from the outside and indirect available for derived instances. The idea is pretty simple, but since I had never a reason to use it I simply didn't use it. Besides most programmers I know are not that hot on the idea of deriving from an object written by another programmer. This includes yours truly. Anyway here is the idea to make data inaccessible from the outside and indirect available for the derived classes.
typedef std::vector<int> intList; class BaseStorage { private: intList m_list; // Can't be accessed from the outside or derived classes protected: void StoreInt(int number) { m_List.push_back(number); } int GetInt(int index) { return m_List[index]; } }; class DerivedStorage : public BaseStorage { // Only local functions can access the data };
At my current internship I have to develop for the iPhone. In this post I have spoken my mind about what poor gaming device the iPhone is those who follow me on twitter () know that I'm not really happy with what the Mac OSX can do. I admit than I'm a Windows/Microsoft fan boy so it must be pretty darn obvious that my opinion about Apple software is unbiased, but there are somethings I simply love about the Mac OSX. If you know somebody who has never touched a computer before in his life I would seriously recommend him/her/it a mac, not because I like it but simply because it's plain simple. If a Windows was Lego than a Mac would be Duplo.
There are a few things I would love to see in Windows. First one is exposé. The idea is that when you activate all your windows will be shown before you. Ok, I admit it sound lame, but just watch this demo.
Pretty cool, right? Anyway I found a free application that does the exact samething on Vista. You can find it on and it's free as I mentioned before. Here is a screenshot of me using it.
Click on the image to see the fullscreen (1440x867)
Anyway the second one is the ability to give folders or files a color. My project folder is stuffed with many code projects and many of them are of little importance (testing some code, writing a tutorial, etc) while other code is important. On the mac you can give files and folders a color, which is sweet as you can quickly spot those that are important and maybe just as important to identify those who can safely be ignored. I'm still looking for a program that can do this on Vista.
The third thing I like to see back in windows is terminal. Ok, the truth is that Windows already has a terminal (called cmd or the command line prompt) but the Mac version looks nicer. I also miss the full-screen command prompt in Vista (you still have it on Windows). It's nothing big, but I have learned that tiny issues are most of times are more important than the big issues. There are plenty of terminal software out there but none that look really nice.
On a side note I have decided to start working on a new engine. It's the one I will use for my final assigment at school and it will be DirectX 10 based and multi threaded and one word "Awesome!".
I don't care much for a country. If the netherlands was attacked by an enemy and I got a call in which they say I'm drafted, everyone in the netherlands is excused when they become 18 (but this might change at anytime), I would pick up my bags and flee. I don't mind fighting for things I'm proud of, but I'm not the least bit proud of the netherlands (goverment) so I won't fight for it. Just so you know I'm proud of our men at arms, where ever they might be, whatever they might be doing. They often have to do what cowardly people require them to do (invasion in Irak was pressed by the goverement).
Anyway at diner I thought wouldn't it be cool to create an independent country. Let's say we buy everything there is on a small island (so we own the island and everything on it) and then declare independence. The next morning the army arrives to supress the freedom fighters (aka you, who owns the entire island, is the only inhabitant and freedom fighter).
Personally I want to do something like that as I want to create an utopia. It will have to start out small and then it will slowly need to grow. All people allowed to enter in the first 25 years should be hard working to make certain progress continues and afterwards the entry rules might become more lenient, to ensure quality. In the end you can be anything you want, you don't need to work, free health care and so on.
The only question that I have is how long it will take after creating this "utopia" for it to fall.
It has been a month since I last talked about Procedural generated spaceships. I haven't had much time to work on because of my internship and other work however the progress that I have made has shown this might be a bigger challenge then I had hoped it would be.
The general idea is that you first create the bones (like a stick figure but then from a space ship), then you create the flesh or hull of the ship and then you will start adding rooms, corridors and all kind of objects so that you can walk through it as if it were a spaceship. However I found two things that I find in dire need of my attention.
The first thing is that you need detail. Even though a starship can have the shape of a cube (borg cube) it will never look like a cube if you get up close. The second thing is that I have not yet found a strategy (a way of approaching the problem) that can guarantee proper use of space. For example how can I be certain that chamber doesn't go outside the spaceship?
Personally I think I need to do some more drawing, thinking like an artist before I can give an answer to questions like those. After I have answer to both question it will only be a case of setting up the implementation and be done with it.
A real simple trick to prevent sickness from spreading is to make certain that nobody else uses your stuff. However it is sometimes hard to make certain you don't do this. In our house, we have a bunch of glasses and when are finished with them we put them on the kitchen dresser so that we might use it for later. since everybody grabs the first glass they come along we sometimes make mistakes which was our glass.
Well, a reall simple trick is to use a rubber band and put that around your glass. You can clearly see which of the glasses is yours and anybody else who grabs your glass will certainly wonder why there is a rubber band around the glass. An additional effect is that the rubber band prevents other glasses from touching your glass (just like a car bumper).
Another good and simple tick is using a simple plastic bag to dispose of your used tissues instead of the common garbage bin. You can not simply "contain" the bacteria using this method, but you do reduce the risk for others since they will not come in contact when they throw away their own trash.
Last it is always to remember some of the old tricks (which your parents most likely already made you aware of) like: Wash you hands (even when your not sick), clean everything you use (towels, table surfaces and so on) and turn away and hold your hand before you mouth when you sneeze.
Fun note: The majority of the tricks don't work as people think (washing your hands mostly reduces spreading, but not preventing you from getting sick) but remember that the idea of getting sick is often a huge factor in really getting sick. An experiment proofed this by having one person who was compleltly healthy being asked if he was sick or if he was really feeling well. As a result by the end of the day he actually thought he was sick and became sick. It's like a reversed example of the placebo effect.
Normally I'm rarely sick and when I was a kid my mom once joked that I could only stay from school if I broke my leg or was death. It was obvious to her that I was faking. I love her for being so caring ^_^.
For those who follow me on twitter this post is old news or it might be a minor refreshment as the majority of the content has already been posted on twitter.
At my internship I have been developing for the iPhone and boy oh boy, can I make a list of things to complain about. Luckily there are also a few good things and they balance each other but it’s a pain when you cannot unleash every bit of skill you have. Let’s start with the sour part.
There are still a few other problems (no multitasking for example, API might break with new firmware update) with the iPhone but let’s move on to the sweet part of the iPhone.
Actually the only one I can think of is that the distribution of applications can only be done through the apple app store. There is no such thing for the windows mobile or symbian. This way apple can also guarantee the quality of the applications, however I find it a mood point since an application that is poorly written is unlikely to be successful.
Actually there are a few more things, the emulator is good (better than the one for the Nintendo DS) and the API is reasonable documented (inconsistence in quality, but overall reasonable).
I have started a new challenge. In case you don't know what a challenge means to me. It is something that I found higly interesting and has a high degree of complexity.
Yesterday as I was getting a Lahmacun and I was thinking of a game concept. In that game concept the player would be walking around a great city just like The Guild 2, one of my favorite games. However since I wanted streets with more than 50 buildings, I needed them to be more different as I was walking I quickly became aware of many issues. One once creates a city one needs to take in account culture, economics, transport, production, layout of the land and so on. I'm also a fan of "A pattern language", a book that explains how countries, regions, cities and buildings should be designed, so I quickly understand that such a challange (Creating a highly detailed procedural generated city) so I decided to let it go.
While I was eating I download a mod for half-life 2 named Eternal Silence and I found it immensly cool how one could walk through a space ship, jump in a fighter, fly out, board the enemy capital ship and then walk through the ship of his enemy. However it would be cooler if you create a simulation based around your own space ship (or maybe even space ship fleets). However this is more complex than I thought. I think I have a good idea, but their were quite a few more problems than I had expected, however I do keep making progress.
So what are my conditions to complete this challenge?
So far I'm working out a few design that should be procedurally possible and I hope that I soon finalize the heuristics so that I can can start focusing on the internal parts of the ship.
One of the things I'm really good at is writing lengthy emails. Ok, that is enough cynicism for now.
The fact however remains that I more than often write lengthy emails, sometimes even 3 pages of A4 format long. Since this has become a structural problem for me I have decided for a new approach. The new approach is that I'm only allowed to write three sentences in the body. You can find more about the idea on
I have done this for a week now (with exceptions here and there) but the result is asstounding, where I would previously be writing a good twenty minutes (including checking, rechecking, correcting and son) I now spend almost less than two minutes on a mail. I now have also like twitter more since it forces you to use only 140 characters (which I hate, because for some reason I always need 141 or 142 characters). By applying a simple constraint like a low number of characters or senteces you can make it realy easy. In the past I often rewrite important emails until they were down to ten or less sentences (record: 1.5 A4 to 4 medium length sentences)
In the beginning however I thought this was rude. I have always been thought to say "Thank you, sir" instead of only "Thanks". But an added side effect is that my emails are so much clearer now, which is nice for the recipient.
Downside however is that I can't apply it in all cases. For example A formal letter of introduction (used for internship or employement) needs to follow a certain rules and in that case you can't write 3 sentences and be done with it. It's at those moment I think that all email should go through a twitter like system.
If I really had a choice I would say we would reduce the amount of communication to only face-to-face and telephone. My father has a saying that goes like "The more ways we have to communicate, the less we do it". And I agree on that. I have skype, WLM, GTalk, Emails, Mobile, paper post and forum accounts and I'm quite certain I'm missing a few others and frankly I'm tired of keeping track of all that.
Then again I'm hyperconnected.
Thanks to Jasper Bekkers, a good friend of mine, the design pattern described in "Possible connector design pattern in c++?" finally has a name. It is actually an Acyclic Visitor combined with an Observer Pattern. The reason why I didn't know of this pattern is because (again, thanks to Jasper for explaining) this pattern was not in the book of GoF and partly because of that it is not wide-spread. I only own two books on design pattern (actually one, since I lent the otherone to another friend) and neither of them described the Acyclic Visitor.
On the website of c2.com there is also a nice link to a pdf in which the original acyclic visitor pattern is designed including code samples. They use dynamic_cast though, while I use typeid. The downside of dynamic_cast is that the cast is not constant while typeid is constant. I do expect however that using typeid is generally slower (especially since i perform a string comparison) but dynamic_cast did not feel natural for me. In retrospect it is rather easy to use dynamic_cast once you accept that once it returns a NULL pointer the casting was incorrect.
I know I promised I wouldn't create another engine but I really couldn't help it. The last two days I have started working on a new engine named "ImpEngine" but I'm going to abadon that soon. The reason why I created a new engine is because the the LimeEngine is just not good enough anymore. I have used it for a few projects and it has completely met my expectations. It's a good engine for prototyping but that's about it. It's not good enough to be used in production enviroment.
After I noticed the fact that I need an engine which is more sutaible for production enviroment I wanted to create a complete new engine however two days later (today) I'm starting to think what I'm doing. My design still resembles the original engine and except a few minor ideas it is basically the same. The only big reason why I want to start over is to add resource management and scene management, both in a proper way. However I can also add it to the current LimeEngine.
After some thought I think I would do better to improve the LimeEngine then it would to create a new engine. Further a good plan is required. I need to know what it is that my end result is.
One of the biggest challenge with SceneGraph is the fact that every object can have a different shader. This might not seem like a big deal but it is really causing me a headache.
The basic problem is that a SceneGraph is tree (meaning one root node and a lot of leaves which can have leaves as well).
The problem with shader is that you don't need to follow the above graph. You could give Node003 two shaders while Node007 has only shader. Shaders prefer it to have the entire scene rendered (otherwise you will have tons of state changes which will kill your framerate).
So an example of three shaders:
The best way would be to traverse the SceneGraph three times and each time apply a different shader and let SceneNodes opt-out if they don't want to be rendered by a certain shader.
However another method that I'm wondering that uses the visitor pattern. Each effect will visit all nodes and then they each shader will have it's own list of shaders that it could use. Upside is that it reduces possible stalls of the GPU, downside however is that this method of traversing involves generating another list and so this method is more CPU intensive.
Another method involves using the observer pattern. Each scene node can register itself with an shader. Then the shaders will be drawing (which in my eyes is also more correct as we now divide rendering from scenegraph. However at the same time this means that Scene nodes are floating (they can be registered at multiple locations). However I might be able to solve that problem using
boost::shared_ptr.
The bottom line is that I'm not certain if any of the above solustions are the best method. Currently I think that the method involving the observer pattern might be the best solution. But it's also the solustion where you get the most overhead. But this is slowly becoming a question of memory overhead versus speed. And in this case I think speed is more important than memory.
Recently I was working on an AI assignment and I needed a method to pass around notification which would cause the receiving objects to act upon it. Problem however was that none of the objects knew each other. I had many AI modules which were all split up (for example driving to a destination would exist out of destination chooser, path-finding algorithm, obstruction evader , driver mechanism, etc) and not all of them needed to concern themselves with notifications (a notification would be “change destination”) and often they only cared about a single notification.
As long as the AI stays simple, you are good with a few notification (in fact I think I only needed two) but as I was writing it I noticed that adding another notification would require changing 4 different classes. If I would heavily rely on my notification passing system I would have been in big trouble.
There are a few ways to make the system simpler and the first one would be that there was only one notification which hold all possible data a notification could have and an ID which would help figure out what the type of message it was. The downside of this method I would need to check the ID and then act upon it. This was something I did not like.
Another method would be to have all AI components derive from a base class which had all the receiving notification messages ( OnChangeTarget(int targetID); ). This was the method I choose in the end (as I started to get me more and more off track while I should be working on the assignment) and since I need only two functions (remember, two messages) it wasn’t that hard . However I promised myself that after delivering the assignment I would find a way to improve this.
And this morning while I was walking the dog something suddenly hit me. Since neither type can recognize the other one (they both start as abstract classes) I need to find a way to connect the types. I had thought of this option before, but since the connecting method would need to be able to handle abstract types it should be abstract as well.
Since I'm assume this has become quite confusing so far I will post the code that demonstrate what I want to do.
////////////////////////////////////////////////////////////////////////// // Two different notifications struct HelloNote : public INotification {}; struct WorldNote : public INotification {}; // The receivers // ... //; }
As you noticed there is no coded type identification within the message (in fact except their names they are identical) and because the receivers are downcasted as well you can no longer see which type should recieve what kind of message. However after we run the final version of the exact same code (I promise I won’t change main at all) the classes will recieve the correct messages.
I’m not certain if the following method is an existing design pattern (believe me, I looked for it). But it is similar to the mediator pattern, but were the mediator pattern acts between two different set of variables, I'm acting between two different types. The solution I provide mediates based on type and not on instance. For now I think the description of an "abstract connector" would be better, but since I'm not 100% certain I will leave it at "possible".
Although I Intended to explain it I decided against it, since the code looks simple (as it is in fact), but it will be faster to experience and then explain it than the otherway around.
#include <iostream> #include <typeinfo> //for 'typeid' to work #include <list> //------------------------------------------------------------------------------------- // Library code // You can copy this straight in your code and it will never have a need for // modification. //------------------------------------------------------------------------------------- struct INotification{ virtual ~INotification(){}; }; class IReceiver; struct BaseConnector { public: virtual void Connect(IReceiver* aRCV, INotification* aNote) = 0; }; struct Translator { const char* m_Type; BaseConnector* m_Interupter; Translator(const char* type, BaseConnector* inter) : m_Type(type), m_Interupter(inter) {} }; typedef std::list<Translator> TranslationList; class IReceiver { protected: TranslationList m_Translators; public: void InitialReceive(INotification* aNote) { TranslationList::iterator begin = m_Translators.begin(); while(begin!=m_Translators.end()) { if(strcmp((*begin).m_Type,(typeid(*aNote).raw_name())) == 0) { (*begin).m_Interupter->Connect(this, aNote); } begin++; } } void Receive(INotification* aNote) { std::cout << "Unhandled\n"; } }; template <typename R, typename N> struct TConnector : public BaseConnector { public: void Connect(IReceiver* aRCV, INotification* aNote) { ((R*)aRCV)->Receive((N*)(aNote)); } }; template <typename R, typename N> struct CTranslator : public Translator { CTranslator() : Translator(typeid(N).raw_name(), new TConnector<R, N>) {} }; //------------------------------------------------------------------------------------- // User code // This is what you will be writing. //------------------------------------------------------------------------------------- ////////////////////////////////////////////////////////////////////////// // Two different notifications struct HelloNote : public INotification {}; struct WorldNote : public INotification {}; ////////////////////////////////////////////////////////////////////////// // Our Hello Reciever, only accepts HelloNotes class HelloReceiver : public IReceiver { public: HelloReceiver() { m_Translators.push_back(CTranslator<HelloReceiver, HelloNote>() ); } void Receive(HelloNote* aHello) { std::cout << " " << __FUNCTION__ << "(HelloNote* aHello)\n"; } }; ////////////////////////////////////////////////////////////////////////// // Our world Reciever, only accepts WorldNotes class WorldReceiver : public IReceiver { public: WorldReceiver() { m_Translators.push_back(CTranslator<WorldReceiver, WorldNote>() ); } void Receive(WorldNote* aWorld) { std::cout << " " << __FUNCTION__ << "(WorldNote* aWorld)\n"; } }; ////////////////////////////////////////////////////////////////////////// // Our HelloWorld Reciever, accepts both messages class HelloWorldReceiver : public IReceiver { public: HelloWorldReceiver() { m_Translators.push_back( CTranslator<HelloWorldReceiver, WorldNote>() ); m_Translators.push_back( CTranslator<HelloWorldReceiver, HelloNote>() ); } void Receive(WorldNote* aWorld) { std::cout << " " << __FUNCTION__ << "(WorldNote* aWorld)\n"; } void Receive(HelloNote* aHello) { std::cout << " " << __FUNCTION__ << "(HelloNote* aHello)\n"; } };; }
If you would look at TConnector you will notice that the virtual function (connect) has an implementation which based on the design casts the receiver and the notification to the correct type.
If now you would look at IReceiver you will see that the InitialRecieve function uses typeid to recover the type information and checks it against an internal list to see if we have a connection for it. Since by dereferencing we will find out the original type we will work with a known type.
Now look at the receiver classes. You see that in each receiver class we need to store a connection. We have to define a connection and the corresponding function. If the connection is missing the data will not be send to their respective receive function. If the function is missing you will get an error.
There are also many things that could still be done to improve it
Also attached to the article you will find the entire solution inside a zip file: PatternDesign Connector.zip (4kb, source)
I have disabled to creation of user accounts on the website. There are a few reasons for this.
The first one is that I suspect spam as the email accounts are often gibberish (or so it appears to me) and the few I did active do not use it, which brings me to my second reason.
The site is intended for my personal use only. Although drupal can be used as a community portal, I have no intention to do so now or in the near future. Of course I'm always open for dialog either by mail or by comments and none of those are blocked.
If you have requested an account, I'm sorry to say that it will not give you any special rights above the ones you already have so there is no need to do so.