These days I’m very busy at work. Sometimes leaving the office after 11PM. I haven’t had much time to go to the gym and I’m becoming a bit obsessed with my belly growing. I really can’t afford to put more weight.. although I’m not really fat.
Monday and today (Thursday), on lunch break I went to the swimming pool at the gym near work. There I could relax a bit and lay for a little while under the sun.
I’m not a big fan of outdoor activities, especially not the beach etc, however it’s a bit depressing to see the summer go away. My body is generally a too cold and I should try to get some sunlight when I can.
At work I’m dealing with network programming. Suddenly, everything is message driven and tasks have to be subdivided by client and server side. Also, because there is no dedicated server, every console is a potential server by itself. That means that even locally some things will work by network messages, communicating by loopback.
My experience with network gaming is rather limited, although it started as early as 1995, when I worked on the PC (MS-DOS) port of Toshinden, which as an extra feature, it supported network play thought modem !
Most of the network work was done by the lead programmer (it was really just him and me working full time on it). What I learned from that experience is something that I still value to this day (that’s to say how little my skills in that field have improved !).
To the message driven nature of the application, it’s added a general need to make everything work asynchronously. A message from the server may bring the request to accept or reject a game session. Then one has a message box that has to answer to, the message box needs to be open as everything goes on behind. Unlike applications, one can’t really stop everything waiting for the user to respond. The game needs to stay alert as other messages could come to cancel an operation in the middle.
The problem with asynchronous programming, is that a simple program flow needs to be adapted to a state machine. Things are the thought in term of: I’m in this state, if this and this happens, then jump to the next state, if something goes wrong, go to the previous state, or possibly just another state. Then there are tasks that need to be started, wait for a result to come by some network messages then stopped. Also a task may partially or totally overlap another task in execution.
Basically, it all can get pretty confusing very quickly. There are always some exceptions that one deals with, one at the time, fixing something and breaking something else. Step by step, consistency is lost and the code becomes messy.
I really don’t like what’s happening with my code. I blame it on the lack of time. That’s generally true I think, but it’s also true that if I had more experience, time now would be less of a problem.
With frustration, also comes the willingness to find a clean solution to all this. Ideally, I’d like to get to the bottom of the whole message driven thing, become fluent at that kind of programming, minimizing the thinking. Also I’d generally get rid of the state-machine concept or, at least, be able to build a higher level interface which can bring me to the typical if/then/else/while concepts.
Posted by Davide Pasca in Uncategorized
