Hello there, and welcome to the making of "Spidersly" the game. Beyond the basic concept, no work has been done yet. Which means that my entire process will be documented right here in the open...
I've incorporated some states to the screenXY system. (objectArrange / imageUpdate / fadeIn / playStart / play / playEnd / fadeOut / changeScreen) This allows for me to now control actions from a centralized system by timers, player input, or other triggers.
This is generally what each state controls :
"objectArrange" - player placement / collision side-walls on or off
"imageUpdate" - a trigger to change all screen images based on the new screenXY coordinates
"fadeIn" - fades out the alpha of the foreground layer
"playStart" - animates the player walking onscreen
"play" - the player interactive state (mouse clicks)
"playEnd" - animates the player walking offscreen
"fadeOut" - fades in the alpha of the foreground layer
"changeScreen" - changes the screenXY value based to the next screen, and restarts the screenStates loop
Here's an example of the screenXY system using the new states.
The Spidersly screenXY system just became much more powerful and expandable.
On the ScreenXY System and Simple Collision Pathfinding
Day 6 was a test of the breathing camera, layers in depth, and an introduction to my screenXY system concept for level design. Today is a test of the screenXY system with a couple of videos. (YouTube compression sure blows out whites!)
ScreenXY
It's a simple concept where the topmost screen is X1Y1. When the player reaches a side of the screen, a calculation figures out which screen to change to and where to place the player. The screen to the right is X1 +1, while the screen below will be Y1 +1. (I may just start at X100Y100 or something larger to avoid negatives in the other direction, but that'll be a matter of actual level design.)
As each new screen is loaded a series of defaults are applied, and only afterward are the screen specific rules checked. For instance borders (The black bars under the floor grid in the video) are placed on all sides of the screen by default to stop the player from continuing in that direction, but each screen has a rule for which ones aren't there. X1Y1 has no 'right' or 'bottom' border, X2Y1 has no 'left' or 'bottom', X1Y2 has no 'top' or 'left', and X2Y2 has no 'top' or 'right'. This creates a square map of four screens with only two alternative rules per screen. This will of course become much more complicated, but it's a decent groundwork.
Next step is a screenState system for loading, playing, and ending each screen. Right now there are no screen transitions, and states will allow for centralized event timing.
Simple Collision Pathfinding
While working with the border collision, I put some thought to the difference between walls and screen objects. I am using Gamesalad's own collision, but it has some weird behaviours to overcome. Right now the movement is a simple "go-directly-where-clicked" ruleset. When this is interrupted by a collision, the object will slide along the angle of the collision never meeting it's goal, therefore never stopping. This video is an example of a rather simple set of collision checks I built to keep the object moving towards the goal.
Playing with this pathfinding has inspired me to add some random movement to the spider overall. Insects have a mechanical scrambling quality to their movement that it would be cool to replicate.
For the open-world design of Spidersly, I had originally thought to have a scrolling tiled background. However, implementing a dynamic tile system in Gamesalad would be tricky, and I don't want to go down the road of laying out the whole world on one screen for a scrolling camera. “Herbert's Day Out” loaded new scenes for the different levels, which was pretty slow. The levels were all custom, and the camera moved along with the player. “Charles C. Gull” had a camera that followed the player up and down, and moving backgrounds that automatically cycled along the horizon. This allowed one image that was screen sized to loop continuously. Considering what I now know about Gamesalad and my goals for Spidersly, I've decided to attempt dynamically loading the map one screen at a time based on a simple X Y grid.
There are a few things I really like with this X Y screen system.
Each screen can be custom designed.
As long as I use good naming conventions, the map can be arranged relatively simply.
It frees the camera for some interesting effects.
With all of that in mind, I put together a little screen test with some simple art.
The camera cycles along a couple of waves to give it some life. The BG doesn't move with the camera, while the Light and two Dust images have an added constraint that works against the camera to give a sense of depth. Gamesalad doesn't have a Z value, so those types of effects have to be faked on the 2D plane. A bonus for not making an action game with the highest frame rate possible, is that I can use layered effects like screen on the Light and multiply for the Shadow! The player movement a simple 'click to move here' system for the test.
I like the idea of a player collecting XP and spending it freely on any available upgrades, but my stated goal of creating an elegantly simple RPG forces me to question such a system.
Upgrading abilities will allow for level advancement through both environmental obstacles and enemy encounters. It seems to me that an elegant solution would be to attach specific ability upgrades directly to player levels, with these levels based on earned XP. This removes the need for the player to think of XP as money, but more as a gauge of how close they are to advancing to the next environment.
What would this look like?
Imagine the starting area as a small corner of wall. Surrounded by high picture frames, a blowing air vent, and a crack. There are some small beetles in the area as a starting prey. The player is a small spider with only a weak pinching attack. The vent blows it back, the picture frames are too high of an obstacle, and that crack is a little too wide to walk across. Small prey like these beetles are not very strong, and after hunting a dozen of them the player hits the first level upgrade. This first level slightly increases the spider's size, strength and speed while also giving it the ability to jump short distances. Now the player can cross the wall crack, and explore the next area open to them. This next level will have it's own obstacles, and more difficult enemies. After a couple more level upgrades, the player will gain the ability to cross the air vent from the first area.
In this way I can control the “Levels” of an open-world game by locking them to the player's own abilities. Not a bad design.
