Quick links

• About Lost Squadron
• Todays topic
• Dvorak keyboard layout
• CountMostUsedKeys tool
• Own keyboard layout
• Useful links

About Lost Squadron

Currently we at exDream have finally started working on the next project and will produce a nice graphic demo/prototype in the next 3 month. I will try to sneak in a couple of screenshots of it from time to time.

Todays topic

We talked a bit about other keyboard layouts like Dvorak, which is way more effective and relaxing than any qwerty layout, but I got no free time back then. You will need around a week to learn to type at low speeds and at least a month to get back to a better typing speed.

Dvorak

After Arena Wars was finished last year I got finally some time to start learning Dvorak. Dvorak seems very nice (see the links below for additional information) and has a lot of advantages for typing "normal" text (but some people exaggerate "a little").

Anyway, while playing around with Dvorak (us default layout) I really found some things VERY annoying, especially for coding and playing games:

• It is fairly hard to learn a new layout and getting really back to the old speed again. Additionally hotkeys you typical need on a computer are totally crazy and unusable. Hard to learn when you used QWERTY all your life, learning can be done in a week or so, but really being able to get back to your old speed can take months (and is painful).
• Ctrl+X, Ctrl+C, Ctrl+V can't be used as easy. I always use my left hand while my right hand can use the mouse, especially for browsing, code comparing, getting text from one place to another, etc. and all this happens VERY often! I know you can also use Shift+Insert, Ctrl+Insert, Shift+Delete, but these shortkeys are just plain unuseable, maybe for lefties, but the keys still suck.
• Hotkeys can't be used the way they used to be, for some games its possible to change hotkeys, for others not (like starcraft, at least its not easy to change) This does not only apply to games, but also a lot for applications, especially when you remembered just the location where to press and not the name of the hotkey, e.g. when using photoshop, you have to re-learn the hotkeys. Also stuff like Ctrl+S, Ctrl+O, Ctrl+F, Ctrl+R, etc. is usually remembered by the positions on the keyboard and not by the key and relearning this keys is pretty hard!
• Dvorak is optimized for typical english words, but not for programming, some keys are even worse than the german keyboard layout. But what I really don't like is the way Dvorak handles symbols like []{};:?+-/, etc.
  Its not that QWERTY is really good for coding, especially when typing stuff like () or -, = or +, but overall it performs still better than Dvorak (counting only symbols).

I've also collected some interessting facts when comparing Dvorak and QWERTY considering c#/c++/java code. Click this link to test it yourself.

• When pasting random stuff into the Keyboard Compare Applet, QWERTY performs almost twice as good as Dvorak (Note: We are not random key generators, usually we type text or code which makes sense ^^).
• When just pasting c# code stuff without much text like
  if ( a == 0 )
  {
  doIt( a!=0?a:0 );
  } // if
  QWERTY still outperforms Dvorak, which can't be good!

I created my own keyboard layout to solve all the problems (yeah, now its getting real geeky), but I based it on the Dvorak layout, which is really efficient and nice for typing "normal" text (which is still required a lot, even by crazy coders).
To solve the Ctrl+X, Ctrl+C, Ctrl+V problem I simply moved that keys to the QWERTY position and exchange the other keys accordingly. This didn't matter much because there isn't much of a difference between X,C,V and Q,J,K according to the key usage (see below).

At this time I was already using Dvorak for about a week or two and had spend a lot of effort into learning and thinking about improvement, I wanted a perfect solution. I checked typical c# and c++ code and wrote a program to count how often each key is used. Now I got the most important keys and asigned the best spot for each symbol using the distance (see the Keyboard Compare Applet) and how much it is used. Using shift is also a major impact IMO, especially when keys are far away.

So I wrote a little test program to count the used keys in all my *.cs files in my code folder, check out the results below.

Screenshot of the program (I improved it yesterday, it was a console tool before):

abi/blog/CountMostUsedKeys.zip">Download the CountMostUsedKeys program.

abi/blog/CountMostUsedKeys_src.zip">And the source code for anyone interessted
(may be useful if you want to write some line count tool yourself)


CountMostUsedKeys results:
Search mode=Everything, File type=*.cs, Directory=C:\code\
Number of files=4041, Number of lines=2031908, Number of keys=67829575

Same results without space and letters, very useful to assign the most important symbol keys:
Search mode=ExceptLetters

Based on that I created my own keyboard layout, which was updated 9 times until I was happy with it.

Version 1 looked like this (pretty much like dvorak, some cosmetic changes at the right side):

Version 2: The next thing I did was moved the Z X C V keys back and copied some keys around, () are moved to normal keys, () is used much more than [] or {}.

