Lok Revival: first alpha version

[Vincent]

@TheLaw:
Don't worry, I won't suicide because of your comment! lol!  I said I was a "little" disheartened.
The reason why the enemy doesn't really lets his guard down is because I thought the AI would be weak and then the enemies would be easy to beat.  When I started making the AI I wasn't really confident, being a first attempt, so I decided the make the attacks and behaviors as tight as possible.  The way the AI works, the enemy tries to get in range, then he tries an appropriate attack based on Kain's location, then he has a cooldown.  It's about the same for all enemies.  During the cooldown, the enemy does not attack.  The cooldown is different for all enemies.  The red spearman steps back during his cooldown.  So it leaves an opening to fit a sword attack.

@bluemonkmn
The enemies all have a weakness or a technique to fight and kill them easily.  The thing is, I didn't really planned those techniques while development, but while I fought them I found good ways to defeat them.  For example, the red spearman does not have an upward diagonal attack.  So Kain can get near the spearman by jumping toward him and slash him on the way down.  It usually gets the spearman down fast and easy enough.  I would advise against bull rushing the enemies and hope that you kill them before you die!   The enemies are quite resilient and Kain does not have a lot of health at the beginning.

The best approach to the fighting, I think, is to stay on the outside.  Look for an opening, get in range, attack and get out of the enemy's range before he counter attacks.  I would call it a dodge game rather than a fighting game! lol!

About the fight: balancing out the damage dealt by Kain and the enemies and the amount of health is something I plan to do when the game is near completion.  I think it is a little soon for that...  I suppose it will be a lot of tweaking and testing.


Can't wait to hear some other comments!  

Thanks again guys!

[Vincent]

Just a quick note, I solved the jump attack problem.  You couldn't attack in the air as long as the jump button was held down, even if Kain wasn't floating yet.  Now, Kain cannot attack while he floats, but he can attack in the air without the need of letting the jump button go.  I'm going to change a couple of other things and then I'll update the repository version.

[bluemonkmn]

My GF, Amy, was playing briefly this morning and managed to hit the *first* enemy causing him to go through a door.  So I was looking at the rules to see if I could figure out why this might happen.  Without reviewing all your code, I suspect it has to do with the way to react to solid sprites.  I thought you could simply use ReactToPush to make your sprites avoid other sprites like doors.  Can't you do this?  The way you are doing it now, it appears that you are checking to see if the sprite is colliding with a door and then reacting to it if there is a collision.  But if there is a collision, it may already be too late.  You should be reacting to other solid sprites before a collision even occurs.  I'm not sure if this is actually the case because it appears you have a separate sprite for detecting collisions, but if that sprite is always in the same location as the enemy sprite (instead of one frame ahead of it), I think this would be a problem.

[durnurd]

As I am wont to do, I was jumping around a lot and was in the air when I met the first spearman, which caused me to hover in the air during the dialog.  It also seems that the game was running particularly slowly on that first map.  Once I got to other maps the game ran much more smoothly, but on that first map, my CPU was pegged at 100%.

[Vincent]

@bluemonkmn:

Thanks, I'll look into it. 

Actually, before I used to solid sprite feature (reactToPush etc) I had my own way of dealing with solid sprites.  It could be that some old stuff is still there.  The enemy sprites are usually into 2 or 3 parts:
1- The first part is the body, moving around.  All the main code of the enemy is in there.  The collisions are managed in here.
2- The weapons or projectiles.  They spawn when an attack is launched and should not influence the body going through the door.
3- The "blood container", when the enemy is dying, I switch the body sprite to a blood container, which behaves exactly like the red urn in the tutorial section.  When this sprite appears, the body disappear, so it should not influence the door collisions again.  Or, maybe you were talking about Kain's sprite?  I'm not sure I follwow you when you say that I have a separate sprite to detect collision.

Anyway, you have given me a good hint on how to solve this!  Thanks!

@durnurd:
Yeah, it's easy to make "weird" cutscenes if you jump around when they start.  It usually won't mess up the game when the gameplay resumes, but it should looks strange to see Kain float in mid-air!  I'll see if I can improve it.  Thanks!

About the performance, I'm having the same problem but it is an on and off type of problem.  Sometimes, I place the framecap at 60 and when I run the game, it really slows down to about 30 fps, for seemingly no reason.  So I raise the FPS to 90 (so it plays at 60 and it makes debugging faster) and all of sudden, after a few modifications, the game runs at a fast 90 fps.  So I reduced to fps to 60 and it works fine for a while...  And eventually, it drops down to around 30.  Note that those fps alterations do not appear during a single play session.  It's when I stop the game and restart it that the fps changes.

I never notices that the CPU was really freaking though.  I'll check it out the next time it happens.

Thanks again durnurd!

[SmartBoy16]

About the performance, I'm having the same problem but it is an on and off type of problem.  Sometimes, I place the framecap at 60 and when I run the game, it really slows down to about 30 fps, for seemingly no reason.  So I raise the FPS to 90 (so it plays at 60 and it makes debugging faster) and all of sudden, after a few modifications, the game runs at a fast 90 fps.  So I reduced to fps to 60 and it works fine for a while...  And eventually, it drops down to around 30.  Note that those fps alterations do not appear during a single play session.  It's when I stop the game and restart it that the fps changes.

this probably means you have the framerate code twice somewhere, the more framerate codes on at the same time, the more it slows it down

[Vincent]

Hi smartboy!

Yeah, I know it is usually the case, (multiple calls to LimitFrameRate), but in this case, it doesn't seem to be.  I put my LimitFramerate function on the main player sprite and it's there only one per map...  So, I don't see what could the problem be.  I cannot pinpoint what causes the FPS to drop and what restores it...

