Lemma Soft Forums

I can totally imagine something like that =D

I like the chest idea, that could be another Scenery item or tile behaviour. =)

DaFool wrote: I think, though, that map scrollability should be prioritized, then everything else will have more appeal.

I tend to agree, so I'm working on it right now. I'm going to have to put a bit of thought into how best to construct the Displayable/s for large battlefields, though.

On a related note, do you have any ideas about how you'd prefer a panning UI to work? I mean, I don't think Ren'Py allows one to retrieve the mouse coords that the user clicks on a button (or whatever) with, so RTS-style mini-map navigation wouldn't be easily doable... a set of buttons around the edge of the screen for scrolling, or a d-pad in the (say) top-right corner would be doable, as would a pair of scroll bars. The concern I have is that I don't think I can easily use a Ren'Py viewport, because you have to add its child Displayables when you construct it and only one of them (the battlefield itself) will be known at that point, so unless I'm missing something I'll have to roll my own.

Can arrow keys be used for panning?

I think onscreen scrollbar buttons will work, but like iPhone apps tend to be cumbersome.
Maybe take a cue from 3D engines and have a custom "camera" viewport that can be configured to track the currently selected fighter or enemy. It can also be used to illustrate current battle conditions, ie the triumphant return of a super weapon in the corner of the map.

That means that everyone has to adhere to a standard grid unit so you can calculate how many tiles to the left/right or north/south of the current target should be drawn. I know it's different from the tile/unit engine that was able to use a viewport but in our case we might still need a Boolean to Display /or not so we can draw only a portion of the map. I don't know if this made sense.

DaFool wrote:Can arrow keys be used for panning?

Hmm. On one hand, it would certainly be possible, and would avoid the need for further UI elements.
On the other hand, I don't know whether it would be so intuitive; bear in mind that presently, it's possible to play the entire thing with the mouse.
On the third (and probably more relevant) hand, the arrow keys are already used if you play with the keyboard for selecting menu items and hotspots (which reminds me, I should really try and remember to add a hover state to the move 'gem' button...), and it would be a little confusing and annoying, I think, to have the camera panning around as you tried to select where to move to.

DaFool wrote: I think onscreen scrollbar buttons will work, but like iPhone apps tend to be cumbersome.

I was also wondering about just stretching buttons across the whole edge of the window and using the hover event to move the viewport, so the user just has to move the mouse to the edge of the screen to scroll a bit.

The potential problem that I'm most worried about at the moment is what to do with panning versus parts of the battle UI being visible; that is, if there's a load of target buttons on-screen for selecting the target of an attack, what happens when the user scrolls? I'm concerned that either the buttons will be left in place, or the whole context of that attack menu will be lost when the battle redraws itself in a new position, either of which is pretty bad.

DaFool wrote: Maybe take a cue from 3D engines and have a custom "camera" viewport that can be configured to track the currently selected fighter or enemy.

This is basically the lines I'm working along; the battle itself has a 'CameraX' and a 'CameraY', then I'll have a few Extra classes which move the camera around in different ways.

DaFool wrote: That means that everyone has to adhere to a standard grid unit so you can calculate how many tiles to the left/right or north/south of the current target should be drawn. I know it's different from the tile/unit engine that was able to use a viewport but in our case we might still need a Boolean to Display /or not so we can draw only a portion of the map. I don't know if this made sense.

I'm not sure I follow that at all, I'm afraid...

The engine knows how big a grid square is in the user's implementation, and how big the screen is, so it's theoretically plausible to check tiles which are off-screen and not draw them if they're not going to be shown. But this would require rendering every sprite which was in an off-screen tile into a Render to find out how big it is and thus whether it needs to be drawn so it can be seen poking on the edge of the screen, which means you're not saving any time. (It's not a value which can be kept, because sometimes those sprites will be animated and have different-sized frames, and under some battle conditions they'll change state and might have a completely different Displayable with a different size).

On the other hand, PyTom tells me that Ren'Py at least tries to work out whether it needs to display a given Displayable or whether it's off-screen and behave efficiently, and I don't have any reason to believe it would do it worse than I would, so I was just going to leave it to Ren'Py.

a set of buttons around the edge of the screen for scrolling, or a d-pad in the (say) top-right corner would be doable

I don't know what a D Pad is, but I'm down with the buttons solution. Navigating with keyboard arrows is cool, but not as obvious as the buttons. Or maybe we could have both, the keyboard arrows mapped to the buttons ?

That means that everyone has to adhere to a standard grid unit so you can calculate how many tiles to the left/right or north/south of the current target should be drawn.

Sorry but I think that'd be a shame =D I'm currently working on a grid unit four times smaller than the one Jake used in order to have a bigger grid. I love the fact that one can customize relatively easily things like that.

