Log In  

Cart #52950 | 2018-05-23 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Several updates, but one new curious problem:

I'm attempting to transition the player to a third scene (the second floor of the yurt), which sets player.x=#, in this case around 340, which is the appropriate x value relative to the area of the map I've used to design that scene. However, it appears using the code I've designed (which has worked just fine for transitions between the first and second scenes) the largest X coordinate value I can assign in this transition method is x=295. Setting to x=296 causes the player to become stuck, and no button input is registering. Its almost as if the draw method is no longer working at that point, because the player doesn't move at all. Typically when I've accidentally made the player's coordinates persistent, pushing in the directions still causes the directional animations to play out, but not in this situation. Is this a known issue that I'm unaware of, asking the player's x value to be set higher than 296? If so, how do we get usage out of the total map area? I'm at a loss here.


Davbo with the win!

Needed to use elseif to split the two different condition sets for the door transition. It works like a charm, and was just as simple of a fix as I suspected it would be. Yeesh.

Time to program the interactive objects for multi-purpose use (computer, dresser, any other items I can come up with for this "tech demo").


Uploaded now is a version where I've commented out the attempt to return the game state to the first level, at around line 304 in-code. As you can see, the transition works perfectly one-way, I just want to be able to return the game state to its original form when interacting with the "transition" object while in the "yurt interior" game state. It really seems like it should be simple, but there's some arcane order-of-operations stuff that I'm ignorant to thats preventing me from making it happen.

Anyone willing to have a look?

Cart #52795 | 2018-05-16 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

I've basically arranged everything as I'd like, and am ready to begin creating scenes that are more than simply tech demos for programming purposes. I've run into an issue that should likely be resolved by discovering an already-invented wheel, if someone can point me in the right direction.

In short:

A flag (game.stage) is set to a string ("island" or "yurt") depending on which scene I'd like to depict. Modifying this flag occurs when the player is "proximal" to an object called "transition". In the most update to date code I have, I'm attempting to set the flag to game.stage = "yurt" if the transition object is interacted with only if the currect game.stage=="island", and then vice versa. You can see my attempt at this at around line 295 (using Atom which I believe is offset three lines from what PICO-8 sees).

From what I can tell is happening, the program checks to see if btnp(4) and transition.proximal and game.stage=="island" and attempts to make the transition, but as-designed it loops through the next if-statement and resets game.stage back to "island". I would have though that using btnp() would prevent this from happening, but I must be failing to understand how this is working. As I have it written now, it seems like it should "just work", but... alas.

Here's where the already-invented-wheels might come in. Hopefully I've explained this simply so that it can be understood easily. How do I achieve what I'm attempting to do without the btnp(4) causing the scene to switch and switch back in one go? I can tell its partially working because one of the effects of switching to game.stage="yurt" is that the player's coordinates are reset per lines 303 and 304.

Anyone willing to review and advise?

Shifted to a system where every actor / object will be created at _init(), plotted onto the absolute X/Y coordinates of the map system, rather than screen real estate. When interacting with transition object the camera and map are adjusted as necessary to actually transition to the next scene on the map. Objects like the mom and dad characters can be moved when the scene.counter variable changes, but the may simply be left behind if no longer needed. I suspect as the little game scenario plays out that certain actors will need to be relocated for further narrative interaction.

One of my last issues was figuring out how to move the player along with these transitions without the new coordinates being persistent and thus keeping the player trapped in place. It seems obvious now, but adjusting the player's coordinates in the check for interaction with the transition object associated with a btnp() to trigger did the trick.

Cart #52746 | 2018-05-14 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

More updates.

Bridgs' object creation method appears to work great when the only time it is called is on _init (once), otherwise it creates a new object every time the game updates. Using the coin collection method she created where the object is only drawn when a certain variable is true (or not false..), I was able to adapt that for when to show the invisible barrier objects on the island. This means I had to create new invisible barrier objects for any other scenes to come, like the yurt interior that is transitioned to when you enter the door, so thats less than ideal

