[Old] 1.0 Release Maps and Scripting

A discussion area for general design issues that staff would like detailed feedback on.

Moderator: Staff

Djinn_in_Tonic
Member
Posts: 67
Joined: Sun Aug 09, 2015 10:36 pm

Re: 0.1.0 Release Maps and Scripting

Postby Djinn_in_Tonic » Mon Aug 10, 2015 1:30 am

Roots wrote:Not easily, I'm afraid. We have no way to "zoom out" of a map in the editor or otherwise so you pretty much have to maximize the editor window and take a number of screenshots to get a full picture. Also I'm not sure what system you're working on, but the editor has only been compiled/used recently on Linux. To get it working on Windows or OS X will take some work. I might be able to help with building it on Windows, but OS X I have no ability to do anything about. (I'm a Linux developer).


Oof. That's going to make that a bit tricky: I'm running Windows, and don't have a Linux machine available at the moment. Ah well!
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Mon Aug 10, 2015 2:05 am

I'll work at getting the map editor running on Windows for you. I don't think it will be too terribly difficult, but we'll see. I'll get started on that in the next couple of days.
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Mon Aug 10, 2015 9:39 pm

Made a little progress on getting this working last night but I'm still not there. In the meantime, you should really watch this video I put together earlier this year. I spent a good number of months overhauling our map editor to make it easier to use, and put this video together to demonstrate its use.





