login | register

Our Sites:

Red Tower Games

Play free flash games

Rosamund's Bower

All the best patience and solitaire games

Like us on facebook!

Jansic's Blog

9th Apr 2009 - 09:17	Network You Eye
Why do modern games developers concentrate heavily on next-gen engines with whizzy graphics and ignore gameplay and usability like they're some kind of unwanted extra? Then push enormous patches to try to implement all the important stuff that they forgot after the game's already been considered a failure? My most recent game purchases include Red Alert 3 and Unreal Tournament 3. Maybe it's something to do with their numbering because they both suffer what are essentially the same set of problems. First up, Main Menu Interface. The main menu is the first thing the user interacts with and even the most brain dead of implementations can give you a usable menu system. Both RA3 and UT3 fail miserably here - with sliding swooshy screens, constantly rearranging button layouts and odd behaviours from the basic interface controls (who ever saw a scrollbar that wrapped?) you'd be forgiven for starting the game up and then going out for a beer instead. For the privilege of interacting with the new UT3 abomination you need to forge through 350meg of patching (and that's before another 1Gb patch that puts the content in). Flaws in the main menu interface inevitably spill over into the other menus, none more notable in both games than the 'network game' interface. For some reason both games use Gamespy as some sort of login database and lobbying system. I've always hated Gamespy, it's an entirely superfluous system and has never enhanced anyone's networking experience with less effort than just doing things by hand. RA3 hides its network interface under a picture of a star in the top right of the screen - there's a perfectly serviceable vertical menu in the middle of the screen but that's holding more important options (like the "Exit" button). Once you've found the network interface you have to log in through it and fight their bizarre lobbying system to find and invite your own friends into your game. The thing to note here is that neither RA3 nor UT3 host games remotely. You host your own game locally. The convoluted lobbying systems are merely a way of getting your friends connected to you computer. Which is probably how they wanted it to work but it doesn't... In RA3 you can actually invite your friends for a game but UT3 really fucks up this basic mechanism thus invalidating the entire design. UT3 differentiates between offline gaming and online gaming. You can't have offline friends and you can't connect to online friends' games. Get this - you can have a LAN game in offline mode but you can only play across the internet if you log in to Gamespy. Why? You're saying that I can get all my friends into my house and play but I can't route across the internet without UT3's help. What use is this help when it's actually no help at all? For UT3 you need to route 3 ports to be able to host a game 6500, 7777 and 13000. This is an annoying but not impossible step. Getting friends to connect is annoying too - you can't be just invited or even 'click through' your friends list - you have to type in the host's IP address manually by clicking a rather unassuming button off to one side (which is in only one of the two 'join game' submenus). What makes this worse is that it must be an IP address. Name resolution functions like "getaddrinfo" and dynamic DNS have existed for years and I can't type in a URL? When we move to IPV6 addresses will I have to type those in too? It's like trying to dial Mars only harder. sigh I haven't even got to ranting about the actual gameplay yet because neither game actually wants to be played! Maybe I'll leave that for another day.
Comments (1)

27th Feb 2009 - 13:53	He does so I do.
Sneeze posts, which inspires me to post. A potentially vicious circle if you ask me. FLib 2 is coming along nicely. Apart from a nice segregated design and increased modularity I've also changed to a different source control system on my home server. We currently use CVS on a remote server; it works and it works well, until you start adding more developers to the mix. We also have the problem that we don't own the server, so additional user accounts are costly and more projects consume more and more server space; especially when I want to version binary resources. Overall CVS is actually pretty poor at concurrent and distributed development. Merging changes from two people is easy enough but start adding more developers and amount of manual conflict resolution increases, as it does so the known reliability of the source drops - and what's considered your 'master' version starts to become a little hazy. I did consider switching to svn. I even gave it a spin on my local dev tree; and am confident that it is a good version control system. I use it at work with 100 other people and just like CVS it's really not well suited to concurrent and distributed development. While I tend to be allergic to most things Linus; I've been using 'git' lately for the new FLib source tree. It's interesting and very different from CVS and svn; and initially I was very dubious of how it worked. Essentially git is a multi-tiered push-pull system. Your working directory comprises the current source code, a local repository and a staging area for local commits and branches. You do your work locally and then 'push' your committed repository to a remote server. What's more is that branches in your local repository need not be mirrored in the remote repository. This allows you to create personal branches for experiments and local patches, yet still have the main branch available to you. When you're ready, you can merge selected branches together very easily; and when you're confident that it's stable you can push the main branch back to the repository. Anyhow it all seems to be working rather well and now I'm preparing for my next phase. Developing a new game idea! Which should be fun.
Comments (0)

9th Jan 2009 - 13:28	Hello World
Recently I've been investigating using DirectX 10 along side OpenGL. Mainly though tutorials and API documentation but also through the rumour mill... DX10 is a new way of working. Gone is the fixed-function 3D pipeline replaced with an all-new fully programmable geometry and pixel shading system. If you look at it in depth, DirectX10 designed around Microsoft think that graphics and rendering are going to end up. That place seems to be back to the world of pushing pixels by hand and to me, this is a good thing. For those that remember "mov ax, 0x13; int 0x10" and programming in mode 13, DirectX10 gives you an API that lets you push pixels around on dedicated graphics processor with a mass of vector instructions. You don't even need to think in terms of 3D if you don't wish to. As long as you can get to grips with Microsoft's new (more generalised) HLSL you can do practically whatever you like. So why 'Hello World' for the title? It's because of my 'rumour mill' research. The fixed function pipeline in OpenGL, you see, is easy to use; there's minimal setup and drawing triangles is simple. So removing the FFP from DirectX is a bed thing. Granted DirectX10 setup is more complicated and you need to be at least familiar with how COM works to be able to use it. The simplicity of drawing that first triangle is the 3D equivalent of writing "Hello World"; But the thing is, no matter how many times you write "Hello World" you'll never create a word processor. Similarly, no matter how many single triangles you draw, you'll never write a game. Some tools do their job well and DirectX10 does. The fact that it only comes with Vista is a pity; but is reason enough to upgrade to program for it. Rant over, time for tea.
Comments (0)

2nd Dec 2008 - 12:59	Stuffages
The FTO's fixed. Finally. It cost quite a bit but I've finally replaced the lower arms with rubber-bushes all round. It's fixed everything, from the sack-of-spanners like handling to the ride, it even brakes in a straight line. I also took the opportunity to adjust the tappet/valve clearances on the rear bank. It was an arduous and painful exercise but now the rear bank is noticeably quieter. I'll allocate some time soon to do the front bank, which should be much easier. On the development front I've been doing some more work on my MMO development server. Recently I've been having problems running it on Vista and a little investigating narrowed it down to the way Vista deals with IPV4 and IPV6 addresses. To be honest, the fault is all mine - I ask for an address (and I get one) but I don't provide any hints as to what kind of address I want. Vista prioritises IPV6 addresses over IPV4 ones so unless you cope with the return codes, or have disabled IPV6 you'll always get one. The reason it works on linux is that, despite having IPV6 configured, it defaults to returning an IPV4 address. Rather rarely I think the Vista approach is the correct one. Granted, lots of casually written software will no longer work but it should push the correct use of the sockets API and at least help the adoption of IPV6. Talking of sockets; isn't the BSD sockets API absolutely crap? What happened when they came to design the address structures? I'd have used a nice union, like the XEvent or Variant structures, but no. The sockets API makes you use and cast opaque chunks of incompatible address data around in the hope that all the fields line up between revisions. Rubbish.
Comments (0)

25th Nov 2008 - 13:17	Alive and newsical.
Today Squaresoft have released a rehash of the original Chronotrigger for the Nintendo DS and I think that's just amazing. Aside from some extra content it's practically identical to the original and that somebody had the motivation see the port through to completion makes me even happier. Chronotrigger is, as far as I'm concerned, one of the greatest games of all time. It lives in my top 4 favourite games along with Outcast, System Shock 2 and Final Fantasy 6. In other news I've been investigating scripting languages for my client-server networked content creation project. Normally I would write one myself - I have the ability to write the tokeniser and the virtual machine - that's easy; but implementing the language expressions and compilation of constructs is hard and time consuming and I really have better things to do. So far I've looked at LUA, Gamemonkey and Angelscript. LUA is distributed under the MIT license and is quite popular (it's used in WoW for example). It's a tried and tested solution, it's pretty quick and easy to get to grips with. The source footprint isn't that big either. There is also a LUA JIT project floating around - though execution speed isn't my main concern at the moment. LUA does have a couple of downsides, firstly it implements its own custom language which steepens the usage learning curve and also the integration code and setup boilerplate is overly verbose. Gamemonkey, like LUA is MIT licensed and based on the same kind of ideology. Difference here is that Gamemonkey uses a more acceptable C-like syntax and does a reasonable amount of optimisation. Downsides for me are that it's built with bison, lexx and yak, making it much harder for me to modify without learning a different toolchain. Similar to LUA, Gamemonkey has nauseatingly verbose macro driven integration code and finicky boilerplate. Angelscript is completely free, released under the zlib license. It implements an object-oriented, typed, C-style language with garbage collection and integrates very well with applications. The source is pretty concise too. I have several qualms which stem mainly from the fact that it's not particularly well optimised. It's in-script string handling is reasonable but the engine implementation makes a real mess of memory. Compile-to-run performance is mediocre and its memory usage patterns are not friendly to long-running applications (like servers). I've looked at several others but these are the main contenders. Overall Gamemonkey looks like it does the right thing but is marred by its evil macro oriented integration syntax and reliance on external tools for modifications. Angelscript is the best language wise but really needs its implementation revisiting. If anybody sees any other suitable languages, please comment somewhere.
Comments (0)

13th Oct 2008 - 22:54	KDE 4
In a fit of boredom I downloaded and installed KDE 4 and I'm really quite surprised at how bad it is. I thought the new Vista interface had missed the mark by a few miles; but KDE 4 isn't even on the same map! Copying and tweaking the basic Windows UI mechanics served KDE3 very well, I'm not entirely sure where they got the new system from. Anyway, it doesn't really matter to me. As much as I dislike the GTK toolkit, all my Linux development systems are XFCE and Gnome.
Comments (3)

7th Oct 2008 - 13:36	CodeLite
One of Linux's biggest strengths as a development system is also one of its weaknesses as a development system. The system comprises hundreds of separate little tools that you can use to do pretty much anything you like. With all of this power and choice comes a lot of added confusion and you often want to do much more simple things. That's okay though, because the vibrant OSS community also develops simple applications to help you too. The problem here is that you have a balance between power and usability. People thinking from the developer's point of view and people thinking from the user's point of view. As a result there's a big wide dividing line down the middle where the power tools and the applications meet in a horrendous rats-nest of half-arsed and half-implemented solutions. My current (simple) setup is gedit, make, gdb and a terminal. It's the simplest high-yield configuration I've come up with so far; not for the lack of trying however. For text editing I used to use nedit but its ageing x-motif interface, cryptic xresource based configuration and lack of full support for hinted truetype fonts (invaluable on large LCDs) makes it much less appealing to use in a work environment. Gedit is generally a better editor, it's much lower effort to use and does almost all the right things. There's the keyword though 'almost'. Gedit is flawed by lacking all the extra functionality that nedit has always had. There's no regular expression search, block select or native c-tags support to name a few. There are a variety of IDEs available for Linux and I'll list the main ones here. KDevelop, Anjuta, Geany, Code Blocks, Eclipse and MonoDevelop. They all have very specific strengths and all have glaringly fundamental weaknesses. KDevelop only really excels at Qt development, Anjuta's just a container for mess of plugins, Geany suffers from lack of integrated debugger (and uses the Scintilla editor of all things), Eclipse needs a stable Java setup (and C++ support is provided with a rather mediocre 'add-in') and finally MonoDevelop only really does C# development. While I have a few rants there already, the fundamental problem with IDEs is that they all want you to work how their authors think you should work - an approach that's not very compatible with the underlying power of the linux toolchain. I could go on ranting for hours but anyhow I've now found a new IDE. CodeLite is your usual text editor and bits of bad design squashed into a single program. The difference here is that CodeLite mostly does the right thing. I can have a usable text editor, block select, a code browser, an integrated debugger, code completion and I can use a makefile based build system.
Comments (0)

6th Oct 2008 - 22:39	DecX
While I experiment with vLite have an interesting article to read. It's interesting because when the OpenGL 3.0 spec came out earlier this year; I did a bit of research and decided pretty much the same thing - DirectX 10 really does look better on paper.
Comments (0)

6th Oct 2008 - 13:07	Waaargh!
Okay, online ordering has gone insane. Completely. After buying my computer components at Dabs for some years now and getting a generally very good service, Dabs have decided to be very annoying. My 7 year unchanged address/card combination now required a 'security check', to which end they e-mailed me to ask to 'confirm' my address. I logged in to my account, saw the order had an 'authorisation problem' and ensured that my address was correct and e-mailed them back with "the address in my account details is correct". Today I received a reply to my e-mail telling me that 'the security check failed' and requesting that I 'confirm' my address. I returned to the Dabs site and saw the 'authorisation problem' still pending. A quick phone call to my bank confirmed that there were no blocks on my card and that also, nobody had requested card authentication from them for that transaction. In short the transaction is held up at the Dabs end because they can't confirm that I'm me. The problem here is that they can NEVER confirm that I'm me. I can log into my account and twiddle all sorts of details, including the contact e-mail address; no amount of reiterating the addresses via (an essentially anonymous) e-mail exchange will give them any more confidence that I am who I say I am. With full control of my Dabs account details and a valid card, I can't do any more without knowing what bizarre mechanism I need in order to satisfy their request. Anyway, in general annoyance I deleted half of my order and placed another order at Scan. Scan managed to make login, ordering, payment and delivery process as excruciating as possible. After I'd scrabbled through the whole process and actually placed the order I was disappointed to find that you couldn't view your order until the payment transaction had actually completed. Once placed you can't modify or cancel your order via the site AND I still haven't had a confirmation e-mail. So I have half an order at Dabs and half an order at Scan. If Dabs can't sort out their end in the next day then I'll cancel the remainder of the order and start looking for other places to shop. Ordering things online used to be easy. What happened?
Comments (0)

2nd Oct 2008 - 13:27	Post-Holiday
So, I've been on holiday. Malta was nice and hot, reasonably relaxing and totally unforeign. It's a strange experience to travel thousands of miles for a holiday and end up in what is essentially Brighton-in-the-Med. No matter, it worked as a holiday and that's a good thing. Having a holiday allowed me to sift through my current rat's-nest of a development plan and bring everything back into some sort of order. The free time has also given birth to some some new ideas and new perspectives on the current state of things. First and foremost FLib2 functionality has been narrowed down to a simpler subset of operations. Once completed I want FLib2 to be able to supplant the C-Runtime on platforms that don't rely heavily on it - MaxOSX and Windows. Secondly I'm going to move ahead of the technology curve. Some research into DirectX 10 and a little comparisons with previous DirectX technology shows that to get the power and flexibility out of modern systems I need to move beyond technology that's 5 years old. As such I'm not even going to consider targeting OpenGL 1.0 fixed function pipeline - the main reason being that the older fixed pipeline and more recent programmable pipeline are not compatible in a way that's conducive to a simple interface. This doesn't rule out OpenGL 2.2 of course; but identifying baseline OpenGL 2.2 support is harder than the much more uniform DirectX 10 API. So I've installed Vista 64. It's the only way I can get a DirectX 10 implementation and I also want to move to more 64 bit development. So does this mean my Linux development will suffer? The answer is both yes and no. I've realised there's much more to be gained from wrapping Linux in a thin layer and presenting it as a more consistently designed API than there is trying to use 3 different platforms' interpretations of the Posix API and C-runtime. The original Flib went out of its way to support odd configurations and bizarre setups for all manner of OSes. One of the ways that FLib2 is being simplified down is by treating the platforms as single unique API configurations. There's only one Windows API, there's only one MaxOSX API and now, for me, there's only one Linux API: X11 is my only WM, pthreads is my only threading model, BSD sockets is my only network model. Anyway that's a lot. More later.
Comments (0)