Messages

It is the same one that I released on itch.io over a year ago! I simply forgot to publish it here for some reason 
When I found out my book in Thimbleweed Park I thought "I should update the thread on AGS forums!", except... There was no thread 

[some additional art]

I thought I published this already on these forums, but turns out I didn't!



Far in the North, where nighttime can last for months, a researcher is left alone with his boredom and an important research close to completion. Then, a power shortage gets in the middle.

The game is available for PC, Mac and Linux!

Download for free (or pay-what-you-want) on itch.io

OR

Download on GameJolt
Download on IndieExpo
Download on IndieGameStand

Game Features

• Short, yet authentic point and click fun!
• Chunky pixel-art, just because!
• Debatable science!
• Pseudo-random soundtrack!
• Some John Conway's Game of Life inspired graphics!

Additional Info

I originally developed this game for December 2014 MAGS, then ported it a year later to Unity and re-released it with my brother helping me on optimizing the original graphics and creating some additional art.

The original is still available, of course, so you can compare versions if you want

Trivia

When Thimbleweed Park was looking for books to fill its huge library shelves, I wrote a short novelization of the game. Seeing it in the game made my little nerdy heart beat with joy

I second what CaptainD said: very easy to use! I find the admin dashboard to be well structured and with interesting Analytics.

As far as I know, itch.io is a much visited website, but I don't really know how much does a successful game earn.

The whole selling process is not hard to grasp and it's well described here.
The only real thing you may spend a few minutes more reading is probably the part about VAT, as it may be different depending from which country you live in.

I did earn a few bucks thanks to donations (free\pay-what-you-want) I did not really put anything there paid-only, yet.

Apologies for the lack of economist lingo but I'm not an expert at all 

Please do Here is the whole thing in a comfy zip format

I called it rAGS because it made sense Of course nothing is final, as the background is one huge placeholder pasted from the original game.
It may be easy to get confused by which are actual objects and which are just part of the background, but if you look at them closely you find out that actual objects are uncompressed and better defined.

Also, I apologize in advance for the messy, spaghetti, useless or incomprehensible code you may find! Let me know if I you need anything!

You say it made all other coordinates go crazy. Aside from that, did it fix the problem? Were you able to achieve precise positioning with high-resolution coordinates?

You're right. I didn't really try.