On another topic, I'd like for us to talk about the run mechanic on maps. As you know, there's a stamina meter that the player consumes whenever they are running. On some maps this meter is either invisible or has an infinity symbol, indicating that the user can run without consuming stamina (used for places where there are no enemies and hence no reason to restrict the player's movement). Here's the idea behind the stamina meter and the run mechanic:

  • The running mechanic replaces the "Run/Escape" command commonly seen in battle in other RPGs. You can't run away from battles in Allacrost once you are in them. You can only run away while on the map (which makes maps a little more exciting to explore).
  • Currently enemies on the map are mindless drones that roam about (restricting to a specific area of the map usually). If the player approaches, the enemy detects it and moves toward the player.
  • We have the ability to script enemies so they don't do the "mindless roaming" and instead have other behavior. Maybe hiding in the shadows waiting to jump out, or patrolling an area.
  • Once the stamina meter is empty, the player must stop running to refill it. Holding down the run command with an empty stamina meter will not cause the player to run, nor will it refill the stamina meter.
  • Moving from stationary to walk, stationary to run, walk to run, or any other change in movement state happens instantaneously, both in graphics and in change in speed.

Here are the things I don't like, or feel like there's room to improve

  • You have to hold down the run button (the 'cancel' command, or D if using the default control scheme). Maybe we should change it so the user can tap the key to toggle on/off running?
  • I don't like what happens when the stamina is empty. Maybe there should be a minimum value it must reach (indicated by the bar being colored red) before the player can begin running again?
  • I'm wondering if we should add acceleration/deceleration to movement mechanics. Would that make map exploration/enemy dodging more fun or challenging? Or would it simply be annoying?
  • I find it annoying when I'm in a dungeon and there's no enemies around, so I want to run through an area (because why would I want to move slower than I have to?). So long passages usually consist of me running, walking while waiting to refill my stamina, running again, etc. Maybe there's a way we could "fast walk" that reduces stamina slower or something? I don't know. :shrug:
  • Maybe instead of having such a long stamina bar as we do now (gives around 5-6 seconds of running IIRC), we could change it so that it only gives the user a 1-2 second burst in speed. Then running would be seen less as a way to get from A to B faster and more of a "use this only when you need to get away"

Just some thoughts to dwell on.
Image
Djinn_in_Tonic
Member
Posts: 67
Joined: Sun Aug 09, 2015 10:36 pm

Re: 0.1.0 Release Maps and Scripting

Postby Djinn_in_Tonic » Mon Aug 10, 2015 9:47 pm

Roots wrote:You have to hold down the run button (the 'cancel' command, or D if using the default control scheme). Maybe we should change it so the user can tap the key to toggle on/off running?


I'd personally prefer the current functionality: I'd hate to lose all my Stamina because I forgot to toggle Sprint off. I'm not sure what the Sprint key currently is though: I'd suggest something very easy, like SHIFT (if that's not already where it's bound).

I don't like what happens when the stamina is empty. Maybe there should be a minimum value it must reach (indicated by the bar being colored red) before the player can begin running again?


A minimum of, say, 25-33% of the bar being required seems appropriate. I think that's a fairly elegant solution with enough use in other games that players will pick it up VERY quickly.

I'm wondering if we should add acceleration/deceleration to movement mechanics. Would that make map exploration/enemy dodging more fun or challenging? Or would it simply be annoying?


Given that our monsters don't have acceleration or deceleration (and our current movement lacks it as well), I'd avoid doing this. Given that Sprint is most useful for escaping monsters I'd also recommend against acceleration, as that makes it much harder to avoid being jumped on unexpectedly.

I find it annoying when I'm in a dungeon and there's no enemies around, so I want to run through an area (because why would I want to move slower than I have to?). So long passages usually consist of me running, walking while waiting to refill my stamina, running again, etc. Maybe there's a way we could "fast walk" that reduces stamina slower or something? I don't know. :shrug:


That's going to mean adding another key though, which I'm somewhat loathe to do. I think that use of Sprint is a fine use of Sprint...it just runs the risk of you being hit by a mob when you really don't want a fight.

[*]Maybe instead of having such a long stamina bar as we do now (gives around 5-6 seconds of running IIRC), we could change it so that it only gives the user a 1-2 second burst in speed. Then running would be seen less as a way to get from A to B faster and more of a "use this only when you need to get away"[/quote]

That's a much nicer solution, in my opinion. I also think this makes WHEN you use it a little more strategic, which is good -- you have to use it to dodge or gain distance, rather than just booking it away at top speed.
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Tue Aug 11, 2015 5:00 am

Djinn_in_Tonic wrote:I'd personally prefer the current functionality: I'd hate to lose all my Stamina because I forgot to toggle Sprint off. I'm not sure what the Sprint key currently is though: I'd suggest something very easy, like SHIFT (if that's not already where it's bound).


I think it feels better/more natural on a gamepad, but is slightly awkward on a keyboard. I'm not the only one that has complained about the "must hold to run" feature either. I think it's fairly easy to tell when you are sprinting versus when you are not, due to the fact that we have different sprite animations for run versus walk, and of course the movement speed is noticably different as well.

I don't like using specific keys for something that can't be remapped, and I also don't want the user to have to move their hands across the keyboard to reach the different keys (their hands should be able to be stationary and all standard commands should be within the reach of the fingers). Shift is within reach of the left hand (which is resting on the ASDF keys), so it's not entirely out of the question, but I don't want that key to only be used in map mode and only for running, so then we're back to the discussion of "what is the ideal default key mappings?", which we already have another open discussion on in another thread. So while I understand your reasoning for the SHIFT key, I don't like it. :disapprove:

A minimum of, say, 25-33% of the bar being required seems appropriate. I think that's a fairly elegant solution with enough use in other games that players will pick it up VERY quickly.

Given that our monsters don't have acceleration or deceleration (and our current movement lacks it as well), I'd avoid doing this. Given that Sprint is most useful for escaping monsters I'd also recommend against acceleration, as that makes it much harder to avoid being jumped on unexpectedly.

That's going to mean adding another key though, which I'm somewhat loathe to do. I think that use of Sprint is a fine use of Sprint...it just runs the risk of you being hit by a mob when you really don't want a fight.

That's a much nicer solution, in my opinion. I also think this makes WHEN you use it a little more strategic, which is good -- you have to use it to dodge or gain distance, rather than just booking it away at top speed.


I agree with everything else you said here. In the near future, maybe we could experiment with having less stamina (shorter total run time) and see how that works. We might need to adjust enemy speeds slightly if we find it very difficult to escape an enemy without a larger stamina meter.
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Tue Oct 06, 2015 6:47 am

In another thread Atypikal mentioned that he was willing to help out with map scripting. So I kind of want to outline here exactly what we need to do. This is somewhat difficult because we don't have any dialogue ready and the maps are still not fully complete. That said, we're not unable to do this work, but whoever does it is essentially going to be writing temporary dialogue and creating scenes (character movements, etc) without much guidance. As a reminder, this module of the game follows the story in the prologue chapter that you can read here. The chapter is not meant to be an instruction guide, but is rather a story that the game is based off of.

We currently have three scenes/maps from the prologue story more or less complete (the intro march to the cave, the cave, and the walk back to the city). What we need to finish are the remaining three map scripts:
  • Harrvah capital under attack by demons
  • Harrvah capital aftermath
  • Sand dock departure scene

All three currently have a working map file prepared, but need the scripting to be done. The first two are going to be large, and complicated scripts. The last one is much shorter and easier to do and is thus much easier for a new scripter to start on. Rather than give a very detailed guide of everything that needs to happen in these map scripts, I'm instead going to give a "storyboard" version of each major scene and piece of content. The scripter can start from there, and add in dialogue that matches well with what is in the prologue story.

Capital Attack
I'll be handling this one and have already gotten started on it.

1) Knights enter the capital to find it under attack by a demon force. After a brief dialogue, NPC knights move to engage in battle while the party is given the mission to go the castle and speak with the captain of the royal guard to receive further orders.
2) Party must make their way through the fire, fights, and chaos of the city streets. The main road is blocked off so the player has to go around side alleys to get to the castle. Enemy encounters along the way.
3) While ascending a staircase, Claudius gets cut off from Mark and Lukar by demons that appear from above. He is ordered to continue onward to find the captain.
4) Claudius makes his way to the throne room, which has become a battleground itself. There he sees the king about to be ambushed from behind, and rushes in to save him and engages the beast (boss fight)
5) After Claudius defeats the beast, the demons retreat back into the shadows from whence they came. The screen fades to black with a "3 Days Later..." message on the screen

