V0.5 Preparation thread

V0.5 Preparation thread

Postby Edward_Lii » 07 Aug 2018, 21:03

Hello all,

Long time no see. ;) Years ago development slowed down and I kind of just stopped working on it. From time to time I did consider picking it up again, but never got around to it.
So I was positively surprised to see the project under active development again after all this time and I hope to contribute my part again (I am listed as "active developer" in the AUTHORS file after all :p )

The goal of this thread is to gather the points still needed for a V0.5 release of Me and My Shadow. If you haven't already, be sure to read acme_pjz's latest post detailing the recent and not so recent changes:
https://acmepjz.github.io/meandmyshadow/2018/status-of-0-5-development-version.html

In short, there are plenty of new features and nice technical improvements:
  • Switch to SDL2 (thanks to oyvindln)
  • Achievements and statistics (thanks to acme_pjz)
  • Scripting support
  • Several improvements/additions to the blocks: pushable blocks, sizing of blocks and scenery (blocks)
  • Undo/redo in the editor (thanks to squarecross)

So, what is left to do? That's what we need to figure out in this thread!
The focus should be to ensure the above new features are stable and well (play) tested.
Also, since this is a game, we should not forget to provide new content compared to V0.4.1, this includes:
  • Updating the 'tutorial' levelpack to include the new features
  • Update the 'default' levelpack with some more levels
  • Introduce a new levelpack/additional levels(?)
  • (Nice to have) Update theme to accommodate for sizeable blocks
  • (Nice to have) Additional music tracks, don't get me wrong, I love the music, but it's omnipresent in all menus/levels/levelpacks.

At one point a string freeze should be introduced to allow the translations to be updated. Given the large interval since the last release, I don't expect all of the original contributors to be available, but we can at least try and contact them.
This will likely mean that we might end up with fewer supported languages than before or have a few translations that only cover part of the strings.

Any feedback or suggestion is welcome! :)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 774
Joined: 20 Dec 2010, 16:46

Re: V0.5 Preparation thread

Postby charlie » 08 Aug 2018, 12:33

I would suggest that a teleporter covered with a pushable block should not work. That would make for some interest level designs (both where you need to push blocks off a teleporter or cover a teleporter that blocks a path).
Free Gamer - it's the dogz
Vexi - web UI platform
User avatar
charlie
Global Moderator
 
Posts: 2025
Joined: 02 Dec 2009, 11:56
Location: Manchester, UK

Re: V0.5 Preparation thread

Postby GunChleoc » 08 Aug 2018, 18:00

Glad to see this project is moving again. I'm still keeping an eye on it for translations :)
User avatar
GunChleoc
 
Posts: 300
Joined: 20 Sep 2012, 22:45

Re: V0.5 Preparation thread

Postby acme_pjz » 09 Aug 2018, 05:52

Here are my (incomplete) TODO list for V0.5.

  • I need to fix a couple of things before a V0.5 beta release. A few days are enough. Already fixed :cool:
  • Clarify the author/description/website/screenshot/license for the addons. Edward_Lii, do you have ways to contact the authors of them?
  • Fix of OSX build and packaging. I'd like somebody help me to make the OSX nightly build compile/packaging script run on Travis CI.
  • To be added...

Here are a list of incompatibilities between V0.5 and older version:

  • The input configuration file is incompatible with older version, vice versa. You may need to reconfigure keys.
  • The "button" state of Button block in the theme file is incompatible with older version. (All builtin and addon themes are fixed.) If you have designed other themes, you may need to fix them.
  • Various game logic changes which may break older replay. I try to hard to keep game logic compatible, but some of them are inevitable. If you find any incompatibilities, please tell me and I'll see if it can be fixed.
  • To be added...

------

charlie {l Wrote}:I would suggest that a teleporter covered with a pushable block should not work. That would make for some interest level designs (both where you need to push blocks off a teleporter or cover a teleporter that blocks a path).


This sounds reasonable. What is your opinion, Edward_Lii? I can implement it if the decision is made.

GunChleoc {l Wrote}:Glad to see this project is moving again. I'm still keeping an eye on it for translations :)


