What next ?

[pjasicek]

Hi everyone,

I was diving again into this project for the past 2 days and I realized it is not that far from being entirely completed. The stuff that's missing right now is:

Level 10 bossfight - Marrow - The fight is really dumbed down Level 12 bossfight - Aquatis - Same as above, he just stands there and attacks in melee range Level 13 + bossfight (Red Tail) Level 14 + bossfight (Haha I dread implementing this bossfight in C++)

There are some logics not implemented here and there, e.g. picking up barrels and throwing them, picking up enemies and throwing them. But I think I am going to skip it since it would eat a lot of my time and it's not really THAT useful IMO to have it in the game.

Now I am wondering whether I should focus on implementing the level 10 + 12 bossfights properly or just get the levels 13 and 14 done and then get back to the bossfights ?

Then I will probably really need to create some release packages (Windows + some Linux distros) since the last ones are REALLY old.

[pjasicek]

Also, thanks to @RicoRodriges , I think it might be possible to disguise the emscripten web build as "native" android application in some way ? :-)

[jstasiak]

First of all, not sure if I mentioned this already in some other place – thank you for working on this, it's really cool to see an open source version of one of my favorite games, I can't overstate this.

The last time I gave it a shot (a few months back):

• the enemies' melee attacks were too fast compared to the original game I think
• enemies' range attacks were activated (and Claw got hit!) when, due to vertical position difference, enemies were inactive in the original game

I think addressing those and other details is really important to consider this complete – I'll try to send pull requests when/if I figure out how to fix those.

[pjasicek]

@jstasiak Thank you for the kind words, it really means a lot to me :-)

• The point about enemies attacking too fast - yeah, I think there should be some initial delay in the attack animation. There is a lot of stuff in the game which they must have hardcoded and hacked from within their engine and this might be one of them
• I am not sure what you mean to be honest - is the range for triggering attacks too wide or the height of the sensor too tall ? Or something entirely different ?

[jstasiak]

The height of the sensor I think. As far as I remember I discovered it when at the very beginning of The Footpath I went to the platform above the enemy (in the area circled red) and I still had knives thrown at me on (from my point of view) ground level, while in the original game this didn't happen (again – to the best of my memory, I need to rebuild the game and try to find what it was exactly).

[pjasicek]

@jstasiak Ah, that's all about tweaking the ranged sensor's parameters (width and in this case height + offset), I will take a look at that

By the way, level 13 complete minus chameleon minus bossfight :-) Now it feels like just assembling puzzle from everything I implemented in previous levels.

[pjasicek]

I noticed that I previously attempted to fix the "too fast" attacks from enemies, but I did it the other way around - their first attack is REALLY fast, but the next one has some added delay (defined in the component). This is a problem when Claw enters and leaves the agro sensor, thus resets the attack animation, making the attacks way too fast.

I need to add an option to define attack start delay.

[pjasicek]

Okay I fixed the NPCs attacking too quickly - added attack delay also to the first attack. The numbers (delays) maybe need some tweaking though, I am not sure what the real values are in the original game.

Regarding the bug where NPCs attack where they shouldn't, that's abit tricky.

[pjasicek]

Okay, fixed the line of sight issue also :-)

[jstasiak]

That's great to hear! I'll play some tonight then. :)

[sshniro]

Wow, thanks for this :) one of my favorite game of all time.

[RicoRodriges]

Also, thanks to @RicoRodriges , I think it might be possible to disguise the emscripten web build as "native" android application in some way ? :-)

Nice to see I could launch active development process back 😀. Please let's keep this going!

By the way I know github allows to create project's github.io pages. Web build needs a simple file hosting. These 2 facts mean that we could try to let people play this game on github. But maybe one big data file with game assets should be separated into two pieces because github limits file sizes.

[jstasiak]

FWIW I believe it'd be prudent to separate the open source code and the game files and avoid hosting the game files in this repository, in any form – I'd hate to lose access to the code in case GitHub was forced to act on some copyright claim and nuked the repo.

[pjasicek]

Yeah, I'm not going to include the REZ assets in this repo, better be safe than sorry. Not sure if it would be a violation of something if I added a link for downloading the REZ archive from a different site (e.g. my website) ?

[RicoRodriges]

I'm trying to decrease technical debt with emscripten and SDL mixer functions. There is emscripten port of mixer library. It was broken and is working again since one of the March update. Everything is compiled but I ran into some problems.

Right now every mixer function is emulated by plain js code. SDL_RWFromMem returns file name, Mix_LoadWAV_RW load file into browser player, ... And it works fast and fine.

Fair SDL mixer port functions is another thing. All game assets in RAM + ResourceCache loads files into RAM + SDL_RWFromMem loads the same files into RAM and after that mixer starts feeding the browser small pieces of audio chunks.

First of all current 256mb RAM limit is not enough. Sad but not a problem. Second thing is Google Chrome works fine. But there is 1-1.5 sec audio delays in FireFox. Looks like Chrome start playing audio on loading and FireFox needs larger chunks.

I'm continue to figure out but I'm afraid current implementation is the most optimal. Yes we could try to implement some mixer functions ourself but there is no guarantee that it will work after next emscripten update.

[jstasiak]

Yeah, I'm not going to include the REZ assets in this repo, better be safe than sorry. Not sure if it would be a violation of something if I added a link for downloading the REZ archive from a different site (e.g. my website) ?

I read too many things on this to be sure about the outcome, but this is something I'd do in case like this, yeah.