Chadwyk.com

The ramblings of a developer

Perspective and scaling the player

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.

Level editor

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.

Here is a demo of it so far.

Walk boxes and Path finding using A*

This week I spent a few days trying to figure out walk boxes and path finding algorithms, which led to a lot of frustration and wishing that I paid more attention in my freshman CS 367 class on data structures!

After doing a lot of research and finding very little code online to follow, I was finally able to stitch together a prototype that implements walk boxes and path finding!

Walk boxes are polygons that limit the areas that a player can walk in the world.  Path finding is finding the shortest path from a point in Polygon A to a point in polygon Z using those walk boxes to go around obstacles. If you have to walk through several polygons to get to a target, it will return a list of the polygons that has the shortest path.

Here is a really crude example.  Please excuse my horrible Photoshopping skills, but in this image the green arrow is what the algorithm, A* (pronounced A star), would calculate the path of the player should be if they were on A and wanted to get to H. It would then tell me the path should be through polygons A, B, C, D, E, F, G, H.

I found many good articles about the theory behind it, but I couldn’t find much code.  What I could find, wasn’t written in C++. The other issue was that a lot of the articles were written for a simplified version of A* using a grid system. This would be great if I was making a tile based game like Lumps of Clay or Super Mario Brothers, but it doesn’t really help much when it comes to polygons / nodes.

In the end I found a wonderful article written by Julian Ceipek. http://jceipek.com/Olin-Coding-Tutorials/pathing.html It describes path finding much better than I ever could.  It also describes in detail the  algorithm to find the shortest path between two nodes.  Perfect! That’s precisely what I wanted.  But the little code he had was written in another language.

It took a while but I was able to make my own node / graph class to store the node and edge data.  Then I was able to port his code over to C++ to analyze the graph data to find the shortest path between nodes. It seems to be working after some tweaks.

Now I need to find some time to implement the algorithm, “Simple Stupid Funnel”.  It is a smoothing algorithm which makes the path taken more direct instead of having the player walk to the center of each polygon before moving on to the next.

 

Without further ado, a short demo!

 

Point and Click!

For the past few days, I have been playing around with Cocos2d-x.  It is a bit different than Cocos2d-iphone, but very similar so I know the concepts.  I just need to figure out the correct syntax since a lot of the old classes have been deprecated.

 

Anyways, I have started a framework with a GUI for the buttons for the verbs.  When you click them, it also updates the label on the cursor, and when hovering over objects it will update the label to say for example, “Open door”.

 

Tonight I got working the player animations and movements.  You can click around on the screen and the player character will follow the points that you clicked.

 

It’s slowly coming together, but of course a lot more to do!

 

It is very basic, but here is a quick sample video of what I’ve done.  The graphics are temporary and taken from a free site.

Changing direction to Cocos2d-x

So I know I was really excited to create my own engine from scratch, but I fear at this point in time it is just way too far over my head.  I’ve spent the last several days trying to get SDL or OpenGL to load and display images, with limited success. Once I get an image loaded, I’m unable to really abstract it into a class to load multiple instances.  If I was able to, it wouldn’t be very efficient either because I’d need to figure out how to do texture atlases and texture batching, as well figure a way to manage the textures in memory.  It’s all really complex to someone that hasn’t touched c++ in a long time.

 

At the moment I feel fairly defeated, so instead, for now, since someone has already done all the hard work, I think I’m going abandon my engine attempt and try out Cocos2d-x instead.  It is a C++ version of the Cocos2d-iphone engine which I used to make Lumps of Clay.  It should be fairly similar I think.  Since Cocos2d-x is written in C++ it is cross platform compatible, and I believe the renderer uses OpenGL at the core, but it’s super easy to load images as Cocos2d-x does all the hard work for you .  I just don’t know how compatible it will be if I ever want to port it to devices like the Nintendo Switch. But if the Switch will be incompatible with Cocos2d-x, it would probably be incompatible with my custom engine since they were both going to be OpenGL based.

 

Maybe I’ll try to make a simple game with it, then send my pitch to Nintendo so I can get a Developer Kit, then see how hard it would be to port it.  We’ll see.  For now, I’m going to abandon my own engine and try to get a prototype going this weekend in Cocos2d-x.

 

In the future I can always revisit my own engine project.

 

UPDATE

I hopped on the forum for cocos2d-x and there is a thread about supporting the Switch since it was revealed that the Switch supports OpenGL.  It appears that at least one developer was able to port their game to the Switch from cocos2d-x, so that is good news!  There was not any posts lately on it so I left one asking if anyone else had been able to port to Switch.  Hoping to hear back some positive results!