Capital Aftermath
This is after the attack and sets up the motivation for the main quest, so its pretty important that this be done well. It follows right after the capital attack map script ends.

1) Player starts with just Claudius in the party. He is in his home (top right house in the village) with his family. Short monologue/dialogue about the results of the attack, the lives destroyed, etc.
2) Claudius needs to go to the knight barracks (in the castle) to proceed to the next main event. He can stop and speak with NPCs along the way, who are filled with grief and exhaustion and remark as such in their dialogues.
3) Claudius reaches the barracks and his former unit (the knights from the early part of the game). Once they all assemble, they march toward the throne room and listen to the king speak.
4) King gives a speech thanking the knights for their bravery (see prologue for dialogue here). As they are dismissed, he asks that Claudius stay for a moment longer.
5) King commends Claudius for saving his life. Reveals to Claudius the legend of the hero, and asks him to consider a mission to travel the world to find the hero and bring him to the king
6) Claudius agrees, and must return home to prepare for his journey the next day
7) Laila (Claudius' sister) hears him packing late at night and the two have a dialogue about what he is about to do. Screen fades to black
8) The next day, Claudius explains to his parents downstairs of his mission with Laila listening in. They agree to send him off later that afternoon
9) Claudius can roam the town once again. The gateway to the passage that is beneath the twin towers of the castle is opened, and Claudius can now go to explore the dock.

Yes, this is a long one with a lot of dialogue and scenes. Eventually we'll also want to add a NPC with a sidequest somewhere in here, but not for this release.

Sand Dock
This is where the game module ends. Once the player has access to this area, they can go here and talk to a NPC to set of a chain of events that will end the game.

1) Claudius can talk to the various NPCs on the dock.
2) One NPC is in charge of preparing his craft (sand glider) for him to begin making his journey. NPC asks Claudius "Are you ready to depart?" and if the player selects yes, the following scenes occur and the game ends
3) A small number of knights come to the dock to bid Claudius farewell, including Lukar (but not Mark). Short dialogue
4) Claudius' family bids him farewell (refer to dialogue at end of the prologue)
5) Screen fades to black with a "To be continued..." and after a short time returns to the boot screen.