As for the translation, I try the Transfiex https://www.transifex.com/acmepjz/meandmyshadow/ but later on I found that there are some quirks on it, e.g. translation pushing/pulling bugs :| .

So meanwhile you can also use the classical translation workflow described in the wiki.
Last edited by acme_pjz on 09 Aug 2018, 10:20, edited 1 time in total.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 514
Joined: 10 Dec 2009, 15:32
Location: Biejing, China

Re: V0.5 Preparation thread

Postby eugeneloza » 09 Aug 2018, 06:23

At one point a string freeze should be introduced to allow the translations to be updated.

When you have final version of English, ping me for Russian and Ukrainian :)
As far as I've understood according http://meandmyshadow.sourceforge.net/wi ... ranslating you just need a pull request with corresponding .po files, right?
User avatar
eugeneloza
 
Posts: 485
Joined: 22 Aug 2014, 12:15
Location: Ukraine

Re: V0.5 Preparation thread

Postby Edward_Lii » 09 Aug 2018, 09:40

acme_pjz {l Wrote}:Clarify the author/description/website/screenshot/license for the addons. Edward_Lii, do you have ways to contact the authors of them?

I'll try and see if I can contact them. Though, what should we do in case we don't know under which license an addon falls?

acme_pjz {l Wrote}:The input configuration file is incompatible with older version, vice versa. You may need to reconfigure keys.

I was thinking we should detect this somehow and perhaps reset the keybindings, as there might be people who still have an old configuration file.
Perhaps store a version in the config file, so we know when we load an old config and make the appropriate changes, though then someone might not be able to load up V0.4.1 (or older) afterwards.
We could also have a config file per version, and on startup if the file isn't there, check for the config file for the previous version and migrate the relevant settings (everything except the keybindings in this case).

acme_pjz {l Wrote}:This sounds reasonable. What is your opinion, Edward_Lii? I can implement it if the decision is made.

I think it's a really good idea and would indeed allow for some interesting puzzles, thanks for the suggestion charlie!
Some things to think about when implementing this:
  • We can play the same 'error' sound for when there is no existing destination, but how would the player know that the destination is temporarily blocked instead of not existing? (Ideally a level wouldn't have "broken" teleporters without destination, but they can)
  • In case the teleporter "auto" teleports, will the teleport commence once the destination becomes valid, or should the player/shadow move off and on the teleporter again (the latter is probably easier to implement)

Some other points I thought about while playing the game again, which mainly have to do with gameplay:
  • A player can't see from the appearance of the teleporter whether it will be a manual one or an automatic one. Maybe we can create a different appearance for them.
  • Both the switch and the button can exhibit different behaviour (toggle, on or off), but again, there is no way for the player to visually see this. The tutorial does point it out, but when you think about it, it's basically saying "switches might not do what you expect, good luck" :p
    Not sure how we should go about this, but at the very least the button and switch should become inoperable after activation if they are set to the 'on' or 'off' mode.
  • As the switch is also a block, the player can activate it as soon as it overlaps with the 40x40px block, but the player can also overlap multiple switch blocks if they are close enough and activate them all at once. Previously I didn't really mind that much, but after playing the level "Picture creator" I realized it would be nice to visually see which (if any) switches I would activate by pressing the interact key.
    Additionally we might want to make it so that you only ever activate one switch, for example the one you overlap/cover the most?

Other than that I'm still looking into some bugs regarding pushable blocks stacked on top of each other on top of moving blocks. And while playing I noticed quite a few times being "squashed" without actually being "squashed", not sure what caused that, but will try and get to the bottom of that.

GunChleoc {l Wrote}:Glad to see this project is moving again. I'm still keeping an eye on it for translations :)

eugeneloza {l Wrote}:When you have final version of English, ping me for Russian and Ukrainian :)
As far as I've understood according http://meandmyshadow.sourceforge.net/wi ... ranslating you just need a pull request with corresponding .po files, right?

:D Really great to hear this, thanks in advance. I'll be sure to notify you when the string freeze is in effect. ;)
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 774
Joined: 20 Dec 2010, 16:46

Re: V0.5 Preparation thread