[SmartBoy16]

that's probably it! what is actually happening is LimitFrameRate is being called more than once because the player sprite AND the map rules are limiting the framerate, they both are run before the screen is drawn (bluemonk correct me if im wrong) thus doubling the framerate limiter.

there are 2 ways to fix this (I think, im new-ish to SGDK2)

* use FrameRateLimiter only on map rules. this would be useful if the playersprite changes often in the game (from one character to another)
* use FrameRateLimiter only on the player sprite. this is useful if the only sprite the player controls is this one.


hope this helps!

[Vincent]

@SmartBoy16:
haha!  I might not have been clear enough in my explanation! :p

I meant that I have a limit frame rate rule on the player sprite and I have only one player sprite per map.  Which means only one limit frame rate.
I think you understood that I have one limit frame rate on my player sprite AND one limit frame rate rule on each map.  Which makes two rules.  But it is not the case.

Thanks for your help!  Although it is not the problem I face, the situation you mention would be a problem and the solution you propose is the right one.

[Vincent]

@bluemonkmn

I just found out what you were saying about the collision problem with the "first" enemy going through the door.  It was indeed my old set of code was managing (not perfectly) collisions with doors that got in the way with your rule ReactToPush.  I think it's one of those case when you're looking at the same code for such a long time that you don't see it anymore.  In my case, it's very true. 

Thanks a lot for pointing this out for me!  It solved the door collisions problems for the enemies!

[bluemonkmn]

Great!  Glad that problem is worked out.  I have two other thoughts this morning.
1) I have never been very fond of the ASD key layout for any games.  I don't think you should necessarily change it, but maybe you could make it more clear to the player when they start what the layout is and how to change it with this idea: automatically display the options dialog when a new game starts (a game where the user has not set/saved the controls yet).
2) The latest version of the game I downloaded from the project site did not hit 100% CPU for me this morning (I haven't checked other times).  There must be some sprite doing a lot of busy work.  I remember durnurd's Technoventure demo used to have a similar problem when one of the sprites (the sprite that follows the player smartly) was searching the whole map when it couldn't figure out the path to reach the player (because the player got blocked off from the other sprite).  You could try running the game in a Visual Studio debugger and see if you can get the problem to occur that way.  If so, then you could hit the break/pause button and would likely see the code that is taking all the time.

[durnurd]

One thing I should mention, if it makes a difference, is that when I paused the game, the CPU was still pegged at 100%.  Not sure why, is the background map still doing all of its processing?

[bluemonkmn]

Five more things I notice this morning so far as I play:
1) I was having trouble activating the save pillar because I had the telekinetic bolt skill selected and I couldn't get back to the Activate skill.  If someone forgets how to play, maybe you should tell them to press Esc to access the menu and see instructions.
2) When minimized the window and then restored it again, it stays very small and I can't resize it (finally I activated the window menu (left of the file menu) with the alt key and selected the size command, but I think minimizing the window should not have this problem).
3) It wasn't clear that I have to hold select before pushing a direction button.  Is there a way to make that more clear?  Do you plan on displaying a pop-up view of the available skills when the select button is pressed so it's clear which directions activate which skills?
4) I was standing upstairs from from a spear man.  When I tried to suck his life, it all went over my head and I didn't get any.
5) The puzzle involving the box on the elevator didn't seem quite right.  I think the first time I encountered it, I pushed the box off the elevator and lifted myself to the top floor, then I walked to the right and back to the left and the box was conveniently there for me to use.  It seems like it would be a better puzzle if you had to use the elevator to lift the box, then walk around the outside to get to the box.  I suspect that was the intended puzzle.

[Vincent]

Hi guys!

Sorry for the delay, I was very busy this week and I couldn't work on my game.  But I'm back on it now!

I updated the submission in the repository.

I  added the precise collision detection (thanks again durnurd).  It's much better like this although it is not perfect.  Maybe I am not setting the offset like I should...

Zooming without lines is now a reality!   Wow!  To make sure the game is always displayed correctly, I removed to possibility to resize the window with the border.  I added a combobox in the tools menu to select one of the following game sizes: 320x240, 640x480, 960x720 and 1280x960. 

Ok, now I'll go through your five points bluemonkmn:
1- Do you have a suggestion on how, when and where to display this information?
2- Solved!
3- I thought about displaying a pop-up for the skills...  but there is already 8 skills done so it would be a large "pop-up".  Since the skill selection by holding down the select button is "real time", showing a pop-up would probably be a problem since it would hide the game...  Or should I make it transparent enough to see what's happening behind?  What do you think?
4- Yeah, that problem happens.  I don't really know why since I'm not using a buggy custom function of my own design (), but the PushTowardCategory function...  Anyway, I modified the blood drinking in the version.  It might not look as "cool" as it did (maybe I'll tweak this again later), but at least now no blood is lost.
5- Oh!  I missed that!  That's because I keep the location of the elevator and the box in the same counter.  So if you leave the room while the elevator is up and the box is down, then the box is considered up when you get back into the room.  I'll split this into two counters then.

Also, about durnurd's issue with the CPU going wild, I can't reproduce it.  I thought it was because of a problem with the fps, but it does seem to be the case.   I'm sorry, I don't see how I will be able to solve this one.

Thanks a lot guys!  Things are going well.  I will begin working on level 2 before long.

[Jam0864]

Why would you change aspect ratios in the drop down box? I thought if you started with something 4:3 like 320x240 and 640x480 you would continue like that to avoid giving an advantage to some players, (eg 1280x1024 not 1280x960)

Or is this deliberate?