Walkabout Engine

[DaFool]

Continuing the discussion from the RPG battle engine thread:

http://lemmasoft.renai.us/forums/viewto ... f=8&t=4159

I'll try not to hijack the battle engine thread any more with walkabout engine discussion, and I know I couldn't get my hopes up too high nor demand things from people coding in their free time, but can the following features be addressed:

* Secret Items - basically, on the map secret treasures are scattered (semi-randomly but must be accessible to the terrain of the picture, i.e. can't be placed on the rooftop of a house) which may or may not give off a tiny little sparkle when you walk close by. The player can either pick them up directly into the inventory like other items on the walkabout map, or else have a separate 'Dig' command.

* Small imagemap-like animations - like door closing / opening, lever activating, etc.

* Semi-randomized dungeons - probably use some elements of a tile engine? I'm wondering if this would be hard to implement, especially if it will really bog down the system if it has to process all the displayable map pieces as off/on per tile.

[Midnighticequeen]

sounds amazing already

[Neon Lemmy Koopa]

I can see how a walkabout engine would dramatically improve a game.

Unfortunately Im not any good with Python. Java's my thing.

But this would be nice to see.

[monele]

Curious : top view, side view, isometric? Also, what are you asking exactly? "Can this be done?" or "can you do this for me?"

[jack_norton]

I think the most useful would be side view, SCUMM style. One of the simplest method is to use a polygon to define the terrain and then do Astar algorithm to pick the closest free spot when user clicks on a object in the scene (which can be rect hotspots I think).
With such add-on + existing first person dialogue option, renpy would be able to make full adventure games. Definitely would rule if someone makes such extension.

[herenvardo]

I'll try not to hijack the battle engine thread any more with walkabout engine discussion

Well done. When a side topic arises in a discussion, it's often difficult to know when to branch it out to a separate discussion; specially when the side topic is interesting and related enough.

* Secret Items - basically, on the map secret treasures are scattered (semi-randomly but must be accessible to the terrain of the picture, i.e. can't be placed on the rooftop of a house) which may or may not give off a tiny little sparkle when you walk close by. The player can either pick them up directly into the inventory like other items on the walkabout map, or else have a separate 'Dig' command.

From what Aenakume has already given away on different threads, I'd bet that the "event" hooking will be flexible enough to allow for that, and more. You might need to code some stuff related to these secret items by yourself; and maybe even the "dig" command itself. (BTW, this reminds me of HoM&M; and I think a HoM&M-clone (up to IV, V went nuts with 3D graphics) might be doable ).

* Small imagemap-like animations - like door closing / opening, lever activating, etc.

You should better wait for an "official" response from Aenakume, but I don't think the engine will need to assume that the displayables it's using are static images; so animations could probably work fine. Keep in mind that this is just my own speculation.

* Semi-randomized dungeons - probably use some elements of a tile engine? I'm wondering if this would be hard to implement, especially if it will really bog down the system if it has to process all the displayable map pieces as off/on per tile.

Fully-random maps (regardless of if they are dungeons or outdoors), with only predefined, hard-coded constrains (such as "rooms must be at least 2x2 tiles" or "can't have 3 consecutive wall sections with doors") are fairly easy, almost trivial.
Map-randomization with flexible constrains ala Diablo II, however, is not that easy. I've done several attempts to implement something like it with no success at all. I'll keep trying, however, since I still have some hopes to get such a feature in FoJ. Also, keep in mind that the dungeon randomization is mostly independent from the engine itself: once you have a code (probably a function) that can produce a random dungeon, it should be quite simple to pass it on to any engine, such as the walkabout engine, my dungeon-management routines, or anything else.

Unfortunately Im not any good with Python. Java's my thing.

If you check the conversation linked by DaFool, you will notice that we are talking mostly about the engine Aenakume is already working on. Of course, you might need some python to use that; but the main point of an engine is that it will do the "dirty work" for you. And, on top of that, according to python.org's homepage, python can be learnt in just a few days .

Curious : top view, side view, isometric?

Until know I've been thinking of it as a top-view, like in RPGM; but I really have no idea of what Aenakume has in mind. I just hope we don't get another isometric-only engine, since we already have chronoluminaire's Tile & Unit Engines (which might probably work as a walkabout engine if a single unit is used).

[Aenakume]

Continuing the discussion from the RPG battle engine thread:

http://lemmasoft.renai.us/forums/viewto ... f=8&t=4159

I'll try not to hijack the battle engine thread any more with walkabout engine discussion, and I know I couldn't get my hopes up too high nor demand things from people coding in their free time, but can the following features be addressed:

Hey, no worries. ^_^; Once i get it barely functional, i'll probably post what i have here and let people chip any upgrades or features.

* Secret Items - basically, on the map secret treasures are scattered (semi-randomly but must be accessible to the terrain of the picture, i.e. can't be placed on the rooftop of a house) which may or may not give off a tiny little sparkle when you walk close by. The player can either pick them up directly into the inventory like other items on the walkabout map, or else have a separate 'Dig' command.

Yup, this should already be possible with what i've got under construction so far. There are a couple parts to this question, so i think i should give you an idea of what it will look like when you make a walkabout scene.

First, you create a walkabout scene object. Then you add:

• images (technically displayables, so they can animated), giving each a string name (optionally, you can leave it blank) and a layer number
• characters, which are the same as images except they move around (one would probably be the player character)
• hot zones, which are defined by shapes (i give a base shape class and a bunch of shapes to work with - so far rectangle, circle, arc (part of circle, like a pie), and polygon (arbitrary n-sided polygon), all are partially working now, but don't count on all of these actually being in the final engine, because... eh, well that's a long story, so don't worry about it ^_^)
• no fly zones, which are technically hot zones with a special event function that makes it ignore clicks (so if you click in a no fly zone the character doesn't move) and blocks any character from entering (with some options, so not all characters have to be blocked, like if you want a bird character flying around).

Then you assign your scene to a walkabout object, and it's displayed and runs.

So! For a secret treasure, what you'd do is create a hot zone with maybe a circle shape around the point where the secret treasure is. The on_character_enter() function for that zone will display your sparkly displayable when the character enters, and hide it when the character leaves.

To get the treasure, you can do one of two things:

1. Make a smaller circle hotzone inside the big one, that when you enter that you trigger a function that gets you the treasure.
2. Make a smaller circle hotzone or use the big one, that when you click in that zone while the character is in the zone, calls a "dig" function that gets you the treasure.

As for seeding the random treasures around the scene - and makin sure they don't land in no-fly-zones... that's up to you. ^_^; But it shouldn't be too hard - just generate random points and make sure none are in any no-fly-zones by using those zones' point_is_in() function.

* Small imagemap-like animations - like door closing / opening, lever activating, etc.

Easy-peasy. Every image is a displayable... which includes the condition switch displayables. So you could (and this is just one way to do it) make a condition displayable that shows a closed door if some variable foo is False, and an open door if it's True... then make a hot zone in front of the door that sets foo to True when the character enters and False when they exit. Same general idea for lever pulls - make a hot-zone that responds to clicks, and if the character is close enough, do something to play the lever animation.

Now... at the moment the walkabout engine isn't gonna support mouse hover events... but maybe that can be added once it's up and running? Possibly, i think so.

* Semi-randomized dungeons - probably use some elements of a tile engine? I'm wondering if this would be hard to implement, especially if it will really bog down the system if it has to process all the displayable map pieces as off/on per tile.

Hm... possible... but as you say, it's not really designed for that. That seems more the domain of the tile engine in the cookbook.

Buuuut... since Ren'Py already caches images so well, it shouldn't be that much bogging down. When you set up your scene, you just add your tile displayables like any image. You'd have to ask Py'Tom what will happen with animated displayables (will they all animate in sync, or at different times?) and if and how that behaviour can be changed.

Curious : top view, side view, isometric?

Depends on how you make your images. ^_^;

I think the most useful would be side view, SCUMM style. One of the simplest method is to use a polygon to define the terrain and then do Astar algorithm to pick the closest free spot when user clicks on a object in the scene (which can be rect hotspots I think).

SCUMM was my inspiration for this, actually. But technically even the SCUMM engine could do any one of top-down, side-on or isometric... it just depends on your images and how you lay your scene out.

There will be no A* by default... although once the engine is done it could be added as an add-on, and it shouldn't be too hard - there's only one gotcha i can think of, and if it becomes a major issue, i can make a hack (in fact, i might have to do that anyway, for other reasons). Characters move in straight lines to whatever point you click (or whatever point they're set to move to in code). If they bump into a no-fly-zone, they stop (by default). That means the terrain is not defined by a polygon - but the other way around, the areas where you can't go are defined by polygons (or other shapes).

With such add-on + existing first person dialogue option, renpy would be able to make full adventure games. Definitely would rule if someone makes such extension.

Yes, i am that awesome.*

* If and when i get it finished.

[Aenakume]

Some screenies. Nothing spectacular, but at least you can see something. The happy face is the "character" walking around where i click.







Code looks like this:

Code: Select all

the_scene = WalkaboutScene()
the_scene.add_image("fond.png")
the_scene.add_image("arbre.png", position=(220,0))
the_scene.add_main_character("moi", "moi.png", position=(100,400))

ui.add(the_scene)
ui.interact()

Please note that none of this represents what the code will look like for the final product. ^_^; It can change a lot.

Oh, and i'll do everything in English and not Frenglish from now on, so everyone can understand what everything is. For now, the first line adds the background, the second adds the tree, the third adds the main smiley character. Oh, and since they're all on the same layer (layer 0, set by default), they draw in the order they were added, so the happy face goes over the tree (shoulda shown that).

[monele]

Et ceci n'est pas une pipe (meep, french!)

I commend the very small amount of script needed for this

[DaFool]

Yay!

I'm assuming the smiley character would be able to "walk" in the future by using a walk cycle animation depending on the direction it's going? (Maybe not everyone may be able to create a walk cycle, but perhaps something simpler like the 8 bit ones).

Also, I'm assuming your art needs are taken care of? At least for testing purposes. I'm tempted to volunteer but maybe the best gift can be to make a good game using this engine, and open source the assets so people can expand the quests or at least use them to test the functionality of their games.

[Aenakume]

I commend the very small amount of script needed for this

Ha! Small amount of script for you the user. For me... lots of scripty. ^_^;

I'm assuming the smiley character would be able to "walk" in the future by using a walk cycle animation depending on the direction it's going? (Maybe not everyone may be able to create a walk cycle, but perhaps something simpler like the 8 bit ones).

Technically the smiley could walk now. ^_^

Right now, the way to do something like this is up to you, not the engine. There are lots of ways you could do it, i guess, but what i'd do is make a ConditionSwitch displayable for your main character (in my example code above, i just used a plain image). To make my main character, instead of the shortcut function above, i'd do somethin like this:

Code: Select all

main_char = WalkaboutMainCharacter("moi", main_char_displayable)

...

# instead of the_scene.add_main_character(...)
the_scene.add_object(main_char)
the_scene.set_main_character("moi")

To make the main character displayable, you'd do:

Code: Select all

main_char_displayable = ConditionSwitch(
    "not main_char.is_walking()", "standing_still.png",
    "is_going_left(main_char)",   walking_left_animation,
    "is_going_right(main_char)",  walking_right_animation,
    "is_going_up(main_char)",     walking_up_animation,
    ...
)

# With helper functions like
def is_going_left(char):
    heading = (char.target[0] - char.position[0], char.target[1] - char.position[1])
    return heading[0] < 0 and abs(heading[0]) > abs(heading[1])

If it seems like a lot of work, there's a reason it's not natively part of the engine right now. The problem is i don't know if you're gonna want two different animations (left/right), four (l/r/u/d), eight (for eight-way movement) or infinite (you rotate a sprite or generate it on the fly using the angle you're walkin at). i don't know if you're gonna zoom the character larger and smaller depending on the y coordinate of the position (to simulate movin closer and further in a pseudo-3d scene). i don't know if you're gonna want to have different character sprites for if you're in normal state, or after you've had a mushroom or a fire flower, or a star of invincibility. i don't want to build into the engine something like that and limit the possibilities right off the bat.

Instead, there will be a bunch of helper functions in the engine (like is_going_left()) to make this relatively painless. And once the engine is up and running, i'm gonna make some cookbook articles with sample code to show how to do stuff like this. So in the end, if what you wanna do is somethin i thought of, you can copy-paste code from the wiki... but if it's something new and unique i didn't think of, you're on your own, but at least you'll have lots of sample code to guide you.

Also, I'm assuming your art needs are taken care of?

Why? What's wrong with my art?

I'm tempted to volunteer but maybe the best gift can be to make a good game using this engine, and open source the assets so people can expand the quests or at least use them to test the functionality of their games.

Hey if you want to be the guy to make a sample game to include in the engine's distribution archive, i say go for it. ^_^ When the engine's done, i'll send it to you first, and you can be the first victim guinea pig beta tester winner!

[PyTom]

Ha! Small amount of script for you the user. For me... lots of scripty. ^_^;

Welcome to my world.

A couple of design ideas:

- It seems a little complicated to have a WalkaboutMainCharacter class, and then also set the main character. It might make sense to haver a single WalkaboutCharacter class, and maybe set main=True as part of the add_object call.

- I'd even go one step further and have add_object call the constructor and return an instance. That prevents people from inheriting from WalkaboutMainCharacter, and doing things with it you didn't intend. (People who want to wrap it can always make a proxy class.)

- It might make sense to add convenience attributes or properties to the WalkaboutCharacter class. Having walking and angle properties would let the user write something like:

Code: Select all

main_char_displayable = ConditionSwitch(
    "not main_char.walking", "standing_still.png",
    "main_char.angle < 45 or main_char.angle >= 315 ",   walking_right_animation,
    "45 >= main_char.angle < 135",     walking_up_animation,
    "135 >= main_char.angle < 225",     walking_left_animation,
    ...
)

In Python, properties are usually better than getter/setters. Especially getters.

[DaFool]

Great! Expandability and flexibility are good. I was originally thinking about only 3 animations: Left-Right animations (basically, flipped versions of each other), Walk towards / down, and Walk away / up. But it's good to be able to potentially include 45 degree walk cycles as well (not that I know how to do that).

Also, I'm assuming your art needs are taken care of?

Why? What's wrong with my art?

I'm tempted to volunteer but maybe the best gift can be to make a good game using this engine, and open source the assets so people can expand the quests or at least use them to test the functionality of their games.

Hey if you want to be the guy to make a sample game to include in the engine's distribution archive, i say go for it. ^_^ When the engine's done, i'll send it to you first, and you can be the first victim guinea pig beta tester winner!

If your art is like your avatar, then you're more than capable. But of course I don't expect anything but unpolished placeholders for the framework. Because once I start playing with it, it's hard to hold back since my tendency is to want to go full-blown in presentation. So while I'm at it, I might as well create a complete game so it'll be worth to more people than just programmers. As to why I'm so eager about this, is because I see this the type of hybrid game that will be easier to complete (versus the 2D racing sim for instance).

Do you have any constraints for the graphics specifications(such as resolution), or is it safe for me to start creating some backdrops in whatever expandable resolution? (I would say 'right now', except that I'm currently addicted to playing Sacred 2)

[Aenakume]

Ha! Small amount of script for you the user. For me... lots of scripty. ^_^;

Welcome to my world.

i knew i had entered there when i heard that snapping sound in my brain.

A couple of design ideas:

- It seems a little complicated to have a WalkaboutMainCharacter class, and then also set the main character. It might make sense to haver a single WalkaboutCharacter class, and maybe set main=True as part of the add_object call.

There's a WalkaboutCharacter class that handles "move_to" commands - which takes a target position and then slowly moves from the current position towards that target. The WalkaboutMainCharacter class comes from that and adds the logic to handle the clicks (it takes a click and does a move_to). You'd use _Character for NPCs and _MainCharacter for your main character(s) normally. The reason there's a separate "set_main_character()" is because you can have two _MainCharacter people, and switch between them with set_main_character().

So imagine you create a dungeon map and put 4 characters on it made from _MainCharacter (along with a bunch of NPCs using _Character) - and on the side of the map there's 4 buttons to switch between the characters.

Code: Select all

the_scene.add_object(WalkaboutMainCharacter("Fighter", "fighter.png"))
the_scene.add_object(WalkaboutMainCharacter("Black Mage", "bm.png"))
the_scene.add_object(WalkaboutMainCharacter("Red Mage", "rm.png"))
the_scene.add_object(WalkaboutMainCharacter("Thief", "thief.png"))
the_scene.set_main_character("Fighter")

# And when you click the "Black Mage" button
the_scene.set_main_character("Black Mage")

Whichever one is the current main character moves towards clicks... the rest just wait (by default). You can use this for puzzles where multiple characters have to contribute cooperatively, for example.

Course, if you just plan on havin a single main character, it's just easier to use add_main_character construct the WalkaboutMainCharacter class internally, and set everything up right. And if i use the next idea, there's no longer any reason not to do things that way unless you want multiple main characters... or you just want to make your life difficult. ^_^;

- I'd even go one step further and have add_object call the constructor and return an instance. That prevents people from inheriting from WalkaboutMainCharacter, and doing things with it you didn't intend. (People who want to wrap it can always make a proxy class.)

Having the add_* functions return instances is brilliant. That cuts the amount of code to do what DaFool was askin about by almost 70%.

Code: Select all

main_char = WalkaboutMainCharacter("moi", main_char_displayable)
the_scene.add_object(main_char)
the_scene.set_main_character("moi")

# becomes...

main_char = the_scene.add_main_character("moi", main_char_displayable)

But why wouldn't i want someone to inherit from WalkaboutMainCharacter? i mean... i can't think of a reason why they'd want to offhand - but i definitely expect people to inherit from WalkaboutCharacter. To make a patrolling sentry NPC for example, they'd inherit from WalkaboutCharacter and change the on_update() function to move_to() the next sentry point when they get to the current point or maybe a few seconds after (that might change - i'm thinkin of adding an "on_arrival()" function that gets called when a "move_to()" completes). Oo! i just thought a reason you might want to inherit from WalkaboutMainCharacter - if you're doing that 4-person thing from above, you can have a custom WalkaboutMainCharacter that makes them stroll around a bit if they're not the main character for a while.

- It might make sense to add convenience attributes or properties to the WalkaboutCharacter class. Having walking and angle properties would let the user write something like:

Code: Select all

main_char_displayable = ConditionSwitch(
    "not main_char.walking", "standing_still.png",
    "main_char.angle < 45 or main_char.angle >= 315 ",   walking_right_animation,
    "45 >= main_char.angle < 135",     walking_up_animation,
    "135 >= main_char.angle < 225",     walking_left_animation,
    ...
)

In Python, properties are usually better than getter/setters. Especially getters.

Ya, that sounds good. i'm learning Python as i go and i only recently discovered @property. i could replace:

Code: Select all

def is_walking(self):
    return self.target is not None

# with

@property
def walking(self):
    return self.target is not None

A similar idea for an angle property would also come in handy.

Great! Expandability and flexibility are good. I was originally thinking about only 3 animations: Left-Right animations (basically, flipped versions of each other), Walk towards / down, and Walk away / up. But it's good to be able to potentially include 45 degree walk cycles as well (not that I know how to do that).

Yup, i'm big on makin everything possible. ^_^; For basic situations - like what you want (which sounds like 4 animations to me: standing facing left, standing facing right, walking left/up, walking right/down) - there'll be sample code to make things copy-paste easy. And for more advanced situations, you can customize.

If your art is like your avatar, then you're more than capable. But of course I don't expect anything but unpolished placeholders for the framework.

Wait... are you callin my tree an "unpolished placeholder"? *hefts crowbar, Gordon Freeman style*

Because once I start playing with it, it's hard to hold back since my tendency is to want to go full-blown in presentation. So while I'm at it, I might as well create a complete game so it'll be worth to more people than just programmers. As to why I'm so eager about this, is because I see this the type of hybrid game that will be easier to complete (versus the 2D racing sim for instance).

i suppose you can pretty much make a whole game with the walkabout engine. ^_^; That's... a bit more than i was intending... but i don't see why it's impossible... yet. i just intended to use it for really sexy menu choices in a VN or dating sim.

Do you have any constraints for the graphics specifications(such as resolution), or is it safe for me to start creating some backdrops in whatever expandable resolution? (I would say 'right now', except that I'm currently addicted to playing Sacred 2)

Nope, no constraints at all - everything is an arbitrary displayable: an image, an animation... whatever. But... i don't know if you want to rush into this. ^_^; It may not be ready for you until Sacred 8.

[PyTom]

But why wouldn't i want someone to inherit from WalkaboutMainCharacter?

Future-proofing. Say I inherit from WalkaboutMainCharacter, and add a field called speed. Then in release 2 of your engine, you also add a field called speed. This is Python, so there's a conflict.

I also think that, in general, callbacks are easier to understand than inheritance, at least for people without much training.