Postby acme_pjz » 09 Aug 2018, 10:44

Edward_Lii {l Wrote}:I'll try and see if I can contact them. Though, what should we do in case we don't know under which license an addon falls?


I don't know... do we need to remove them? :( I don't like that.

Here is the list of addons with license unclear:


----------------

I prefer this approach:

Edward_Lii {l Wrote}:We could also have a config file per version, and on startup if the file isn't there, check for the config file for the previous version and migrate the relevant settings (everything except the keybindings in this case).


because without SDL1.2 we can't deduce the actual key from the number (unless we copy some code from SDL1.2 header file :think: and I don't like to do that since it pollutes the code)

[EDIT] implemented in b450e27 :)

.....

Edward_Lii {l Wrote}:Additionally we might want to make it so that you only ever activate one switch, for example the one you overlap/cover the most?


I think activate multiple switches at once is OK. Personally I don't like the approach that only activates the nearest switch. Plus, it certainly will break old replays. :think:

Edward_Lii {l Wrote}: And while playing I noticed quite a few times being "squashed" without actually being "squashed", not sure what caused that, but will try and get to the bottom of that.


Yes, the half-baked collision detection code (written in 2012--2013 ?) has a lot of nasty bugs. I managed to fix most of them (see git rev 5269929, 1234a8f, 4a0fbf4, ... ) but there seems still bugs, for example in level 19 "subway surf" in Akos level pack you'll be squashed when you standing on a block moving up while another block moving up at a higher speed. :(

[EDIT] I think I fixed it in b8e6e7a :)
Last edited by acme_pjz on 13 Aug 2018, 19:05, edited 6 times in total.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 514
Joined: 10 Dec 2009, 15:32
Location: Biejing, China

Re: V0.5 Preparation thread

Postby eugeneloza » 09 Aug 2018, 14:27

I'll be sure to notify you when the string freeze is in effect.

Don't get me wrong. I have no idea what "string freeze" is :) I just need final version of English text to start :)
(UPD) looked up in the Internet, yep. That's what I'm waiting for :)
User avatar
eugeneloza
 
Posts: 485
Joined: 22 Aug 2014, 12:15
Location: Ukraine

Re: V0.5 Preparation thread

Postby GunChleoc » 10 Aug 2018, 17:54

acme_pjz {l Wrote}:
GunChleoc {l Wrote}:Glad to see this project is moving again. I'm still keeping an eye on it for translations :)


As for the translation, I try the Transfiex https://www.transifex.com/acmepjz/meandmyshadow/ but later on I found that there are some quirks on it, e.g. translation pushing/pulling bugs :| .

So meanwhile you can also use the classical translation workflow described in the wiki.

Which are the bugs that you are referring to? I have used Transifex for years now and it's working well for me, so I'd be interested to know. They are also really good about responding to inquiries.

A problem for translators is that you can't watch an individual file on SourceForge, so there are no notifications for changes available. Manually keeping up with the number of projects that I maintain has become impossible. I do read this forum regularly though.
User avatar
GunChleoc
 
Posts: 300
Joined: 20 Sep 2012, 22:45

Re: V0.5 Preparation thread

Postby acme_pjz » 11 Aug 2018, 03:41

GunChleoc {l Wrote}:
acme_pjz {l Wrote}:
GunChleoc {l Wrote}:Glad to see this project is moving again. I'm still keeping an eye on it for translations :)


As for the translation, I try the Transfiex https://www.transifex.com/acmepjz/meandmyshadow/ but later on I found that there are some quirks on it, e.g. translation pushing/pulling bugs :| .

So meanwhile you can also use the classical translation workflow described in the wiki.

Which are the bugs that you are referring to? I have used Transifex for years now and it's working well for me, so I'd be interested to know. They are also really good about responding to inquiries.

A problem for translators is that you can't watch an individual file on SourceForge, so there are no notifications for changes available. Manually keeping up with the number of projects that I maintain has become impossible. I do read this forum regularly though.


