Um so, this might be a bit of a read… I was trying to create a way to present digital comics with a little bit more interaction than a standard PDF. I figured an app would be a nice way to present them and people might respond better. I tried Tyranobuilder which is a cool tool for story telling using Visual Novels, but I feel like there are too many bugs and the development has slowed down not to mention people have weird ideas when they hear “Visual Novel” even if I’m not making one. Then I ran across Panoply for Unity which seemed ideal fro presenting comic images it even gives a swiping morsion for tables that feels like flipping through a book, but the problem was Unity itself. Unfortunately, anything outside of what the plug-in itself does (like playing a sound or having a dedicated button just to exit the comic) requires an understanding of Unity I don’t have. Gdevelop has been on my computer longer than Unity so I finally decided to give it a try. After a few tutorials I figured it can’t be too difficult to get this to display a few comic panels in a dramatic way, right?
First experiment was getting the “game” to switch pages. For that I lined up my pages along the X axis, I placed a target on the screen, told the camera to follow on the target, and on the click of an on screen button the target would proceed to tween to the middle of the next page or back from a previous (making each page 1600 pixels wide, I figured each button press would just send the target +1600 pixels to each page and the camera would follow). It works…kinda, but if you click the button more than once during the tween it throws off the camera causing it to stop between pages, and even with the trigger once command this happens. Whats more, when it “works” (if you don’t double click) the camera makes it to the next page, but the target seems to just leave entirely going further than the 1600 pixels.
With no clue how to keep the camera from stopping mid way on a double press I decided to try putting each page in a scene and maybe, more like Panoply, I could control the reveal of the page a bit more dramatically. Trying to do something as “simple” as having a black screen fade into the next scene (simple for other applications I suppose) I couldn’t figure it out for the life of me. Something like Tyranobuilder and Panoply have the ability to fade in or out fairly easily. A bit of googling later and I came across references to the “Do timedelta()” command, except I couldn’t figure out how to give the “Do” command as all the examples are from 2015 and example projects aren’t hosted anymore, also I figure Gdevelop has changed a bit since 2015, or maybe my version of Gdevelop is out of date? Because I did eventually get it to do the fade but without the same timedelta command I was being told was the method… but I honestly don’t understand why it worked, I feel like I just got lucky “randomly” clicking and entering stuff in fields. (by random I mean I just followed anything that even looked like it would do what I wanted. I dont even remember where I got the bit of code for the timer.)
Your method of lining up the pages and moving the CamTarget horizontally is perfetly fine. It’s the implementation that needs a bit of tweaking.
In your first screen snip, you have the trigger once as a subevent, with no actions. It will do nothing; it doesn not affect the parent event one bit. And as a result you are repeatedly kicking off the tween, the effects of which you experience.
To fix this, move those Trigger Once conditions (dragging them in the editor is the simplest way) to the parent events (the ones that check for cursor over an object and left mouse button down).
In addition to moving that trigger Once condition, add 2 more conditions to check that neither of the CamTarget tweens exist.
And then create 2 new events (say just before the scene change event) one for each CamTarget tween. These should have conditions that check if the CamTarget tween has finished playing, with actions that remove the finished tween.
For the fading, what you have is not ideal, as the opacity will be updated indefinitely once the time has passed 3 seconds. You’d be better off adding a tween behaviour to the fade object, and using an opacity tween to fade it in or out.
Thanks for the reply!
The Trigger once instances were actually in the parent before, but they still did nothing so I moved them to see if they’d change the reaction at all and it was the same either way. I did try to a tween check once before, I think I had it set to look for the tween in action and tried to stop it from taking a second request before the first finished but that didn’t have any effect. I suppose I could have done it wrong, but there wasn’t anything to say “Hey doofus, this isn’t doing anything.” I feel like a lot of my problems are stemming from not knowing what some of the commands are capable of and when I want something specific not knowing where they are to even be able to plug them in. and then flailing around moving things into different positions of the stack to get a different reaction in the hope that I’ll at least learn something if the change breaks it horribly.
I tried to have the fade destroyed or at least the timer after it reached the desired opacity, before that I tried destroying the timer after the desired amount of time passed but I hadn’t gotten the actual animated fade to work at the time so it would just wait 3 seconds and pop to clear. I did consider a tween for opacity but could never find the exact method to do it. No search result other than the one from years ago came up when searching for fading or opacity change over time, the video tutorials only seem to reference shifting to different tints.
I’ll try to match what you said in my next session. Hopefully that will be what I’m looking for. Also, another question do you think having a 24-32 page comic divided between a couple dozen scenes is better than the scrolling page method in a single scene, or is that overkill? I would imagine most games that use extra scenes probably don’t use more than a half dozen considering there doesn’t seem to be a more practical way to switch between them in the interface besides clicking on the tabs, and also comparing the way Panoply does it with steps and interpolation to this idea feels like using a monster truck to tow a smartcar.
Personally, I think it’s overkill. A scene per chapter, yes, but not a scene every couple of pages. I’ve worked with another dev on a story book like what you’re doing; it was a good 20 pages per scene which worked really well.
Yes! I was eager about the fade so I tried that first before your first suggestion It took a bit of trial an error to find (I didn’t even know this particular tween existed) but this version seems to work exactly the way I was hoping for! Thank you so much for that! I did discover that if I just added this without telling it first “at the beginning of the scene” it just waits 4 seconds and then pops to 0 opacity. So it needs to have some sort of condition.
I modified it a bit after, I thought I might need to give the darkness a moment to build tension at some point so I adjusted the timer like this:
So now it creates the timer, waits 3 seconds and then commits the tween and then should destroy the timer after the opacity change is complete so it’s not still counting after the fact…right?
Also thanks for the incite on the use of Scenes. Now that you mention it, it probably works better to hold on to scenes for actual narrative scenes within the book. It occurs to me now this might make it easier to create “bookmarks” with a table of contents screen for readers rather than having to flip through every page to get to a particular part of the book, which also gives me more control of UI elements than I had with Panoply. I’m still confused where my CamTarget runs off to when I click for the next page, but I will try your suggestion for stopping the double click problem next.
Can I ask which book you helped on so I can compare? (I did run across a children’s book posted here recently before I signed up to the forum, was that it?) It’s weird that I didn’t see more people trying to use Gdevelop for digital book or magazine creation when I first started exploring the idea, almost made me feel like this idea was something of a Jerry rigged hack.
That’s the way it appears, but it’s really tweening over 4 seconds, by the end of which the opacity is 0. The easing function plays a bit role in this. It describes how the value of the tween changes over time. Here is a list of easing functions.
Yes, that’s how it should go. BTW, you can put the 2 actions (create tween and delete timer) in the same event.
It was Ava’s Destiny. Unfortunately I don’t have the source code for it any longer. However, it was a simple concept to implement.
Each scene reperesented a chapter, and each page was an image. All images were the same dimension, and were laid side by side from left to right.
I had 2 sprites, firstPage and lastPage, to act as first and end page marker. firstPage was positioned a bit to the right ot the first image centre, and lastPage was positioned a bit to the left of the last image centre.
I had a cameraFocus object, which moved a page image width at time . It would move left if the previous page image was clicked on and the cameraFocus.X() was greater than firstPage.X().
Similarly, camerafocus would move right if the next page image was clicked on and the cameraFocus.X() was less than lastPage.X()
That list of easing is incredibly helpful, thanks!
I’ll keep that in mind, I think I’m just paranoid that the engine wouldn’t understand so I tried to keep those actions distinct.
I’ve been trying to follow you instructions on stopping the double click problem, but I’m clearly misunderstanding them. I’ve tried several iterations of it adjusting the positions of the commands and either it didn’t change or the page doesn’t move at all when the buttons are clicked. In this current version the page only moves a few pixels at each click, and I’m not sure what I’m doing wrong. (also I tried to include a condition to keep the page from reversing past the first image into a blank area, which seems to work until I tested the the double click issue and then it skips the barrier I set up.)
I’m starting to wonder if maybe there’s another way to do it rather than tweening a set number of pixels with each click, like pacing an image target in the center of each page image and having the camtarget stop when it touches.
It definitely sounds similar to what I’m trying to do, I’m surprised it didn’t show up at all in my searches. I should try to download it and give it a look when I can get my android testing device working. Unless you know where I can find a PC version.
Let me first say how much I appreciate your help on this, and your patience with my failures in working my way through this. I think I did have most of that and when something I entered wrong didn’t work I must have deviated and left out a bunch of stuff while flailing around trying to figure it out, and then added more complication on top of that before figuring out the previous issue.
Okay, I followed what you did exactly and the double click is finally solved! Not only that, but it has the added benefit that holding the pageleft control ontinues to flip through the pages to the end rather than having to click constantly which might be more favorable for reader comfort. I’m going to have to seriously study this now to understand how it works, Because I don’t understand the context of inverting the condition checking to see if the tween exists. Is it like saying “Check that it doesn’t already exist?”
As for the conditions you suggested as a barrier to stop the CamTarget from goiing beyond the first and last pages into the blank area, it works… and it doesn’t. I mean It’ll stop if from going beyond the last page, but not the fist page, at least not until it’s already gone a full page width into the blank area and then it wont go any further, which is odd to me since the barrier to stop it before escaping last page works perfectly.
I did a bit more experimenting with the CamTarget while trying to come up with another end stop method. Originally, I gave it it’s own layer (this was so that I could keep everything compartmentalized and hide UI elements easily) and as you might recall I kept saying that when it tweened to the next page it just shot off somewhere seemingly beyond the range of view even though the camera landed where it should. While testing, I discovered that if it was just on the base layer it stayed in view of the camera at least as long as it was in a higher Z position.I suppose I could just make it a fully invisible sprite but maybe I’ll just keep it at the bottom of the Z order of the base layer for now.
As for the end stop method I guess I was just over thinking it:
This worked perfectly! I just grabbed the X position of the Camtarget (768 being the left edge of the 64x64 camtarget sprite in the center of the image) and said it simply can’t go left if it’s in that starting position. Although before that I did try putting up a literal wall sprite with the path finding obstacle behavior on it so if it started to move into the sprite it would have it’s tween stopped before being reset to the starting X position, but since the double click is solved there’s no way it can gain enough “momentum” for lack of a better word, to get beyond that point!
Where have you placed that firstPage object? It has to be slightly to the right of the first page centre. And the CamTarget has to start off in the centre of the page.
Ugh, I see, that’s my mistake yet again. Like an idiot I assumed you were using placeholder names for my existing pages/objects. So I just substituted the names of the actual first and last pages rather than creating new objects to act as the endstops. Looking at it now with new context I think get what you did: It’s restricting the movement of Camtarget to only If it’s between the firstpage.X and the lastpage.X, correct?
My CamTarget always started in the center either way (atleast according to the 32x32 grid,) but I guess the way my mind works is that it shoudn’t even see the light of day outside of the zone of restriction, which is why my version is set before CamTarget’s starting position. So if I’m understanding it in your version, CamTarget has to pass through firstpage.X to keep going right and loses it’s “permission” to move once it gets beyond the center of lastpage.X, but wouldn’t that cause the last page to be slightly off center if the Cam target has to past through lastpage.X to stop… or should it stop immediately on contact?
Pretty much. It can only move left if it’s to the right of firstPage.X, and only move right if it’s to the left of lastPage.X
No, because the firstPage and lastPage objects are slightly off centre. In the image below, the orange X’s are the centre of each page or the spots to which CamTarget tweens.
The purple square is the firstPage object, the purple triangle is lastPage object.
When CamTarget get to position A, it’s X position will be less than that of the firstPage object, and so won’t be allowed to go further left. Ditto for position B, but with the lastPage marker and not being allowed to go right.
(I’m probably over describing this, but it’s for the benefit for others who may read this and hopefully may explain it a bit better).
No doubt, I hope any of this conversation helps another person later on. And I appreciate the over explaining as well, because as is clear I can miss stuff that should have been clear as day. This kinda stuff gets complicated real quick for a newbie.
Ultimately, I suppose there’s nothing inherently wrong with the way I did the endstop, as long as CamTarget stops where I need it to every time it’s still reliable. Your version would work far better than mine for a game with a great deal of fluidity to the camera, but since I’m directly controlling every pixel that goes into the book I should be able to stop it exactly on a dime now. At least I’ll have your version for reference if it breaks further down the line or on another platform… Thinking about it for another second, I should probably try build your version out for myself tomorrow, just to have another tool in the experience box regardless and I’ll let you know how it goes!
Okay I’ve done it exactly the way you did and I think it’s helping to understand that the inverted conditions are saying what I think they are. I think I have the most trouble when I can’t convert “code speak” into English. If I know what the code is saying I can sort of understand why it’s doing what it does.
That is to say: When you invert something that is a check for a condition, It becomes a check that that condition is not happening (or true), thus denying the action from occurring if that’s the case until it is happening. Correct?
With that I can say the code works, Although the graphic elements on the UI layer behave visibly different from what the code is telling it to do making it very confusing, which I can only assume is a visual bug is gdevelop. Like the CamTarget zooming off to never be seen again, the “firstpage” endstop object stays on screen the entire time rather than being left behind on the first page when the camera moves, and the “lastpage” object is never visible when you reach it. If I want to see it work as it should I can put the objects on the base layer, but since I don’t want it seen by the reader I can thankfully hide all of it on the UI layer and it all still seems to work even if it’s doing weird things when I’m not looking.
I think with that, I can finally start laying out the comic as an single contained app! I seriously appreciate all the help you’ve given me, MrMen. Thank you, once again. Hopefully I wont need to use your valuable time again too soon… but I probably will need your, or someone else’s, help again when I start getting more ambitious.
I mean, it’s the same Event list you provided, the only difference is the one blank condition in the beginning to lock the camera to the CamTarget. As I said, it only does it when the objects are on the UI layer. When visible on the base layer they move exactly as I expected.
The objects shouldn’t be on the UI layer - leave that for the Rbut and Lbut objects. Using layers and cameras is pretty neat when it works, and can produce some weird behaviour if things go a bit wrong.
Given it’s working fine when the objects are on the base layer, we’ll leave it there. Don’t fix what ain’t broke.