In Version 3-6 I tried moving some keys around based on the distance and effectiveness, but I moved most of them back because they felt really uncomfortable and were bad for hotkeys. One bigger change was moving the . , () keys back down, which improves typing speed a lot because we really need more keys on the left side when using the mouse with the right hand and when typing the right hand can easily handle most of the symbol keys on the right side.

Version 7 was pretty much the final version, I trained this version a week and except some minor cosmetic changes in the upper row everything stayed this way till the last version:

Version 8 and 9 changed only the positions of J D F K B and the ? | and + - keys, at first I didn't like the position for b at the right side, but b is used a lot in combination with vocal keys unlike j, it is much better to have it on the right side. The + - key on the upper left is now the same as the key on the lower right (which is not present on all keyboards).

This is the final Version 9 I am using for nearly 6 months now, I got up to my old speed in the first 1-2 months and now I type even faster and more relaxed than before (maybe around 400 keystrokes per minute for normal text if I try hard). I wouldn't suggest changing your keyboard layout just because you might be a little faster with Dvorak or my keyboard layout, I think the comfortablity is at least as important as the speed. In my option the greatest thing about my keyboard layout (or dvorak for normal text) is the fact you can type most of the time without moving your fingers much (90% of the most used keys are directly on the center row).

abi/blog/abiKeyboardV9.zip">Download AbiKeyboardV9 installer

I was not trying to create the best keyboard layout ever or to make Dvorak obsolete, I just want to improve it for me and other interessted programmer. If you get started with Dvorak or my keyboard layout you should use some keyboard training tool and spend a couple of hours (but not much longer) each day training it. I found this website very useful: Learning Dvorak

The main reason I wrote this article now was the nagging of some people I told about this and who wanted to know more, so keep nagging if you want to see articles like this :)

If you got comments or some ideas to improve this even more, let me now!

Useful links

Ok, so I skipped that idea and returned back to Lua and finished the EffectManager on the Lua side making only a couple of calls to c#. This did not only help to learn more about Lua and scripting, but I also improved the c# engine very much and spend a lot of time simplifying code of the engine. Creating textures, making unit tests, error handling, etc. all got much easier (this comes when working with Lua and then looking at c# code and thinking everything is overly complicated). Anyways, Ivo and Fabian didn't do much either on the game and so we got stuck in the development and started today again and made a new schedule to finish the game at the end of next week. We will include some left out ideas and have gotten some new improvements on the game, the editor and some units. Ivo did also start some new objects (buildings and enemy units), there might be some fresh graphics for that soon.

Over the chrismas and new years eve weekends I read some more of my Lua and Rapid development books and yesterday I started reading Code Generation in .NET by Kathleen Dollard, which is also very interessting and got me in a lot of thinking how to improve coding in general (not only using scripts and code generation techiques, but going 1 step ahead and create new ways to handle coding and reusing existing code).

Well, first of all Lost Squadron has to be finished

Useful links today:

• Free game libs (mostly c++ stuff)

I spend the last couple of hours trying to get Unit Testing on the engine level to work and I finally got now everything up and running. This is really one of the greatest things ever in Game Development IMO! Normally I would spend a lot of time changing code to just test stuff or even write small test application only to check the behaviour and graphical output of effects, newly imported textures or models or new game features. Now I can just write a VERY short Unit Test for that INSIDE my project, no more extra projects, no more messing around in the code.

Just to make this clear: This is not a usual Unit Test like in other parts of the engine, like when checking file input/output, internal methods or some logic issues. These Game Unit Tests (thats how I will call them from now on, or just GUT, which is german for good ^^) give you all the features and easy testing possibilities like normal unit tests, but you can initialize the whole engine, see visually whats going on and shut down everything automatically or by user input. Let me give you an example how this looks:

Note: This code uses .NET 2.0, if you want to read about Anonymous Methods click here.

Same thing is of course possible with a couple of lines more code when not using Anonymous Methods (using Events or just duplicating the code in TestInitEngine). This code will create all the stuff required for the game engine, then execute the initialization code to create the effectManager. Then it will proceed to the game loop and execute the render code each loop there, everything will be shut down if the user quits the form, presses some key or if we set a timeout to quit automatically. There is a lot of hidden code behind all that, but this is exactly the code executed when just running the game and testing that is always good

In the next 2 days I will not code much (visiting family, chrismas, etc.), but I will to read 2 nice book from Steve McConnell: Code Complete 2 and Rapid Development. I already read a couple of pages of Rapid Development and it is really written good and very interessting.

The next Lost Squadron screenshot will be posted presumably in 2 days.

