So it’s been a long time without an update. For a while there I was working a side job at work which sucked up my free time, then I kind of just lost interest. Then next thing I knew I let me website hosting expire, and my Apple account expire. I just now got my websites back up finally, but at this moment Lumps of Clay on the iOS App Store is still down. I’m unsure if I’m going to bring it back. It never saw too many downloads. In order to get it back on the store, I may need to recompile it since it’s been so long, but the engine it is written in, is no longer supported so I may run into issues. I’ve thought about porting it to another engine, but then I think “why should I do that unless I port it to other platforms”. Bringing it to Switch might be cool. But I also never got very far on my other project, which would have been a point and click adventure. I’d almost rather see that through than revisit an old game. I’ve kind of had more interest again to start that up again, so maybe I’ll do that.
It has been a long time since I posted anything or really worked on this project. I finally got some motivation and decided to tackle a couple of the hard issues that I was facing and wasn’t sure the best way how to handle.
First up, clicking outside of walk boxes. What should happen? Where should the player move? I went through lots of experimentation to find the best results. Finally I made an algorithm to expand a + out from the click point to see if it hit any walk boxes. If it does, then that is the spot the player walks to. If not, then it means it is in a diagonal and I need to find the closest walk box vertices to the click point, and have the player walk to that position.
That was difficult but I was able to handle it with relative ease. The second issue was that I had the player walking the path to a click point, but he would move to the center point of each walk box as he walked through them. This lead to a very unnatural look.
However, much of his code was hard to follow and in psuedo code. Luckily in the comments I found someone used his code in a javascript example and posted it on pastebin. http://pastebin.com/7jwrmw1i
It actually probably only took me a couple hours to port the code to c++. The hard part was to figure out all the “portal points” along the walking path. This means basically finding all the vertices of the edges the player walks through. Also not a horribly difficult task.
What was hard, is that I needed to keep track of the point orientation as the player walked the path. This was crazy hard for me to figure out the best way to do it. You could not just say, if the player goes left, the left vertices is the bottom one and the right is the top. That might work for some shaped walk boxes, but others it wouldn’t, especially if the angle you were walking into it was a diagonal.
The solution I finally came up with was to find the orientation of the segment. If it was mostly vertical, or mostly horizontal. Then I got the direction the player was moving in. Based on that I made the following conclusions which seem to work.
If the segment was vertical and player moving right, then left = upper vertices, right = lower.
If the segment was vertical and player moving left, then left = lower vertices, right = upper.
If the segment was horizontal and player moving up, then left = left vertices, right = right.
If the segment was horizontal and player moving down, then left = right vertices, right = left.
So now after tweaking my code to move the player along the path via the center points of each walk box, the player walks a smooth line to the click point!
The final step in the process is Steering. I’m unsure if I’m going to do this or not. I don’t think my walk box paths are going to be that big and it looks pretty good as is. For example, if a player is walking around a turn, he will make a 0-point turn. You could use steering to tell the character to generally stay within a range of the path I made with the Simple Stupid Funnel and steer back to it if they get off track. If I implement this, I’ll have to do some more research into the best way to implement it.
Ugh… today was a pain… I woke up and found an email that eBay locked my account because someone hacked my password. Turns out I think I used that same password on lumpsofclay.com… no good….
I also got an email that some random email address got set as an “Owner” for lumpsofclay.com. They hacked the site and since they had access to the server, where all my sites live, they messed up almost all of them. They hijacked them with malicious code and had google re-index my sites, so now crazy links pop up when you search for them.
Lame… I spent a good chunk of the day on chat with my hosting company. Luckily they were able to restore everything from backups. I then promptly changed all the passwords for website accounts, databases, and other websites that may have used any of those passwords that got hacked. I also updated WordPress and all plugins incase that was the attack vector, but I think it was an old password that may have been listed on some hacker sites from other websites getting hacked.
Bleh… I know I should never of done it, but it was easy to use the same password for multiple sites. But no more! No more using the same password for multiple sites! I’m going to start using password manager software!
It could have been worse… they could have got banking passwords (which were all different already).
I didn’t post last week at all, but that’s not to say I wasn’t working on the game at all. I spent a good amount of time making the room builder easier to use by adding a toolbar to the top. Prior I had keyboard shortcuts.
I then started the task of adding perspective scale to walk boxes. The higher up on the screen I want the player to look further away, smaller and move slower. There are a couple ways to handle this. You could just scale the player via it’s Y position, however I want a little more control than that.
I tried adding a scale value to each walk box, so as long as the player was in that box, he would be that size. However that didn’t work to well because there wasn’t a good way to set a speed to uniformly scale the player when it crossed a border to the new box.
I changed methods and assigned a scale value to each corner of the walk boxes. The closer to the corner it gets, the closer to that scale it gets. It took me a lot of experimentation to get it working. It still has some weirdness to it, but as long as I follow a few rules, it works.
Each walk box can only have at most 2 scale sizes in it. This means I am limited to using rectangles or triangles. If I add more points or scale sizes, it jumps up or down to different scale sizes too rapidly when it changes to a new closest point. I’m sure there is a way to somehow average some values together of all the points or something to get a smoother transition to use more corners, but I’m bad at math and this seems to work so I’m going to move on to the next thing.
I actually did try averaging the scales between the closest corner and all the other corners but that had the effect of shrinking the player in the center of the box and growing him along the edges, which kind of makes sense.
The method I am using to determine the scale is the following:
Get the closest point to the player and second closest point to the player with a different scale value
Get the difference in scale between the two
Get the distance between the two on the Y axis
Divide the difference in scale by the distance
Subtract that value from the larger scale size
When the player walks, multiply the scale by the speed that I’m moving it so that it moves slower when “further away” from the camera
In the video below, the blue line drawn is the distance from player to the closest corner, and the red is to the second closest. I set the scale values pretty drastically different for testing purposes so you can really see the scale changes. At the top of the screen the scale is .5, and bottom of the screen 1.0 – In the actual game, I don’t think they will be so drastic.
I’m going to hold off on tweaking the path finding and smoothing algorithms until later. Instead, this week I decided to take what I learned from last week to create a new application that I’ll be developing along side the game. It will have much of the same code as the game, but it’s main functionality will be a level editor. This will save me a lot of time in creating each room of the game. I’ll be able to quickly layout the room and easily edit them visually instead of the long slow process of doing it in code.
I will be able to drop in a background, click and draw where I want the walk boxes to be and how they connect with each other. I’ll be able to add portals/doors, game objects and other sprites into it. Then when I’m done with the level, I can save the configuration to a json file so the game will be able to easily load it.
I have the file loading, exporting to json, and path finding working with a test mode, but I need to add the tools yet to add other objects, and images. I also need to add the ability to delete points of a polygon or whole polygons.