blakjak wrote: I don't know what a D Pad is

The cross-shaped directional button on a game controller is known as a 'd-pad'; short for 'directional pad'. I guess it's a 'pad' rather than 'buttons' because they're usually made from a single piece of plastic that rocks from side to side rather than separate 'left', 'right', 'up' and 'down' buttons?

blakjak wrote: Sorry but I think that'd be a shame =D I'm currently working on a grid unit four times smaller than the one Jake used in order to have a bigger grid. I love the fact that one can customize relatively easily things like that.

Don't worry, I'm definitely not going to force a standard grid size, and since the Battlefield class knows how big the grid square is, it's unnecessary! ;-)

Oh so that's a D pad ! =D

Then yep, I think D pad is even better than buttons.

Don't worry, I'm definitely not going to force a standard grid size, and since the Battlefield class knows how big the grid square is, it's unnecessary!

Ok cool =)

Just thought of something, I didn't see any friendly AI, are you planning on adding it for non controllable NPCs ?

Jake wrote: The potential problem that I'm most worried about at the moment is what to do with panning versus parts of the battle UI being visible; that is, if there's a load of target buttons on-screen for selecting the target of an attack, what happens when the user scrolls? I'm concerned that either the buttons will be left in place, or the whole context of that attack menu will be lost when the battle redraws itself in a new position, either of which is pretty bad.

How about making pans auto-snap to the most adjacent grid? Then the camera "viewport" will merely be a position/translation relative to the larger map, and you can translate the location-dependent ui functions accordingly.

For example, you have a huge top down 12 by 12 grid and your focus is a 4 x 4 grid focusing on the top left. If the character range goes offscreen by 2 units right, for instance, then you auto-pan by 2 units right. In other words, allow panning controls by the user, but freeze controls and automate best-fit panning when things get crucial, ie target acquisition and execution.

blakjak wrote:Just thought of something, I didn't see any friendly AI, are you planning on adding it for non controllable NPCs ?

Actually, you should just be able to set up an EnemyFighter or MovingEnemyFighter and add it to the player's faction, and it'll work as a non-controllable NPC. There's nothing in the AI which makes it only work against player characters, it will target any fighter which isn't in the same faction as it. I should probably rename those classes 'AIFighter' or something. ;-)

DaFool wrote: How about making pans auto-snap to the most adjacent grid? Then the camera "viewport" will merely be a position/translation relative to the larger map, and you can translate the location-dependent ui functions accordingly.

The problem isn't working out where to draw the UI controls, because otherwise they'd never work when the view was panned - I've built understanding of the pan into the BattlePosition object, which is used to position everything battlefield-related, so I know where to draw stuff.

The potential problem is that (Scenario 1) when you get to (say) choosing where to move, the engine displays a collection of UI components and positions them with absolute screen positions which happen to line up with the positions of the allowed-move grid squares. If the user waits until the move options are on-screen and then pans the view, the pan button will change the camera offset and re-draw the battle, but that won't re-draw the UI components because they're not controlled by the battlefield, so those UI components will stay in the absolute screen position they were in before the pan and no longer make any sense.

Alternatively (Scenario 2), since I don't know how ui.interact will respond to other buttons elsewhere on the screen being clicked, it may return a value other than one of the valid values for the movement UI if the pan buttons are clicked while the movement UI is up... in that case, I can happily catch that condition and re-draw the movement UI as well, but I don't know 'til I try it.

If the first scenario plays out and the move buttons get off-set, then it seems to me I have no choice but to incorporate the movement buttons into every single one of the UIProvider's UI presentations, which should avoid problems with panning but will make new UIProviders more complicated and confusing to write.



Of course, the ideal answer would be that there's some way of adding to a ui.viewport after it's initially been drawn, but I didn't see one in the reference manual. I'll try the panning, and if I get scenario 1 then I'll certainly be digging about in the viewport internals before I go with a more-complicated solution.

Actually, you should just be able to set up an EnemyFighter or MovingEnemyFighter and add it to the player's faction, and it'll work as a non-controllable NPC. There's nothing in the AI which makes it only work against player characters, it will target any fighter which isn't in the same faction as it. I should probably rename those classes 'AIFighter' or something.

Off course ! I should've though about that >_<;

I've got a couple thoughts that came up while I was playing with the alpha :

- I had wondered how you managed to make the trees become transparent when a fighter was behind it, and back to opaque when none was. I then understood that you drew the tree both on the background and on the sprite that was added as Scenery on the same spot where it was drawn on the background.

So did you use any particular method to know where exactly to draw it on the background ? Did you first place it as a Scenery sprite and then made a screenshot ?