As you can see on the screen I completed the roads stuff and added some new objects. Also as planed yesterday the moving around and mouse aiming does work now, but I'm screwed again with those X files, there are totally messed up (rotation wrong, each object is rotated differently, meshes do not fit on top of each other, the upper part of the tank does not have the same pivot point, really annoying), grr, but I don't have the time to write an own 3d-model format (or import any format into the engine, 3ds would suck at a similar level).

I also started the game message classes and most classes needed for gameplay are existing now, but most of the functionallity is missing. I will try a new approach this time to write that code: Unit Testing. Many smaller methods of the internal engine are already checked, but I never done large Unit Tests for a whole game. The tests should be able to run the whole game (creating units, moving around, blowing stuff up, doing graphic effects, winning, losing, etc.). I will report back how that works. Later today (when I slept a couple of hours ^^) I will start that stuff with my intern Fabian

So the new date for the first Demo version of Lost Squadron is 2004-12-31. It might be playable tomorrow already a bit, but I don't think it is wise to release it so early. The first experience should be very nice and for a quick look you got the screenshots here ^^

Here is a fun link about Programming Languages and why some of them failed and others not:
why-microsoft-can-blow-off-with-c.html

I had another idea to just test the alpha values for 50% alpha and then skip writing to the frame buffer and that didn't work either (framebuffer is full of false pixels anyway). Instead of banging my head into the wall I just steped back and thought about needing this feature at all and no, there is no need for that in this game: I can just delete or don't use anything with multiple alpha layers. For example the palm had 3 layers of palm leaves, but I killed 2 of them and no everything is working perfectly (I still have to sort objects and to render first solid, then alpha materials, but thats pretty fast). I'm happy I got this solved

The Editor was also improved a bit and everything needed for a full mission can be set there. As you can see on the screenshot there are a couple of new features for the map: Roads, some more neutral objects and some enemy units. Shadows and shaders would be nice too, but there is no time for that right now. Maybe I will be able to put that into the engine next week.

Moving around with the tank and aim and shoot on stuff should work tomorrow. Effects and AI won't be complete till christmas, there will be most likely only a couple of standard effects. Also collision detection is another big issue.

So I ended up writing a nice LineManager class, which collects all lines draw each frame and put them in a vertex buffer and because the lines are only changed when some big change happens, the vertex buffer can stay the same for a long time and thats really fast. Everthing gets rendered at the end of the frame (used for on screen controls and other stuff anyways). Same thing for filled boxes, color blending effects, etc. lots of helper classes.

The texture blending (as you can see in the image) was also not a piece of cake, but the blending over 5x5 vertices is now a nice technique. The textures are not really fitting good together, when you just put them besides each other, but with this blending technique it looks really good (or maybe I'm just to tired to tell anymore ^^). Another bonus is my new vertex format, which is compatible with a test shader I wrote 2 days ago (which didn't run correctly back then, I only managed to do some basic stuff). Seems like some arguments where missing and the vertex shader wasn't complaining, but crashing some time later (after couple of calls, not really funny to debug).

There isn't much time left, so maybe some features might have to be put on hold because I really want to finish the base game this week (just 1-2 missions, only basic features to see if its really as much fun as I imagine). If its playable a small demo or some sort of beta-version will be available before chrismas this week. Anyways, till new-year the game and the final demo-version should be finished, lets see. Maybe in the next couple of days things can be done more quickly because all the base classes and the complete framework are now completed.

The UI needed also some improvements, so I made completly new graphics for them and updated all UI controls and added some we needed for the Editor. All this little things, like writing UI code, writing smaller classes for the ground textures, the road logic, neutral objects and the enemy units can really keep someone busy. I still hope the basic engine for this game can be finished this week, so we got next week to make some cool missions and the advanced stuff (shooting, effects, multiplayer).

About all this shader stuff from the last couple of days: I managed to get some basic shaders to work, which is really nice now, but still no clue how to implement all that spotlight normal mapping with alpha blended textures. Maybe I will just use some sort of directional light for the bump effects (or maybe a point light if I can pull that off, but then all the lighting calculation has to be done inside the shader as well, uhh complicated).

Because of all this problems there is no real screenshot this day (with all this shader errors Lost Squadron isn't looking pretty today ^^), but you can see my first shader version of normal mapping on the right. Tomorrow will be the last day I will try out to get this goddamn shaders to work, else I will just leave them out and finish the rest without any high level shader support and maybe add them later ...

Other than that I tried also to implement the ground normal map shader I developed yesterday for the last couple of hours, but I can't get it working. Some mul operation always crashes inside my shader and is very hard to debug. Maybe I need to debug everything with DEBUG_PS and DEBUG_VS. Well, I hope I get that working tomorrow.