Well, last week I translated locally on my computer using Poedit. When I want to use "tx push -t -l zh_CN" nothing get uploaded :| I have to use "--force" flag :( Maybe there are some bugs on comparing file modification time.

[EDIT] Also, it looks like that Transfiex will delete translations whose original text was removed from .pot files. This causes Translation Memory get lost. The local editor, for example Poedit, simply comments out the removed translations, which can still be used in Translation Memory.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 514
Joined: 10 Dec 2009, 15:32
Location: Biejing, China

Re: V0.5 Preparation thread

Postby acme_pjz » 11 Aug 2018, 09:13

@Edward_Lii, my plan is release V0.5 Beta version next weekend, at around Aug. 19. There are no code-wise tasks left in my checklist. Is this time period too short for you to find bugs?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 514
Joined: 10 Dec 2009, 15:32
Location: Biejing, China

Re: V0.5 Preparation thread

Postby Edward_Lii » 11 Aug 2018, 15:31

acme_pjz {l Wrote}:Yes, the half-baked collision detection code (written in 2012--2013 ?) has a lot of nasty bugs. I managed to fix most of them (see git rev 5269929, 1234a8f, 4a0fbf4, ... ) but there seems still bugs, for example in level 19 "subway surf" in Akos level pack you'll be squashed when you standing on a block moving up while another block moving up at a higher speed. :(

Yeah, the collision system is indeed not great and it seems that a fix/tweak generally has some undesired side-effect. The current state of master seems okay, apart from one thing: pushable blocks :|
I tried simplifying the collision system as a POC, using the following notions:
  • All blocks except pushables can be updated without problem (as they don't influence each other)
  • All pushable blocks will update after all other blocks have moved
  • Rather than combining "base velocities" and movement "velocity", change it to two phases: "forced movement" and "voluntary movement"
  • Rather than pushing the player, his shadow or pushable blocks iteratively, determine the "forces" and push them out of the blocks (makes this step order independent)
The "forced movement" is the movement coming from the delta of the block the player or pushable block is standing on. After applying this movement, a check is done to see if there are any overlaps with blocks, if so a push "force" in each direction is determined to push the player or pushable block out of it. The current code for that can behave differently depending on the order of the blocks, the POC approach doesn't.

If the player or pushable block no longer collides after "forced movement", they can start "voluntary movement" (which does include gravity). This now becomes a lot simpler as it's simply seeing how many of the desired pixels it can move before it hits something. The standing on check is still a bit complex, to handle the 50% on conveyor belt and moving blocks scooping the player/pushable block up.

Even with those changes, quite a few problems remained, and they all had to do with the order in which the pushable blocks were moved. I tried to sort them using a heuristic that ensured any stack of pushables would be updated from bottom to top. But even that is not sufficient as not being part of a chain, does not mean you are not influenced by pushable blocks in the chain (or even will become part of the chain in that update). In the end I didn't manage to find a reliable ordering, so I opted for having the pushable blocks indicate failure and processing it in multiple rounds until stable or after X amount of rounds. The end result works, but not very nice :(

I've committed the code to a branch on my repo (wip/collision) if you want to try it out, I've also attached some testing levels I've used, which illustrate several of the problems/difficulties.
levels.zip
(1.09 KiB) Downloaded 4 times


acme_pjz {l Wrote}:I think activate multiple switches at once is OK. Personally I don't like the approach that only activates the nearest switch. Plus, it certainly will break old replays. :think:

I'm fine either way, I also think it's generally not a great idea to place switches in adjacent blocks, anyway. What should be done IMHO is give visual feedback which switches are going to be activated. Perhaps with an outline or something?
That way the player won't be surprised if they are overlapping the adjacent switch by only a pixel or two.

With regards to breaking old replays, we should indeed avoid it where we can, but almost any changes to the collision/movement/activation might break replays.
At the very least we should ensure we don't break levels with the changes we make.

I don't know... do we need to remove them? :( I don't like that.

I also wouldn't like that, on the other we can't have levels/levelpacks with unclear licenses in our repo. Most of them will still be around on the forum, so they won't be totally gone.
In any case, I have contacted everyone and awaiting there response, I have good hope that we will hear back from most of them :)

acme_pjz {l Wrote}:@Edward_Lii, my plan is release V0.5 Beta version next weekend, at around Aug. 19. There are no code-wise tasks left in my checklist. Is this time period too short for you to find bugs?

My biggest concern at this point are the pushable blocks. For the most part they work fine, but they are so sensitive to the block order, that it can be very tricky to make levels with.
If we were to release them in the state they are in, I would probably only use pushable blocks in "controlled environments", which rule out certain level ideas I had.

Other than that, I think next weekend would be nice for a beta release. Throughout the week I can find some time to do some final extensive testing. ;)
Afterwards, it would be all making levels, playtesting and translating.
From,
Edward_Lii
User avatar
Edward_Lii
MnMS Moderator
 