One of the issues we have right now is that there is no way to tell a map to "begin" at a certain location/place. For example, the aftermath map will need multiple points of entry because the player can both begin it in Claudius' home after the attack, and it can begin from the top center of the map if the player enters it from the sand dock. We'll need a smarter map loading mechanism so that we can set criteria that get invoked when a map loads. I think being able to pass a simple integer to a map script's load function should suffice for now.
Image
Atypikal_Arkitect
Junior Member
Posts: 28
Joined: Tue Aug 11, 2015 1:57 pm

Re: 0.1.0 Release Maps and Scripting

Postby Atypikal_Arkitect » Thu Oct 08, 2015 9:14 am

The last one is much shorter and easier to do and is thus much easier for a new scripter to start on.

Dibs! :cool:
Atypikal_Arkitect
Junior Member
Posts: 28
Joined: Tue Aug 11, 2015 1:57 pm

Re: 0.1.0 Release Maps and Scripting

Postby Atypikal_Arkitect » Fri Oct 09, 2015 10:49 am

We got the editor working on Windows right? Was wondering if the changes have been pushed through? Am getting 'undefined reference' when trying to compile it. Maybe there are some changes I need to make to my local environment?

I guess the editor its probably not essential for scripting but very helpful.
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Sun Oct 11, 2015 7:36 pm

The editor isn't required for scripting, but yes it is extremely useful to have to figure out positioning, etc. I would say don't try to compile the editor yourself. Use the pre-compiled editor that should be in the package I supplied. I can't recall at the moment exactly how the editor got built, but I think it was through another process than what we normally use to build the game. Thankfully, the editor code is stable and there won't be any major features or incompatibilities added to it any time soon.


Feel free to ask questions if you're trying to script something but don't know how. And FYI: on the dock map there will be a single-person craft on the middle dock at some point, but we don't have the artwork for it yet. It will be on the right side of the dock and it can be reached by going down the ladder that's right around there. For now, just pretend that something is there. I don't think we'll want the scripting to actually show Claudius climbing down, getting in, and taking off with the craft (too much custom art required for that, and we don't have the resources to make that kind of scene right now).
Image
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: 0.1.0 Release Maps and Scripting

Postby nemesis » Mon Oct 12, 2015 6:47 am

Atypikal_Arkitect wrote:We got the editor working on Windows right? Was wondering if the changes have been pushed through? Am getting 'undefined reference' when trying to compile it. Maybe there are some changes I need to make to my local environment?

I guess the editor its probably not essential for scripting but very helpful.


I guess you have only compiled the source in the editor directory. The editor uses some more source from Allacrost itself, among others the utils. Have a look in the autoconf.ac file. There is the list of all required files to be compiled and linked for the editor. Or, as roots pointed out, use the precompiled exe. If you have any issues with this one, please tell me.
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Fri Jun 17, 2016 3:51 pm

There's an issue that has come up during the capital scripting with context switching. As you can imagine, there are a lot of different contexts in this map due to the number of different structures and floors. The problem is rooted in how we make the transitions between them. Context zones work on a tiled basis, which means that we switch the context depending on what tile the user is standing on. A context zone defines two sections on the tile grid: one corresponding to context A, and the other to context B. Depending on your current context and which section you are standing on, we switch from A to B or vice versa.

The problem with this is that we need the sections of both A and B to exist in *both* contexts. Otherwise when we change the context, if there's no tiles in the context we are switching to (or those tiles are not walkable), then the sprite gets stuck and can no longer move. Imagine a door that the user walks through, from top to bottom. The section below the door is context B->A switch, and above the door is A->B switch. But to do this switch correctly, we have to turn off collision on the door so the user is able to walk through it. And we need the interior of the structure to extend below the door so that the user can walk out.


I realize this is all rather technical and complicated to explain. So what's the problem with this system? There are several.
  • Both sections of a context zone need to be walkable in both contexts so that the player doesn't get stuck
  • This causes some weird looking transitions in some cases. Houses that extend out beyond their physical boundaries, for example.
  • It requires us to make some map elements uncollidable that otherwise should be (walls, doors).

I'm thinking we need a secondary means to switch contexts, otherwise we'll be stuck with these oddities in all our maps. There are a few different ideas that I'm thinking about.
  • Instead of having two sections in a context zone, only have a single one. That way there's less space that has to be "shared" by both contexts.
  • When switching between contexts, take control of the player sprite and turn off collisions for it, then force it to walk through the door/whatever to fully transition to the new context, and avoid having the sprite get stuck because two contexts don't have an overlapping section
  • In addition to a context zone, add functionality so that contexts can be switched by collision detection. Ie, if we detect that the player has run into a door, it triggers an event that switches the context. (Collision detection events would probably have other uses as well).

For now I'm just going to continue to design the maps to work around our current system, as implementing new context switching features would take some time. Maybe later in the release we might have time to squeeze it in, but right now I want to focus on getting the maps working.
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Tue Jul 05, 2016 3:15 pm

With the new notification engine I added last week, we should now have a viable alternative solution for context switching. We can now execute code upon collision detection. So taking the example of walking through a south facing door in the last post:

- The map script continuously examines any collision events that have occurred
- If a collision happens with where the door is located (which we represent as a line sitting between two tiles) and is in the correct context, we execute some custom code
- The code transitions the context and moves the sprite to the other side of the door, moving the camera to the new position

It's relatively straightforward, and much better than a context zone. Context zones will still have their uses though, as there are times where we want to change contexts after walking through a certain area. But I expect they will have limited uses now.

-----

I've been working on the capital map for the past couple of days, adding new artwork, organizing some tilesets, and building out the map more. I've been trying to avoid adding layers unnecessarily, but I'm at the point where I simply can't do what I want to without more layers. So I moved the layer count up on this map from 4 to 5. The bottom three layers are all drawn before objects and have collisions enabled, while the last two are drawn after the objects and have collisions disabled. I'm making great progress on it though and will have more to share soon. :hack:
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Mon Jul 11, 2016 1:53 pm

I implemented the new context switching on the capital map last night and thought it would be prudent to demonstrate how it works.

1) Checking notification types
First in the map script's update function, we examine all notification events and if any are collision events, we pass off the notification to another function to handle it.

