Messages

Rocco: You are able to have at least 8 sprites on the screen, so smart people used the spare ones for detailing, that is what seems to be going on there (Last Ninja is a relatively graphically advanced game). Sprites can be set to single pixels or double wide pixels regardless of the background display mode.

I don't think anyone cares how many GB sprites you use, Akatosh.

C64 has various graphic modes, but most games use pixels that are double wide, so the screen is 160x200 instead of 320x200, stretched horizontally. The reason is that you can only use 2 colours in each 8x8 area in full resolution mode, whereas you can use 4 in half resolution mode, which makes things a lot easier. Example, notice there is never a single dot of colour in the background, always two next to each other. You can mix and match high res sprites and double wide sprites if you like, but it looks a bit odd. AGI on PC also used this system to save memory.

You don't need to be completely strict, people rarely are in retro theme games, because it's a bit tedious making graphics for the actual system restrictions, but the stretched pixels are a simple signature of C64 graphics.

I don't think it's mentioned in the manual but yeah, a lot of people use block comments, it's something people would naturally try if they come from other languages. I expect you picked it up from modules or forum examples, TheMagician.

The important difference in SSH's example is that the function is declared with the return type "String" rather than "function". Using "function" is the same as using return type "int".

Monkey is fine, but I think having a name that doesn't mean anything in particular is best. That way you don't need to have seperate email addresses for when you communicate with real people. Easiest thing is to base it off your real name. Trying to pick a name that sounds brooding and cool for yourself will only make it less cool.

It's too late to go changing things now, but I wish my friends had chosen a nickname that wasn't a relatively common noun and adjective.

Are you including me in the calculations? I will pay CJ by the time Mittens comes, which makes it 40/6*5 = 33 eur, right?
Also there's still time for us to invite people to come. Then again it's nice to share rooms with fewer snoring AGSers and have less congested bathrooms so I don't mind paying the extra personally.

Well it's not much of a client... it doesn't even respond to PINGs, but here

Code: ags

// room script file