In case you'd go along with making destructible Scenery, this method wouldn't work anymore right ? Unless there could be an instance of the Scenery item sprite drawn on a Renpy layer that was both on top of the battle background and behind the fighters; and that could update its image or animation as the Scenery item sprite would update its state ( normal or destroyed ).

Also, I'm having a crash course in animated walking isometric sprites, and one of my examples are the Ragnarok Online sprites. I noticed on their
spritesheets, that they only have sprites for upper left and lower left movement, and that these are probably flipped horizontally at runtime. This method saves ressources. Could it be possible to have a type of movement automatically call a flipped version of a displayable ?

blakjak wrote: So did you use any particular method to know where exactly to draw it on the background ? Did you first place it as a Scenery sprite and then made a screenshot ?

Actually, I did it a really bad way around - I drew the whole BG with the scenery included without thinking of separating them out, 'cause I originally did the BGs for my ill-fated NaNo game, and the battle engine at the time couldn't draw scenery in front of the fighters.

Then I cut the tree and the tree-line at the front out from the BG (copied and pasted, then erased all the bits which weren't tree), added them as scenery objects (semi-transparent, as you noticed) and then just played with the anchor values until they lined up properly... ;-)

blakjak wrote: In case you'd go along with making destructible Scenery, this method wouldn't work anymore right ? Unless there could be an instance of the Scenery item sprite drawn on a Renpy layer that was both on top of the battle background and behind the fighters; and that could update its image or animation as the Scenery item sprite would update its state ( normal or destroyed ).

What I was planning was to add extra functionality to the Scenery class, so that you could set a flag and it would draw itself once opaquely to the BG layer, and then once to the Fighters layer with transparency... so you wouldn't have to bake the scenery into your background. Destructible scenery would be done with states on the scenery sprite (the same way as with Fighters; Scenery actually descends from Fighter), so once they were destroyed and had a new sprite, that sprite would then be the one that gets drawn to the BG and then with alpha.

blakjak wrote: Could it be possible to have a type of movement automatically call a flipped version of a displayable ?

That's a pretty good idea - I'll note it down on my to-do list!

I'll leave it as an option, though, 'cause it occurs to me that it wouldn't be so useful for - for example - a guy with a sword in one hand and a shield in the other... they'd flip hands when he walked in opposite directions! ;-) I expect there's a lot of cases - monsters, robots, maybe wizards who aren't carrying anything - where it could work well, though.






(On an unrelated note, I think I've worked out how to get panning working in a generic and unobtrusive way, so I might be able to make an Alpha2 release sometime early next week, with any luck.)

Jake wrote:Actually, I did it a really bad way around

lol ok =D

Jake wrote:What I was planning was to add extra functionality to the Scenery class, so that you could set a flag and it would draw itself once opaquely to the BG layer, and then once to the Fighters layer with transparency... so you wouldn't have to bake the scenery into your background. Destructible scenery would be done with states on the scenery sprite (the same way as with Fighters; Scenery actually descends from Fighter), so once they were destroyed and had a new sprite, that sprite would then be the one that gets drawn to the BG and then with alpha.

Oh yeah, that'd be perfect =)

Jake wrote:That's a pretty good idea - I'll note it down on my to-do list!

I'll leave it as an option, though, 'cause it occurs to me that it wouldn't be so useful for - for example - a guy with a sword in one hand and a shield in the other... they'd flip hands when he walked in opposite directions! I expect there's a lot of cases - monsters, robots, maybe wizards who aren't carrying anything - where it could work well, though.

Right, I didn't think about that. It seems that the way they do it, is that they draw the sword separate from the character. Maybe it would be possible to combine in a Livecomposite in Renpy ?

But you're right, it might become more cumbersome, especially if you have effects happening with different states or shadow casting.

blakjak wrote: Right, I didn't think about that. It seems that the way they do it, is that they draw the sword separate from the character. Maybe it would be possible to combine in a Livecomposite in Renpy ?

It's certainly possible - but I'd prefer to leave it out of the core engine, on the grounds that it depends a lot on what size, orientation etc. your sprites are. It stops working so well even if some of your guys are different heights or hold their arms differently, so it's not really a generic always-works solution.

That said, it could be worth providing an example or two of that kind of thing with uniform-size sprites...


(Speaking of uniform-size sprites I've been spending a bit of my time in the evenings trying to draw a walkcycle in an iso projection so I have some example sprites to test the movement animation with, but it's pretty difficult! Even leaving aside that animation isn't the easiest thing in the world to do in the first place... if I get so far as animating just one, I doubt I'm going to want to do any more, so I'll have uniform-size sprites by default. :3)