Code: Select all

function Update()
   local index = 0;
   local notification = {};
   while (true) do
      notification = NotificationManager:GetNotificationEvent(index);
      if (notification == nil) then
         break;
      elseif (notification.category == "map" and notification.event == "collision") then
         HandleCollisionNotification(notification);
      end

      index = index + 1;
   end
end


2) Examining notification properties
This specific function has been written for handling only collision notifications. It figures out what collided with what, and depending on the location that the collision occurred, determines if any action should be taken. I removed a large chunk of the middle of this function because its rather long (there are a lot of doors on the capital map).

Code: Select all

-- Processes collision notifications and takes appropriate action depending on the type and location of the collision
function HandleCollisionNotification(notification)
   -- We're only concerned with collisions by the player sprite for this map
   local sprite = notification.sprite;
   if (sprite:GetObjectID() ~= Map:GetPlayerSprite():GetObjectID()) then
      return;
   elseif (notification.collision_type == hoa_map.MapMode.OBJECT_COLLISION) then
      -- TODO: we may want to use this collision type to detect if the object was an enemy and start a battle if so
      return;
   end

   -- Determine the positions of each side of the sprite's collision rectangle
   local x_left = RoundToInteger(notification.x_position + notification.x_offset - sprite:GetCollHalfWidth());
   local x_right = RoundToInteger(notification.x_position + notification.x_offset + sprite:GetCollHalfWidth());
   local y_top = RoundToInteger(notification.y_position + notification.y_offset - sprite:GetCollHeight());
   local y_bottom = RoundToInteger(notification.y_position + notification.y_offset);

-- large block omitted here

   elseif (sprite:GetContext() == contexts["interior_b"]) then
      if (sprite:IsFacingDirection(hoa_map.MapMode.SOUTH)) then
         if (y_bottom == 68 and notification.x_position >= 22 and notification.x_position <= 24) then
            SpriteContextTransition("exit_lcastle_side", sprite);
         end
      elseif (sprite:IsFacingDirection(hoa_map.MapMode.EAST)) then
         if (x_right == 84 and notification.y_position > 60 and notification.y_position <= 66) then
            SpriteContextTransition("ltower_to_balcony", sprite);
         end
      end
   end