Posts: 774
Joined: 20 Dec 2010, 16:46

Re: V0.5 Preparation thread

Postby acme_pjz » 11 Aug 2018, 18:46

Hi Edward_Lii,

...... so the plan is use the collision system in current master branch in V0.5 Beta version and wait until we figure out a new collision system for pushable blocks? Or release a final version anyway if the time period expires (a few months)?

Edward_Lii {l Wrote}:Even with those changes, quite a few problems remained, and they all had to do with the order in which the pushable blocks were moved. I tried to sort them using a heuristic that ensured any stack of pushables would be updated from bottom to top. But even that is not sufficient as not being part of a chain, does not mean you are not influenced by pushable blocks in the chain (or even will become part of the chain in that update). In the end I didn't manage to find a reliable ordering, so I opted for having the pushable blocks indicate failure and processing it in multiple rounds until stable or after X amount of rounds. The end result works, but not very nice :(


I have an ad-hoc idea: in the collision subroutine, sort the pushable blocks by their y coordinate, if y coordinates are equal then sort by x coordinates. By this way the collision result is deterministic, although it's still depend on block order, but it doesn't depend on the order of blocks added to the level editor, only depend on the coordinates they showed on screen.

[EDIT] I have read this article https://godotengine.org/article/godot-3 ... ematicbody and the situations in the last 2 gifs are a little bit like to the case you mentioned.

Edward_Lii {l Wrote}:I've committed the code to a branch on my repo (wip/collision) if you want to try it out, I've also attached some testing levels I've used, which illustrate several of the problems/difficulties.


I'll try it in a few days, since I'm get a little busy now.

Edward_Lii {l Wrote}:I'm fine either way, I also think it's generally not a great idea to place switches in adjacent blocks, anyway. What should be done IMHO is give visual feedback which switches are going to be activated. Perhaps with an outline or something?
That way the player won't be surprised if they are overlapping the adjacent switch by only a pixel or two.