Socket* irc;
String chan;
function room_AfterFadeIn()
{
  chan = "#ags";
  irc = Socket.Create();
  irc.Open("irc.adventuregamestudio.co.uk", 6667);
  irc.Write("NICK ags_sock
");
  irc.Write("USER socky socky socky :ags_sock puppet
");
  irc.Flush();
  Wait(80);
  irc.Write("JOIN ");
  irc.Write(chan); irc.Write("
");
  irc.Flush();
}


function room_RepExec()
{
  if(irc != null) irc.Poll();
 if(irc!=null && irc.ToRead()) {
  String line = irc.Read();
  if(line.Contains("PRIVMSG")==-1) return;
  int msgstrt = line.Contains(" :")+2;
  int nameEnd = line.Contains("!");
  if(msgstrt == -1 || nameEnd == -1) return;
  String prefix = line.Substring(1, nameEnd);
  prefix = prefix.Append(": ");
  
  cEgo.Say(prefix.Append(line.Substring(msgstrt, line.Length-msgstrt-2)));
 }
}
function hHotspot1_Interact()
{
  if(irc) {
    String msg = Game.InputBox("What do you want to say?");
    irc.Write("PRIVMSG ");
    irc.Write(chan);
    irc.Write(" :");
    irc.Write(msg);
    irc.Write("
");
    irc.Flush();
    }
}

Yeah SocketServer doesn't work in that release. I have no idea about proxies... outside of having to use a HTTP one at school. If someone explains how that all works I'll be happy to implement it.

I don't know why it won't work for you dualnames but I'll look into it.

This will vary completely from person to person depending on their interests and skills, and style of game. When I'm doing AGS stuff I spend easily 80% of time on art, because it's what interests me, and 0 time on music because I have no ability for it. Designs tend to formulate on their own over time. The amount of hours sat down focussed on puzzles are a tiny fraction of development time, maybe 1-2%. Writing is another thing entirely and takes me quite a long time.

Basically you can't know how long you should spend on different areas. Just spend as long as you need and try to focus on the aspects you're good at.

It hasn't been updated for approaching three years so it won't run many new games. I'm not sure if it is officially discontinued or not.

Bit late, that was the first thing I tested it with.
People look even stupider coming out of Roger.

Just pointing out that even though this was moved to the module/plugin archive, it's not ready for use, but I will sort out the missing features as and release it as it is if nobody complains.

One thing I'd like to sort out is the String reading/writing NULLs problem. I could add an option to escape/unescape null characters I suppose.

That sounds quite odd, the plugin doesn't interact with any other codecs. I can't replicate it myself.

Well ok, here's a start. Not tested or for release or anything. But whoever wants TCP/IP can play with it and suggest interface improvements.

The interface doesn't echo real tcp/ip sockets exactly, it's simplified for AGS use.
struct Socket {
    bool Open(const string url, int port); // returns true on success
    void Close();
    bool Connected();

    void Write(const string data); // write data into the socket
    void WriteInt(int value);
    void WriteByte(int c); // write a single byte value between 0 and 255
    void WriteFloat(float f);
    int ToWrite(); // amount in write buffer
    int Flush(); // sends buffered write data and returns how much was written

    int ToRead(); // amount in read buffer
    String Read(int limit = -1); // read a string out of the buffer
    int ReadInt(); // read an int, will return 0 if there's not enough data so remember to check ToRead
    float ReadFloat();
    int ReadByte(); // read a single byte value between 0 and 255
    int Poll(); // read incoming data into the read buffer

    static Socket* Create();
};

struct SocketServer {
    SocketServer* Create();
    bool Listen(int port); // begin listening for connections on a port
    void Close(); // disconnects all clients and stops listening
    void Update(); // queues new connections and polls/flushes all clients
    Socket* GetNewSocket(); // returns an incoming connection or NULL if none pending
    int GetNumSockets();
    Socket* GetSocket(int id); // access to the client sockets so you can interate over them
};

I think this set up should be fine for most purposes but do suggest improvements. One issue with String reading is that you can't recieve NULL bytes, AGS won't allow them to be put in the string. This is fine for some protocols but not others. You would have to use ReadInt/Byte to get 0 characters properly. I would leave it to module authors to write robust HTTP libraries or easy game value synchronisation etc.

Some of the functions should become variables, like .connected or .toRead, but that's just tidying up. Poll and Flush are automatically called once per frame, but they are provided so that people can block on reads if they want, or reduce lag.

Here's an example of Roger querying google (put it in a default game)

Code: ags

function room_AfterFadeIn() {
    Socket* cs = Socket.Create();
    if(cs.Open("www.google.co.uk", 80)) {
        cEgo.Say("Opened a socket, sending request.");
        cs.Write("GET / HTTP/1.1\r\n");
        cs.Write("Host: www.google.co.uk\r\n");
        cs.Write("Connection: close\r\n");
        cs.Write("Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1\r\n");
        cs.Write("Accept-Language: en-GB,en;q=0.9\r\n");
        cs.Write("Accept-Charset: iso-8859-1, utf-8, *;q=0.1\r\n");
        cs.Write("User-Agent: AGS (Windows NT 5.1; U; en)\r\n\r\n");

        cs.Flush();
    } else {
        cEgo.Say("Failed to connect");
        return;
    }

    while(!cs.Poll()) {
        cEgo.Say("Waiting for a response...");
    }
    cEgo.Say("Recieved %i bytes.", cs.ToRead());
    String response = cs.Read();
    int bodyStart = response.Contains("\r\n\r\n") + 4;
    cEgo.Say(response.Substring(bodyStart, 255));
}

"I believe, for what i read in the AGS changes log, that AGS become from a Aplication to create AdvGames into a Medium-level progaming language oriented to AdvGames, but not limited to it.
...
Probably not the right place to express an opinion, but seconded.
"

I don't see how you could get this impression from the recent changelogs, unless you hadn't realised there was a script language before, because it's virtually the same now as it has been for years. All recent changes are based around AGS's main purpose, of being a focussed traditional adventure game creator. If it was about being a general purpose game development tool you would see the script language being beefed up with general programming features, and movements away from character system, built in pathfinding, walkable areas, hotspots, etc.

AGS is not, and hopefully never will be like Game Maker, pygame etc. It would be pointless. That's not to say I wouldn't value improvements that make AGS more versatile, that benefits everyone, but not if it means forgetting why AGS exists.

AGS's focus has changed very little since the interaction editor was lost. It's true that you are required to write script commands instead of filling out interaction editor dialogs that do the exact same script command tasks, but the logic is the same. You do not need to spend much time thinking about script in the new AGS if all you use are the options that were in the interaction editor.

Additionally, the script language hasn't changed, nor the focus on adventure games. The engine is near identical to before and no more or less suited to non adventure games. Only the editor has changed. A form of interaction editor may reappear some day, and if it does it will be much more user friendly than the old one.

Nobody should think of AGS as another tool for general game development. All the engine features are highly geared towards point and click adventure games, that is why it works so well for that task, and relatively poorly for platformers/rpgs/etc.

Now about TCP/IP... I don't mind volunteering a bit of effort to make a working plugin, I am skeptical about if it would get used or not, but multiplayer experiments would be fun... I'll post back later if I get round to it.

Calculators and phones are rather low res, although they would at least do the LCD greens. Can't think of a system that'd fit that perfectly but perhaps you could adapt it to a vector machine like the Vectrex, or similar early arcade systems. That way you have high res line art while still emulating an 8 bit system. With a green overlay your thing should work.

It's a custom AGS script language, which is closely modelled on C, but removing most features that could confuse people and get them into trouble. People do use the term C-style for any of the millions of custom curly brace languages that are out there, but I think just mentioning that you have scripted games will be enough, there are many languages but few standards in this area, unfortunately.

Well that's the wrong way for driving to the place. Seems like people are meant to drive to Vireux-Wallerand and take the path along the river, for 3km. Here's more evidence from MS's map thing. You can clearly see the house, gites, chapel, tennis court, and WMD factories.

http://www.chateaulerisdoux.fr/route.htm says cross the bridge from Vireux-Molhain and after the town hall, the first right towards the Fracotte pool, up to the river, then left along the tow path for 3km.

First one does work for me. Once the other buildings are detailed like the nearest and there is some street detail it'll look good, the fisheye style is fine. Feels like the city goes on forever, and actually the empty streets make it kind of eerie, could be a good thing if you are going for that.

The second looks more odd to me because the bands of light coming out of the sun radially suggest that it's a lamp hovering over the horizon. In a landscape, when the colour of the ground changes with distance it's generally due to fogging, which means colours get less vibrant, whereas you have the opposite. I like the cutout style of the tree, if you want it to be a more interesting focal point you could add some more details and volume on it, trying to maintain the original feel. When you have strong bands of colour in an image they can be broken up in a way that suggests the texture, could work on the ground. Anyway here are some of those ideas in practice.