3) Determining context switch properties
Finally, we've determined that a context transition is to occur. The code analyzes the string identifying where on the map the transition is taking place and from which context to another. The code first sets the virtual focus to the sprite's position, then updates the sprite to its new destination past the door/whatever its walking through, and then animates the context change and also the camera movement from the old to new position

Code: Select all

--! \brief Initiates necessary actions for a sprite to transition from one context on the map to another
--! \param transition_key An string determining what sort of transition should take place
--! \param sprite A pointer to the sprite making the transition
function SpriteContextTransition(transition_key, sprite)
   local transition_time = 1000;
   local new_context;

   sprite:SetMoving(false);
   -- Set the virtual focus to the sprite's original location.
   Map:GetVirtualFocus():MoveToObject(sprite, true);
   Map:SetCamera(Map:GetVirtualFocus());

   if (transition_key == "enter_lcastle_side") then
      new_context = contexts["interior_b"];
      sprite:ModifyYPosition(-2, -0.5);
   elseif (transition_key == "exit_lcastle_side") then
      new_context = contexts["exterior"];
      sprite:ModifyYPosition(2, 0.5);
   elseif (transition_key == "balcony_to_ltower") then
      new_context = contexts["interior_b"];
      sprite:ModifyXPosition(-2, -0.5);
   elseif (transition_key == "ltower_to_balcony") then
      new_context = contexts["exterior"];
      sprite:ModifyXPosition(2, 0.5);
   elseif (transition_key == "balcony_to_throne") then
      new_context = contexts["interior_a"];
      sprite:ModifyYPosition(-2, -0.5);
   elseif (transition_key == "throne_to_balcony") then
      new_context = contexts["exterior"];
      sprite:ModifyYPosition(2, 0.5);
   else
      new_context = contexts["exterior"];
      -- TODO: print warning message about unknown transition key
   end

   sprite:SetContext(new_context);
   Map:ContextTransitionBlackColor(new_context, transition_time);
   -- Animate the camera moving to the sprite's new location
   Map:SetCamera(sprite, transition_time);
   -- Prevent player from controlling sprite until transition completes
   Map:PushState(hoa_map.MapMode.STATE_SCENE);
   EventManager:StartEvent(event_chains["pop_state"], transition_time);
end



The end result is pretty slick (take my word for it for now). The only jarring part is that the sprite will instantly disappear from the context as it begins fading into the next one. It will look even better once we are able to blend two contexts together to show the transition more seamlessly. But for now, this effect is definitely nice enough for the next official release. :approve:
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Sat Jul 30, 2016 4:55 am

As I continue to do the scripting for these maps, I'm finding better ways of doing things and wanted to share. What is particularly annoying during development is whenever we need to construct or modify an event sequence. Below is an example of a sequence where done the "old" way.

Code: Select all

   -- Party watches as enemy demon emerges from the shadows and attacks
   event_sequences["demon_spawns"] = 20;
   event = hoa_map.PushMapStateEvent.Create(event_sequences["demon_spawns"], hoa_map.MapMode.STATE_SCENE);
    event:AddEventLinkAtStart(event_sequences["demon_spawns"] + 1);
   event = hoa_map.DialogueEvent.Create(event_sequences["demon_spawns"] + 1, event_dialogues["demon_spawn1"]);
   event:SetStopCameraMovement(true);
   event:AddEventLinkAtEnd(event_sequences["demon_spawns"] + 2);
   event = hoa_map.CustomEvent.Create(event_sequences["demon_spawns"] + 2, "SpawnSceneDemon", "IsSceneDemonActive");
   event:AddEventLinkAtEnd(event_sequences["demon_spawns"] + 3, 1000);
   event = hoa_map.DialogueEvent.Create(event_sequences["demon_spawns"] + 3, event_dialogues["demon_spawn2"]);
   event:AddEventLinkAtEnd(event_sequences["demon_spawns"] + 4);
   event:AddEventLinkAtEnd(event_sequences["demon_spawns"] + 5);
   event = hoa_map.PopMapStateEvent.Create(event_sequences["demon_spawns"] + 4);
   event = hoa_map.PathMoveSpriteEvent.Create(event_sequences["demon_spawns"] + 5, sprites["enemy_spawn"], 0, 8);
   event:SetRelativeDestination(true);


