Skip to main content.
September 2nd, 2005

The thousand faces of programming

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

This entry was posted on Friday, September 2nd, 2005 at 2:20 am and is filed under Uncategorized. You can follow any responses to this entry through the comments RSS 2.0 feed. You can leave a response, or trackback from your own site.

4 Responses to “The thousand faces of programming”

  1. ragin' lion says:

    Mr. Kaz, I’ve some painful (but useful) advice for keeping the weight in control during those long coding sessions … eat only as much as you need and try to drink mostly water. It’s so easy to snack and pile up on the junk (and thus inflate like a balloon).

    I haven’t done any network programming (yet), but to get around the state machine problem you might want to try to “automate” it. It’s not too complicated to implement; contact me if you want the details. It will at least make your code (and debugging) a bit more easier than the if/then/else & switch statements.

  2. rince says:

    yeah that client server architecture thing seems like what is required nowdays. i vaguely understand the concept, but cant really picture it being applied to all situations. for example what about user interface? if a user presses a button on some screen is there going to be a delay until he sees the button graphically being pressed or in some cases the state logic will decide that the button should not be pressed at all? i assume that in cases like that, code will have to be duplicated on both client and server sides for immediate decisions.

  3. Davide Pasca says:

    Ragin, I’ll be glad to contact you personally, but no advances can be given here publically ? 8)

    I think I read something on state machines on Game Prog Grems. I can’t find it on the #2 that I have here at home. Perhaps was on the #1 that I left at work ? Maybe I’m just mistaken.

    Rince: I’m not sure how far the client/server thing is good to push. I’m currently trying to avoid it in some cases.
    Actually I have two servers. One is the session server. It runs on the machine of the player that started it. It handles people joining and leaving, also handles the queue of players. For these things I use the server & client messaging, even locally (sending messages to 127.0.0.1 (loopback) and getting them back, on the same machine).
    The second server however, serves the actual real-time game data (field situation, controller input), and runs on the player/s machine (1 or 2 for VS games). This server, serves the current game data (game field, controller input). In this case, sending and receiving local network data, could possibly lead to a lag of one frame.. (move left now, see the reaction in the next frame) which is not acceptable in my case.
    This is where I decided to make an exception and skip the local server & client architecture.

    ehhh !

  4. ragin' lion says:

    Hey Kaz, I could write it publically, but it’s a lot easier to just talk about it that write it down. I must be getting lazy with age … :(

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>