Test run Windows 8
Today at the office I download and installed the developer preview of WIndows 8 in VirtualBox. The first thing I noticed was that the installation was fast. It was a similar installer as Windows 7 so no big suprises there. After installing and starting it for the first time I was suprised to see a really green screen. The windows color for me has always been blue (which is recuring theme in almost every Windows version since Windows 95). After completing the create account procedure and logging in you notice that green is the new blue, almost everything is green and as you have noticed I'm not too big a fan of green. But enough about green, lets go to the part that is important.
After logging in you are presented with the new Metro GUI which is confusing if you are not familiar with it (and even more if you have no touch device). So a few hints:
- If you move the mouse completly to the left bottom you will see a start menu. Clicking on start will always bring you to the metro page.
- If you move the mouse to the rightside of the screen you will get to see a thumbnail of the application to switch to
- Left mouse click will switch to it
- Scrolling will display other running applications
- Right mouse click will give you the snap options
- Alt-F4 closes applications
- The windows key will switch between the metro interface and the application
- In metro applications the right mouse button often shows menus at the top and bottom, but you will never see quit (which confused me a lot)
- Windows-R gives you the run dialog and yes mspaint, wordpad, notepad, explorer are all available.
- Seen enough and want to shutdown? Move to the left bottom and click on devices and you will get a toolbar on the right. The center bottom button there is a power off button.
After playing with it for a few hours there are a few things I like and a lot I don't. Keep in mind that this is a developer preview so I'm sure a lot will change before the initial release.
The things I liked where:
- Snapping works well and frankly I love it. This is done way better than I have seen before.
- The twitter app looks good, works good and when snapped to 1/3 of the screen it is just a killer app
The things I don't like are:
- It's confusing, it took me a while to get around
- No good replacement for touch if you only have a mouse
- I miss the old start menu (which is a first since I enjoyed each new version of the start menu so far)
- Scrollbars are ugly
- Metro interface is confusing
As a closing note I would say that Windows 8 is not suitable for coorporate enviroments (no good function for metro interface) and is more aimed at the tablets. If I would have to pick a tablet I would wait until Windows 8 for tablets is ready.
Taking a look at NoSQL
At work I have been tasked with writing a new version of the application server which is considerable different then the current version running. Since I want to restructure the database I have decided to take a look at how I can improve the Data Dictionary (that what defines what and how things should be put in the database).
The problem is as followed our security software knows many devices (many different cameras, intercoms, fire alarms, door locks and so on). We don't just support one vendor, but any vendor the customer wants. Of course each vendor has it's own method of implementing it's configuration. In the old software we had one huge table called "devices" (no points for originality there) that contained every device of the customer. The table contained not only the type and locations but also the various properties in a single row. There are two other alternatives.
One in which we create two tables where one holds the generic device description and the other which contains multiple rows for one device. This is an inefficient format.
The other alternative is that for each type and brand we create a new table. So we have a table for acti_cameras, axis_cameras, sony_cameras and so on. I think we support over at least a hundred devices so that is likely to go wrong.
So I have been looking at alternatives like NoSQL database. NoSQL is not a formal term but in general it means "Not Only SQL". It's a new development inside the database world and one I think that is certainly worth looking at. The first SQL was created in 1974 which in our line of work is really old. I also want to point out that it can only be so old because it has proven it's value. NoSQL on the other hand is from 1998 and the most common flavors are Key-value and Document store and graph.
Document store is in my opinion the coolest one as you can often just dump the data in any table. You don't need to look at the format. This would mean that we can still freely define types but at the same time we can also have different values and parameters.
There is only one downside: Eventual Consistency.
I understand the reason behind it (delaying writes while allowing reads) but there are plenty of situations where it is not acceptable. Sure you can catch it in your application layer but again that is not what you want.
Currently I think the best method is using MSSQL where a row also contains an XML document.
Service your code
In the past week a friend of mine tweeted that debugging took so damn long, because he had to compile a lot of code, load the game and wait until the level was loaded before he could test one specific feature. From experience this can easily take more then 10 minutes of your time, while to solution is only a boolean check that needs to be inverted. One of the solutions I proposed was to put it in a DLL and dynamicly load (and re-load) that code until you have solved the problem and as I was typing it out I realized that this could be applied more often.
If you create a core application against which does only a few core elements (like basic rendering and providing input) and you put the rest in DLL which can dynamically be loaded and unloaded you will in theory never have to touch the core application again. The rest are all buildingblocks which are continuesly improved. If you do this, you can easily rollout (or rollback) features. Even cooler is that with another product you only have to write a few new buildingblocks (assuming you continuesly improve your old buildingblocks), create new content and your done.
If after a few years you want to re-release your game but you want to use the improved render, all you need to do is replace it. No more memory leaks the old version had 
But for that we need to continuesly serivce our code, something I believe is rarely done.
Mercurial switch notes
At work I have taken the librarity of proposing to switch from Subversion to Mercurial and the following are the results of typing out my notes.
The major advantages of working with Mercurial over SVN are:
- No unexpected merge (or merge conflicts)
- Developers can work independent of each other. They don't have to worry about commiting broken code, only syncing broken code.
There are two types of branching:
- Unnamed branches
- Named branches
Named branches are comparible to what we know from SVN. Unnamed branches are done when you have reverted to an old changeset and then make a change, they are like an automatic branch that occur where normally (in SVN) you would have conflict.
An example can easily be created by making a few commits, then revert to and old one because you want to try an alternative approach for a problem you were having and start commiting then. Once your done with the alternative you can decide which branch should be closed and which one should be continued.
When syncing your changesets with someone else, you make it possible to look at what the other has done without having to worry that your own code gets broken by the changes. For example you encounter a problem and notify another developer of it who tries to fix it while you continue work on your own problem. Once both of you are done, you can review each other code without having to merge. Then one is tasked with merging it while another continues with his tasks. Once done you simply merge again and you are done.
You can always sync your code with a central repositorie. It's not uncommon that you are working on a large issue which might take a day or two. With Mercurial you can still commit as you normally do and if only a central repository is backed up you can still push your changes to that location without interfering in someone else his work.
Another great feature is shelving. Simply put it puts your changes on a shelve. Imagine you are working on a feature and suddenly you have to put that on hold as your boss wants you to work on a bug. You can either complete what you were working on or revert all changes. With shelving you put those changes on the shelve and when you are done with whatever had a higher priority you can take the changes from the shelve and continue as if nothing had happend.
There are, as always, a few bad things about moving from Subversion to Mercurial. First of all, Subversion is linear which gives you a linear method of developing. Secondly because Mercurial automatically creates branches and you would have to actively control this by doing merges often.
Mercurial has a lot of nice features like being able to import from SVN (nice if you want to do a complete switch) as being able to rebase (similar to Git). Also Mercurial could easily be intergrate in our toolchain.
Since I mentioned Git, I would like to say that I have thought about it but decided against using Git. Git has no native version for Windows. Git was also hard to start with, heck, the installer alone requires several extra steps. As a developer I don't want to worry about the tools or how it should be used. Mercurial was ready with just a few steps and working with it is quite easy compared to Git which I was messing around with for a few days. So basically the choice was made on personal preference
Inline skating
When I was young I loved to my skates (I called them skeelers even though they had four wheels) and I did it quite often. So yesterday when the weather was just perfect I decided that I wanted to do some inline skating even though I had not touched a skate in the past six or eight years. I looked up on the Internet what the current state of the industry is, relearned the things I had forgotten about skating (the theory) and was deciding where to buy them until my mom reminded me that six or eight years ago I had bought these excellent skates but had only used them for a week or so.
So up in the attic I searched for my inline skates and found them in one of the boxes. I had indeed bought them and I recalled that they were quite expensive for me at the time. They were bought in France when we were there on vacation and I had indeed used them for only a week or so before I boxed them in the attic. The weather in the Netherlands was what excpected in the Netherlands: Nothing but rain. The year after that the weather was also poor and so I forgot all about them.
After cleaning the frame and wheels (I had not done that when I boxed them 
) I geared up (wearing protection for elbow, knees and wrist), I finally got up and... almost planted my face on the ground. I admit I knew that I would have trouble skating again, but except the first time I wore skates I had never had any trouble getting up. I guess that the years of sitting behind a desk, hitting the keyboard while writing code had not improved my balance. Big surprise there. However that was indication enough I had to learn everything from scratch again.
So after a few test rounds on the parking lot, learning to brake and to turn I was reminded why I didn't like skating on the parking lot with these skates. The wheels of my skates are 80mm 82a which means that they are small and reasonable soft and the the parking lot has a lot of bricks. So after a few minutes you feel like your feet have been put in the blender. Leaving the parking lot behind me I left in a random direction. I'm proud to say I did not fall, but it took a lot of effort and I wouldn't be suprised if I have lost my balance more than 20 times.
When I decided to rest I was tired and everything hurt. My arms from spinning, my feet from the poor road, my back because it wasn't used to bend like that and my head because it was the middle of the day and it was hot. After a few minutes of recovering my breath I decided to go back home. To my suprise going back was a whole lot easier. I only lost my balance a few times, four or five times if I recall correct, and the rough tarmac didn't feel so rough anymore. I enjoyed it. The distance skated was only 8 kilometers (about 5 miles) but for the first time after so many years it feels like quite a feat.
I only hope that this weather will stay as I want to do some more skating.
The state of the game
The game that I have been working on will most likely be delayed as in the past month I have been distracted by my new job, my younger brother graduating, looking for a place to stay and a few other things. In addition I also bought four games which of course need to be played as well.
Because of all those distractions I have decided that I will take some extra time, relax, smell the roses and stuff and then start again this month. The result is that I will be behind, but that is OK and knowning myself I will most likely catch up at one point.
Image from: http://www.studiohajo.nl/ (license unknown)
New job!
When I first created my site, I once joked that it is, besides a platform for me to talk about various subjects, it would also be a professional business card in which I present myself to any prospecting employers. Well, the joke is on me, since I was actually contacted through the "contact me" form and was offered a job. I went in on the job offer and within two meetings I had signed the employment agreement and I have a really good feeling about it.
The downside is that I had to talk to my current boss about me leaving, which I did the next day. I have never done something like this before and the only time I was "let go" was due to the fact there was no more work for me. But instead of getting angry or sad I was happy with the news. The HR (Human Resources) person who brought me the bad news had trouble understanding this (I was smiling) and I had to explain that I didn't feel OK with only showing up and then do nothing. Maybe it is my sense of pride, but I rather have no job than not doing my job.
So that day I asked my boss if he and I could have a few private words and explained that I would be leaving. I had talked it over with my dad how to do such things and what should be done in which way, but my boss was a true sportsman and except a request if I could stay one month longer to give him more time (which I declined) there were no problems. The reason why I tell this is because there are plenty of stories (often American) where someone is escorted from the premises without even giving them time to grab their jacket. Those are horror stories and a clear case of a lack of trust and proper behaviour, but this was the exact opposite.
So that is the news. I have a new job starting the first of May (well second actually since the first is a Sunday) and except the bit of overtime at my old job to ensure that me leaving there has a minimum impact (technical documentation and finishing a few projects) it seems there are no problems professional and personal. Now all I need to do is find a new home and wait until it is time.
The editor
I have written a few level editors, often only intended to be used with a certain project and once something that was intended to be used a common tool. Often I see it as welcome change and use the chance to work on something else.
For my current project I was conflicted about what to do with the terrain editor. I had two choices, either create a seperate tool or integrate the editor in the game. The first choice always has my preference as a tool and a game have different usage requirements which is reflected in the way they are programmed. The second choice is also a risk in my opinion as you might couple part of your codes that should not be coupled. Decoupling them afterwards is, as many programmers can tastify, a pain.
However the advantage of combining the code is that I don't need to duplicate code or functionality. This is also the reason why I have decided to create the editor in the game. The cool thing however will be I can review the results of my work in realtime.
However before I can start working on terrain editing, I need to write the terrain code, which means that I need to start thinking about the culling acceleration structure and refresh the knowledge about terrains.
Scared to code
The project I'm working on at home is making steady progress. I'm on schedule, the code is of high quality (even higher than I had expected it to be at this point) and as the architecture becomes more and more mature I'm getting more and more optimistic about my goal: A commercial game.
So why, if everything is going so well, do I write an blogpost that is titled "scared to code"? Was I not getting more and more optimistic?
That is because soon I will be done with the majority of the architecture and I have to actually write the game code and to be honest there I no complete design document only an feeling that I want others to have when they play the game. The game design is therefor mostly informal which means that without a formal definition I won't be able to measure how far the game is complete. Now I know there are plenty of people who are able to work that way and get incredible results, but I know that unless I have a formal definition I will continue working on the game forever. So either I have to make a formal game design or learn how to cope work with informal game designs. I don't think I can do the first part as good as I used to and I fear what would happen if I choose the second option.
Now don't get me wrong, I have worked in both ways and got results. I do prefer formal game design as they are more predictable and it is easier to know what is inside or outside the scope of the project. The problem in this case however is that I have decided on a hybrid method. The game should be developed until the end of Juli which means that somewhere in August I need to release the game, as this is one of the restrictions I have applied on the project. So what I at least have is an schedule and I'm happy to say that I'm good with scheduling tasks and projects. However I have never made a schedule without having a formal definition of the end result of the product. It's not the way that I usually work and most certainly not the way that I prefer to work.
Writing a decent engine is pretty straight forward, there are some things you need to take in account, but if you have written a few, than writing a new one is more like a warming up then actually trouble. Each game however is a different so there are no warming ups. You might be able to use a few tricks that you have used for other projects and use it here, but overal the code is completely new. Now next to me is a single piece of paper on which I have written the schedule. The schedule is quite decent but at the moment I'm afraid of moving on to the game code.
The strange thing is however that once I start working on the game code, I know that the fear will disappear, but until then I'm scared to death, uhm.. scared to code.