So what's the problem with this? For one, it's a lot of typing (or copy/pasting) of the event_sequences["name"] everywhere. But the major issue is that if we need to alter the sequence by sticking some new events in the middle, we have to update all these IDs everywhere. It's tedious and error-prone to do.


Now here's my improvement, using another sequence example.

Code: Select all

   -- Dialogue where player must choose to help or ignore the citizen
   event_sequences["help_citizen"], event_id = 100, 100;
   event = hoa_map.CustomEvent.Create(event_id, "StartHelpDialogue", "");
   event:AddEventLinkAtStart(event_id + 1);
    event:AddEventLinkAtStart(event_id + 2);
   event:AddEventLinkAtStart(event_id + 3);
    event_id = event_id + 1; event = hoa_map.PathMoveSpriteEvent.Create(event_id, sprites["lukar"], 164, 128);
    event:SetFinalDirection(hoa_map.MapMode.EAST);
    event_id = event_id + 1; event = hoa_map.PathMoveSpriteEvent.Create(event_id, sprites["mark"], 164, 130);
    event:SetFinalDirection(hoa_map.MapMode.EAST);
    event_id = event_id + 1; event = hoa_map.PathMoveSpriteEvent.Create(event_id, sprites["claudius"], 3, 0);
    event:SetRelativeDestination(true);
    event:SetFinalDirection(hoa_map.MapMode.WEST);
    event:AddEventLinkAtEnd(event_id + 1);
   event_id = event_id + 1; event = hoa_map.DialogueEvent.Create(event_id, event_dialogues["help_citizen"]);


I declare a local variable called event_id in the CreateMapEvents function, then set this ID at the same time I set the start of the sequence. I pass the ID all the functions that require it, incrementing the ID with an offset for the event links. The event_id itself is incremented just before every Create() call for an event, on the same line to make it a bit easier to read.

With this method we'd still need to update the event link IDs, but inserting a new event into the sequence won't be as painful as before. And I feel that the code becomes a little more readable without those long event_sequence["..."] everywhere. Sound good? :approve: I'm going to do my event construction this way going forward (unless I find an even further improvement).
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Fri Aug 12, 2016 4:22 pm

The capital attack script is nearing completion. There are just three more event sequences that I need to write now, and I don't expect they will take me very long to do. A big reason why this scripting has been taking so long is due to the complexity of the map, the amount of scripted sequences that take place, and the number of features that map scripting was lacking in order to make this all happen. I've since added a lot of improvements that give map scripting more power and flexibility, so future maps won't be quite as tedious and frustrating to design (I hope).


Now when I say 'completion' I mean something good enough to play through the entire map, start to finish, with all major functionality implemented. There is still some missing artwork needed (mostly sprites), but placeholders are doing fine for now. Of course we'll continue to iterate on this map as we get additional art assets and make other technical improvements, like adding sound sources.


The next capital map, "aftermath", I don't think will take very long at all. It won't have as many scripted sequences and is more of a typical player exploration map. And the sand dock map is even less work, and is nearly complete already. I'm wagering that by the end of the month, we'll have all three of these maps complete and will be able to make another development release. :D And when this is achieved, all that should be left for map design and scripting is just refinement work and smoothing out any rough edges.
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Fri Aug 19, 2016 4:56 am

My work on the capital attack script is done for now. For the aftermath map, before I start scripting on that there's some missing artwork that needs to be created, and then additional interiors of the castle and homes need to be designed with that art. So for the next week or two I'm going to be focused on finding or making that art and placing it into the map. It will be a good change of pace for me, as I need a break from scripting work anyway.
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Tue Dec 20, 2016 5:25 am

Roots wrote:For the aftermath map, before I start scripting on that there's some missing artwork that needs to be created, and then additional interiors of the castle and homes need to be designed with that art. So for the next week or two I'm going to be focused on finding or making that art and placing it into the map. It will be a good change of pace for me, as I need a break from scripting work anyway.