The _draw() function works just fine for drawing non-interactive props like the moving waves and the computer inside the yurt, and for establishing what cls() color to use, what section of the map data to draw to the screen, etc. It can't be used to call additional objects though, and apparently neither can the _update() function, as these care called constantly, creating more and more iterations of the objects that are created using the make_game_object function.

I can continue to adapt this for my purposes, but I think perhaps a meaningful further piece of guidance in any further tutorials in this series from bridgs (thanks again!) would be more ways to interact with the objects as designed in the tutorial, namely to move them! All I'd like to do is move existing objects! Clearly there's something about the method as-designed that I'm failing to comprehend or grapple with.

Paging @bridgs?

Cart #52703 | 2018-05-14 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Made several additions.

I've changed the invisible barriers to a highly visible sprite for testing, and added a teleport block that when proximal to and btnp(4) changes the scene to the interior of the house, as a means of transitioning.

As the barriers, player and "mom" and "dad" actors are created with the "make_game_object" function from bridgs' excellent tutorials (but not created by me...) I do not fully understand how to manage moving those objects when transferring from the first scene to the next. I can manage removing the sprites that are simply drawn to the screen only when the first scene is active, but the other interactive objects I'm stumped on. I'll have to keep reviewing bridgs' tutorials and get a better understanding of the syntax and how to continue to adapt it for my purposes.

My best estimate is that due to how the player, barriers, mom/dad are initialized to the screen, my method of transitioning from one scene to another won't be able to affect those objects without changing some states and values of their properties as established in the "make_game_object" function as it relates to each specific object. Lots more to ponder.

Definitely a great way to learn this, but also poses some challenge when you don't fully understand shared code..

Cart #52645 | 2018-05-12 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Special thanks to @bridgs_dev for her excellent tutorials on Youtube. I've converted my first piece of learning script from last year to utilize her game logic, and have made my own alterations. My previous attempt was --terrible-- and running into her tutorials delivered a better method to accomplish the same things I was trying to do, and even showed me the "right" way to do it, as well as clued me in further on Lua syntax. I'm improving!

I'm posting this basically just to keep her updated. Still absolutely a work in progress.

I don't intend to create an RPG or anything of that sort, but closer to a "visual novel" or a mix between a top-down action game and a point-and-click adventure.

I intend to make a series of these types of "games" and have the scenarios be "social stories", which are a teaching tool for Early Childhood Education. Most of them you can find out there are incredibly rudimentary 4-6 page doodled comics showcasing appropriate behavior or short narratives about how a child should tackle a problem or situation. I think PICO-8 is perfect for doing this in a far more entertaining way.

P#52646 2018-05-12 11:50 ( Edited 2018-05-23 01:59)

Do you know the else keyword?

I've only had a quick look but I think you want to do

if btnp(4) then 
If game.stage=="island" and [your collision code] then
elseif game.stage=="yurt" and [your collision code] then

Then on a transition if the first if statement is hit you will skip the second, preventing you from resetting the state immediately.

You are correct that btnp will prevent the state being set back and forth on consecutive frames - your problem seems to be that it's being set back and forth on the same frame.

Looks like you're making a good effort to get to grips with this stuff - keep working at it!

P#52804 2018-05-16 02:37 ( Edited 2018-05-16 06:54)


You did it, my dude. It was indeed exactly as obvious as I predicted it would be. I do in fact use elseif in my code, and will need to ensure I continue to do so for my transition logic. Thanks so much for digging in and identifying this!

My dude!

P#52819 2018-05-16 20:31 ( Edited 2018-05-17 00:31)

It looks as though when I transition to played to the third scene, the game thinks the player is now proximal to one or more of the old actors, and the btnp(4) triggers player.busy to be true. Might have to keep digging before I call for help..

P#52951 2018-05-22 21:59 ( Edited 2018-05-23 01:59)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-02-24 14:50:28 | 0.042s | Q:32