Maybe we can rephrase the tip in the corner of screen as "press DOWN key to activate <number> switches" and highlight the switches if there are at least 2 switches will be activated (we don't highlight it if there is only one) ?

Edward_Lii {l Wrote}:My biggest concern at this point are the pushable blocks. For the most part they work fine, but they are so sensitive to the block order, that it can be very tricky to make levels with.
If we were to release them in the state they are in, I would probably only use pushable blocks in "controlled environments", which rule out certain level ideas I had.


My idea is use current collision code for V0.5 beta release, and we add "Pushable blocks are experimental, there are bugs especially multiple blocks stack together case ... please don't rely on strange behavior when designing levels utilizing pushable blocks ..." to the beta release note.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 514
Joined: 10 Dec 2009, 15:32
Location: Biejing, China

Re: V0.5 Preparation thread

Postby bgalon_2000 » 11 Aug 2018, 22:58

acme_pjz {l Wrote}:
Edward_Lii {l Wrote}:I'll try and see if I can contact them. Though, what should we do in case we don't know under which license an addon falls?


I don't know... do we need to remove them? :( I don't like that.

Here is the list of addons with license unclear:



Hi All!

Nice to see this back in action. A few month ago, I noticed it went onto GitHub, but nobody was seem to be doing much.

Can't contribute to development - don't really have the time - but would love to do additional level packs with the new features.

As for Twelve Pits - At the time I didn't even consider a license, but if we need one, then I prefer the GPLv3 license. What license are we using for the software? If it's MIT then I think that's compatible. Let me know if that is okay.

Also, if I develop additional levels - should I become a part of the GitHub project? It's been a while since I done any serious development.

bgalon_2000
bgalon_2000
 
Posts: 15
Joined: 26 Sep 2012, 16:40

Re: V0.5 Preparation thread

Postby acme_pjz » 12 Aug 2018, 04:19

Hi,

bgalon_2000 {l Wrote}:As for Twelve Pits - At the time I didn't even consider a license, but if we need one, then I prefer the GPLv3 license. What license are we using for the software? If it's MIT then I think that's compatible. Let me know if that is okay.


GPLv3 license for levels seems a little bit weird, but I think it's OK :) The game itself is GPLv3 of course. See here https://forum.freegamedev.net/viewtopic ... 351#p54979 for previous license discussions.

bgalon_2000 {l Wrote}:Also, if I develop additional levels - should I become a part of the GitHub project? It's been a while since I done any serious development.


No, you don't need to (but of course you can) do that. You can either

  • still use this forum for posting levels/levelpacks,
  • or you can create a GitHub project by yourself for your levels if you want to share all the work-in-progress levels with others.
  • If you want to upload addon by yourself (beware the addon zip and metadata format is still undocumented, please test on your computer first), you can fork the addon repository and submit a pull request.
Last edited by acme_pjz on 13 Aug 2018, 19:04, edited 1 time in total.
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 514
Joined: 10 Dec 2009, 15:32
Location: Biejing, China

Re: V0.5 Preparation thread

Postby GunChleoc » 12 Aug 2018, 11:08

acme_pjz {l Wrote}:Well, last week I translated locally on my computer using Poedit. When I want to use "tx push -t -l zh_CN" nothing get uploaded :| I have to use "--force" flag :( Maybe there are some bugs on comparing file modification time.

I never push anything from the command line except for the .pot updates, so I haven't run into this bug before. Definitely worth telling the Transifex team about.

acme_pjz {l Wrote}:[EDIT] Also, it looks like that Transfiex will delete translations whose original text was removed from .pot files. This causes Translation Memory get lost. The local editor, for example Poedit, simply comments out the removed translations, which can still be used in Translation Memory.

I have never sourced fuzzy translations from po files, because I just use Virtaal's translation memory. So, it would be interesting to hear from the other translators. Unless we have bigger translation teams, it doesn't really matter, unless POEdit doesn't keep its own translation memory for you to source the strings from? I have only ever used it for its validation functions, because I prefer working with Virtaal.
User avatar
GunChleoc
 
Posts: 300
Joined: 20 Sep 2012, 22:45

Re: V0.5 Preparation thread

Postby acme_pjz » 12 Aug 2018, 16:44

Today it works... I update the messages.pot locally, "tx push -s", then I update the zh_CN translation locally, then "tx push -t -l zh_CN" works. However, it uploads all zh_CN translations, including those which are unmodified at all.

Also, the po files obtained by "tx pull" looks weird, too, for example in https://github.com/acmepjz/meandmyshado ... cale/de.po you can see something weird like "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE" and "charset=CHARSET".

.......

(It gets off-topic since we're in V0.5 preparation thread, not Transfiex bug reporting thread.)

@GunChleoc : Should I invite you to the language team or you send a request to me on Transfiex?
Some of my open source games on GitHub
User avatar
acme_pjz
 
Posts: 514
Joined: 10 Dec 2009, 15:32
Location: Biejing, China

Re: V0.5 Preparation thread

Postby GunChleoc » 13 Aug 2018, 08:37

acme_pjz {l Wrote}:Today it works... I update the messages.pot locally, "tx push -s", then I update the zh_CN translation locally, then "tx push -t -l zh_CN" works. However, it uploads all zh_CN translations, including those which are unmodified at all.

Yep, it doesn't track that, you'd need to restrict the resource manually with -r. I always upload manually via the web interface when I translate something, because we don't accept pull requests for translations on my project.
User avatar
GunChleoc
 
Posts: 300
Joined: 20 Sep 2012, 22:45

Who is online

Users browsing this forum: No registered users and 1 guest