I'm finally getting around to this now. I started scripting the aftermath map and realized that the castle interiors need a lot more work before I can script the second sequence. So I'll be doing the above until it is in a good enough state that the scripting can be done. This is currently the primary blocker for our development release.
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Maps and Scripting

Postby Roots » Fri Dec 30, 2016 1:30 am

I got asked in the chat channel a few days ago about how others can help with map development and scripting, seeing as I am the only one with the knowledge of how to do it at the moment. I've been meaning for weeks to produce a video tutorial to explain exactly that, but I just haven't gotten around to it. So in lieu of that, here's a brief explanation of what needs to be done and how to do it.


The map that needs someone to work on it is called the Harrvah Sanddock. A lot of this map is already filled out and you can play it right now (use the test interface menu to access it), so you don't need to start from scratch. The map data file and script files can be found here:
  • lua/data/maps/harrvah_sand_dock.lua
  • lua/scripts/maps/a01_sand_dock_departure.lua

The map data file (which is produced by the map editor) is mostly complete. However, some of the collision data is wrong. If you play the map, you'll see that you can walk off of the wooden docks at some places (where there are no rope barriers). This needs to be fixed, as the player should not be able to walk off the docks, nor should they be able to walk down the ladders.




This video I produced a while back should be sufficient to explain how to use the editor to make these changes to the map data.



The second part that needs work is the map scripting. Right now there is only a very basic script file, placing some sprites and dialogue. Here's a list of what needs to be done:

- Exiting the bottom of the map should return the player to the "harravah capital aftermath map, near the top center just underneath the castle balcony walkway.
- Some random dialogue needs to be added for the other NPC soldiers on the dock. Don't worry too much about the dialogue, as its simply placeholder for now. But it shouldn't be something silly or nonsensical.
- The sprites for Laila, Marcus, and Vanica should not be visible on the map initially (they will come off screen during a script sequence).
- There is a soldier on the center dock near the ladder. This soldier should say something like "Are you ready to depart?" along with a yes/no option for the player to choose. If they choose no, the dialogue closes. If they choose yes, a scene begins (the final scene of this release).
- During the scene, Claudius' family (the three characters I mentioned earlier) walk in from the bottom of the screen to bid farewell. A multi-line dialogue between Claudius and his family takes place. Again, this is placeholder, but you should refer to the story chapter on our website as a model.
- When the conversation ends, Claudius will walk down the ladder (eventually there will be a sand glider there. I'm still working on it).
- Claudius boards the glider and it begins traveling off the screen to the right, with the camera focused on Laila, who is now alone on the dock watching him leave.
- The screen fades to black with a "To be continued..." message


So how do you do all this? The best thing to do is to look at existing map scripts and see what they do. I strongly recommend following the style and organization of the map a01_harrvah_capital_attack.lua. Toward the end of this map it does the fade to black "To be continued..." sort of message, so you can see how that is done. Hopefully the map script should be somewhat self explanatory. Most of the work in map scripts is setting up all the different data that gets loaded and placed (sprites) and all of the event sequences that get built. The actual stuff that happens at run-time (checking special update or draw conditions) is pretty trivial.

If you have any questions, please don't hesitate to ask. If someone picks this up it would be a huge help to me. And you can learn quite a bit from this as well. :approve:
Image
Lordakius
Junior Member
Posts: 26
Joined: Thu May 26, 2016 9:22 pm

Re: 0.1.0 Release Maps and Scripting

Postby Lordakius » Mon Jan 02, 2017 1:10 pm

Cool thing :approve: definitely would love to start with that, but I first want to finish my current work (and since college started again, I am a bit busy with that,too :ohnoes: ).

When I am done with my assignment, I will try to hook on your work, though. (the very latest date would be end of February, after my exams, but I am confident that I should have time before.)
Lordakius
Junior Member
Posts: 26
Joined: Thu May 26, 2016 9:22 pm

Re: 0.1.0 Release Maps and Scripting

Postby Lordakius » Mon Jan 30, 2017 11:23 am

Since I didn't made a lot of progress with my current work, I will hook up on the map scripting. Did anyone else started already on this, so we are not colliding with the work ?

Return to “Design”

Who is online

Users browsing this forum: No registered users and 3 guests