I disabled all the scripts that involved object placement and manually placed an object on the screen. Displaying the Object.X, its "center" (object[a].X+(Game.SpriteWidth[object[a].Graphic]/2) and player.DestinationX I can tell it seems to work as I originally intended.

Now I wonder more about this setting, though. Is it best to enable it before doing anything else in the game, maybe?
I'm not sure if there is any specific "conversion" I should make in terms of XY coordinates in my scripts in order to make them work properly. Most rely on variables such as player.X+arbitrary_value_I_choose.

Is there anything that I can read about it?

Thanks for the heads up, Gurok!

We're currently finishing up RC1. Hope the testers don't find too many bugs!!

So, how are we doing?

Jokes aside, I was not sure what to think about splitting the game in two parts, but after my second round of testing - the first one being at least three years ago - I changed my mind.
So much time has passed since the first testing and it was pretty easy for me to notice how the game's scope grew since. Plenty of stuff has been added and I could see how some design ideas, that simply weren't there before, helped this stuff into the game.

Also, as I probably already said here somewhere, I learned about the series Red Dwarf while testing this and SMEG if it was worth it

Many thanks to Katschey for the awesome header image!

And great work by Katschey, as always!

[between]

Of course the easiest workaround for me is to simply check whether the player walks in a position that is between the object origin and its center.
This puts a patch on the problem and basically solves it, but I don't know... Is this an AGS bug to report, anyway?

Thanks everybody for your help, up to now

[2 pixels]

Wait, what is the basis for the Player Destination X value in the screenshot?

The displayed value is the one that the game sends when I click on the Object. It should get it from the player.Walk() function within the oBottle_Interact() one (which is the one I showed in the first post), but it always get it a pixel off.

But still, it works whenever I click somewhere on the screen. I noticed that wherever I click, the result is alwas an even number.

And what happens if you place the object at an even X coordinate?

I tried something simple (which may be wrong, of course):

Code: ags

function oBottle_Interact()
{
    int p = object[0].X+(Game.SpriteWidth[object[0].Graphic]/2);
    
    if (p % 2 != 0)
    {
        p++;
    }
    
    player.Walk(p, player.y, eBlock, eAnywhere);
}

And, instead of adding 1, it adds 2 pixels :\

BTW, what is game resolution?

As I'm currently just doing tests, it's a custom and temporary 608x304. Is it a problem?

Thankfully I did display them! It's the reason I found out what the problem was in the first place
Player X is a single pixel away from the Obiect[0] Mid position.
I also tried using the Object[0] X instead, but the results are the same.

This time, though, I also added the DestinationX and found out that when I click on the object it doesn't really send the character to the position I set up in the Character.Walk() function.
No matter where I click on the object, it always send it to a pixel away from the destination I'd like to send it.

It almost feels like it doesn't like odd numbers

EDIT: btw, do you take image alignment into consideration? IIRC character's frames are centered at its position, which may make character look a bit "offset" if sprites are not fully symmetric.

I had the feeling that characters' frames and sprites did not have the same "origin" point. If I understood correctly, characters have it in the center while objects at their left (that's why I'm calculating the character's destination to be the object.X + half of its sprite's length). Still, I'm not sure I have the logic needed to deal with the problem

Try checking General Settings->Use low-resolution co-ordinates in script-> false

It was set to false already. I tried switching it to true but, as the disclaimer would say, it made all other coordinates go crazy

If you change the character speed to 1 pixel per frame, does it still miss the destination?

I'm tracking the Character.X on screen and apparently it always walks 2 pixels at a time. Things I tried:

• I tried coding the WalkSpeed to (1, 1) in the game_start() function
• I tried setting the speed manually in the Character's Properties
• I tried setting the AnimationDelay property to 1
• I tried setting the MovementLinkedToAnimation property to false

...Or is there another way to set it properly?

Try to use .Walk instead of .WalkStraight, and also try the eAnywhere option.

I tried that before but tried it again now. The same result, unfortunately.
I also tried making it an eBlock, instead. But no.

I know that the walkable area is unnecessarily tall, but still... I'm not sure. The object appears below the player's walkable area (as it should be).

And, yes... I'm reverse-engineering Rags To Riches from the C64

[few pixels off]

As per subject, I'm trying to make a character reach a very specific destination, before performing an animation.
This is the line I've been using:

Code: ags

player.WalkStraight(object[0].X+(Game.SpriteWidth[object[0].Graphic]/2), player.y, eNoBlock);

The result is that most of the time the character gets a few pixels off the target. For instance: while that specific x is 733, the Character reaches 732 or 731.

I tried using both Character.Walk() and Character.WalkStraight(), also I originally had just object[0].X for the x parameter of the function. The results are the same.
Is this something strictly related to the way those function work? Is it because of the walking animation, perhaps?

It is probably worth mentioning that the object[0] is placed everytime right outside the players' Viewport (whether the player moves to the right or to the left) with the following code:

Code: ags

function RandomItem()
{
    // Choose which item to place
    int r = Random(2);
	
    // Check if any item is already in the viewport
    // if NOT, put one
    if (!isItemInViewport())
    {
        // Make all the items different than r invisible
        for (int i = 0; i <= 2; i++)
        {
            if (i != r)
	    {
                object[i].Transparency = 100;
	    }
        }

	// Check which direction is the player taking
	if (player.DestinationX < player.x) // LEFT
	{
	    object[r].SetPosition(playerViewportEdgeLeft-Game.SpriteWidth[object[r].Graphic], 278); // Then move it right outside the viewport
	    object[r].Transparency = 0;
	}
	else if (player.DestinationX > player.x) // RIGHT
	{
	    object[r].SetPosition(playerViewportEdgeRight+Game.SpriteWidth[object[r].Graphic], 278);
	    object[r].Transparency = 0;
	}
    }
}

Thanks in advance, everybody

[this.width/2]

I don't know what you're doing with "this.width/2"

The reason I was using the this.width/2 was because it kept the cursor from hovering the "popup" GUI (which caused a blinking glitch). But I think a could manually subtract another integer value at my leisure.
I'm not sure whether I tried that expression in a previous attempt but still, thanks It seems to be working! I'll run just a few tests to see if I'm right, and if I am I'll mark this solved.

In my RPG I use a GUI (gEmote) for emotes above the player character, in some situations the GUI might try to be drawn off-screen. Perhaps you could take something from it.

If not for this purpose, this can actually come really handy later on, for another thing I'm trying!
Thanks a lot to all three of you

[this]

The this in the Description.asc script should ultimately represent the GUI itself.

The function declaration - with the double colon, which a quick research defines me as a "scope resolution operator" - is, I think, a little to advanced for me to understand properly, but as far as the code goes, Descriptions is a struct defined in the script header. My guess is that the scope resolution operator helps to avoid overwriting "accidents" between different "instances" of Description but, again, I'm not really sure about what I'm saying

To be a tester on this game was really fun and interesting, I remember having the feeling of being part of a great project, not just in terms of scope but also in terms of quality - as all of you can now see
I was very happy when Knoodn asked me if I wanted to be a tester, after I did the same for his great game UNGA Needs MUMBA. I felt like I got a promotion!

As others said, hats off to all the devs and I wish you all the best in whatever project (gamedev related or not) you decide to dedicate yourselves to.

[mostly]

I've been playing around with the Description module by SSH in order to achieve this:



In other words: when the cursor reaches the far right end of the screen, invert the position of the Hotspot Name GUI, placing it to the left of the cursor, instead of the right.

To do this I tweaked a specific line in the original module's script, from this:

Code: AGS

// Original code
protected function Descriptions::Update_Position(int font, int width)
{
    // ...

    this.x = mouse.x + this.OffsetX;

    if ((this.x + this.width) > this.MaxX)
    {
	this.x = this.MaxX - this.width;
    }

    // ...
}

To this:

Code: AGS

// My code
protected function Descriptions::Update_Position(int font, int width)
{
    // ...

    this.x = mouse.x + this.OffsetX;

    if ((this.x + this.width) > this.MaxX)
    {
        this.x = mouse.x - this.width - ((this.width/2) - this.OffsetX);
    }
    
    // ...
}

This mostly works but, as soon as I reach the top-right end of the screen (whether it's in windowed or fullscreen mode), the game crashes giving me the error: GUI.X co-ordinates specified are out of range.
I'm pretty sure I'm missing something in the messy "logic" I tried to find out. Maybe it's just the order of the operands in the expression, but I'm not really sure about that.

Does any of you have any advice on how to fix this?
Thanks in advance

[noloopcheck]

You're right Edmundito: This is very close to the thing I want to achieve (I may have slightly changed my idea on how I want this to look like, in the meantime)!

Your code is very easy to read and indeed interesting. Actually I think I have never read a noloopcheck function before, I read the documentation about it but wanted to know: why did you use it? Is it for optimization purposes? I'm also curious about the fact that when you import it in the script header you can omit the noloopcheck from the import.

On my own I have been able to create a GUI that appears and animates at the given position, but I'm not quite there yet, as I need to solve the text wrapping issue whenever the speaking character is too close to the viewport's borders. I'm not sure whether it's my lack of math\trigonometry knowledge or something else

Thanks a lot!

[how much better]

Hugely interesting read, Ben, thanks a lot!

I think I saw your style "grow" over time in such a way that, yeah, I could see how better was getting every time, but I didn't pay close attention to how much better it got.
Seeing the different examples side by side really put them under the spotlight.

Anyway, reading about the Bazaar scene in Shardlight, I just wanted to express my extremely cheap two cents. I may actually have missed the point

Spoiler

I can't really put my finger on it, but that specific scene didn't really give me the feeling that I was walking in a big world (no matter how destroyed and ruined).

Walking in that scene gave me more the idea that people chose that specific spot just because it was "the right spot" for a bazaar to take place. Like: "it's not as ruined as everything else and it is big enough, let's stick around here".

I couldn't really "see" (in my mind) much else behind those buildings in the foreground. Or, at least, not as densely populated. I don't think it's because of the art style or the perspective. Maybe it's the composition? I'm pretty ignorant about it

Of course, I'm not saying it's a bad thing After all you said "big world", not "crowded"!

[close]

That said I'm genuinely curious about what your new approach can produce, when "drifting off from reality" again with your own titles!

THANK YOU!

These are very nice words, Kumpel, and I can't thank you enough!
When we were working on the last bits of the game, CaptainD said the same thing about playing it at least once in a while and I would agree with him.

I guess I can say that we really have enjoyed working on the game