0 favourites

Tags


Subscribe

Get emailed when there are new posts!

Stats

  • 504 words
  • ~2-3 mins read time
  • Published
  • 205 visits
  • 92.1 visits per week
  • 241 page views

License

This blog post is licensed Creative Common Attribution Required v4.0.

Share

Enjoy this blog? Share with your contacts!

Share now

Laura_D's avatar
Medal
Construct Team Community Manager

If you read my post last week, you’ll know I was rather excited about the fact that my NPCs were pretty much all working, and life was wonderful. Except as I’m finding out more and more with this project, that sense of “it’s done” is in fact, a lie.

This project I’ve embarked on is somewhat complicated, but I didn’t quite appreciate just how much my little bits and pieces would need to intertwine. For example, I said that my next big job is to start the dialogue system, which meant I was going to have to really start getting to grips with XML etc. Which to be honest, was rather terrifying for me. So I thought, I know, I’ll put that off by making sure my dialogue boxes spawn correctly etc, then I can think about the text that’s going into them.

Easy right? Just a case of adding in a few more bits of code? Nope.

The player character was one of the first things I put into this game. It’s a pretty simple system, just uses Tile Movement’s default controls so I don’t really have to think about the keyboard too much. (That will obviously change if I decide I want to tackle gamepad support or custom key bindings.) But for all intents and purposes, it worked. The guy moved, the animations moved correctly with him. It was fine.

That is, it was fine until I tested the interaction system (that will bring up the dialogue boxes) a bit more thoroughly. I realised then that there was nothing stopping the player from starting a conversation and then just walking away. And that’s just rude! So, I needed to go back and re-evaluate how the player character worked to try and come up with the best way of factoring in this newly required behavior. Which is when someone suggested (I’m sorry I can’t remember exactly who, it’s been a long week!) that I should probably be using states for my player, in the same way I had for the NPCs.

So fast forward to the current state of the project, my player character now has a ‘Talking’ state in the same way the NPCs do, it serves exactly the right purpose. The player now has to wait until the dialogue functions have finished before the state changes back to ‘Standard’ and their movement is re-enabled.

It probably sounds obvious to more seasoned game developers, but I keep forgetting just how much each mechanic affects everything else. This definitely won’t be the last time I come back to a mechanic I’ve already implemented because I’ve added something in somewhere else. It’s just another learning point I didn’t even consider!

As for the game we played this week, Healer’s Quest has so far proven to be tricky at times, and hilarious. I don’t think I’ve ever laughed so much in a character creation process! You should definitely check it out if you’ve not come across it. I’ll be playing it again on Thursday too!

  • 11 Comments

  • Order by
Want to leave a comment? Login or Register an account!
  • Laura_D, isn't it tempting to ask Ashley a lot of questions while working on a project like this?

    From reading your blog I think you do try to find it out on your own, but I am wondering what your response is. :)

      • [-] [+]
      • Laura_D's avatar
      • Laura_D
      • Construct Team Community Manager
      • 2 points
      • (0 children)

      It is tempting, and I do ask the others when I'm really stuck. But they're all busy doing their own work, so I try and get through things on my own!

      Or with the help of my viewers - co-op coding is becoming a regular thing!

  • Your answer here is : State Machine.

    It's tricky and hard, (breaking teeth on this on my next game…) but it's a good way to start. There is a very good plugin for C3 called FSM for this.

    Doc here : gameprogrammingpatterns.com/state.html

  • I personally think it would be better to start with basic projects first. Or just make small projects just for fun and learn things from them. I have quite a few C3Ps on my desktop, and only one of them is to sell. I've made a few computer simulator games where you can play actually real games that I've played. It's a long story about Cooking Simulator, but it even makes fun of how Windows Updates wreck your computer! Once my computer got really laggy. Then after resetting it it was still laggy but the display was messed up. I definitely suspected an update, and it was at the worst time too, when I was sick. Now my computer simulator game makes fun of that! Three update, three times the laughs! You can try it if you want. After doing the second windows update, don't forget to visit Walmart and the Bank! And after the third update, stay on a certain screen for 5 seconds and you will go LOL!

    Try it here:

    dropbox.com/s/hsgutukqlbqaz2s/Computer%20Simulator.c3p

      • [-] [+]
      • Laura_D's avatar
      • Laura_D
      • Construct Team Community Manager
      • 1 points
      • (3 children)

      In a way, I'm already doing that - all the mechanics for this game are being built in small, external projects before being imported into the main game. Also means I can more easily create examples for tutorials etc.

  • Hey Laura_D, what you need is to focus on a FSM (Finite Stame Machine) approach to your game. I've created my own C3 plugins to make this easier, but you can implement it with simple instance variables and you will need a global variable for your whole game state. This is a simple and effective approach since all the actions depend on your object's state. For instance, if you NPC is being controller by the player, it may have the state "PLAYER_CONTROL" as a string in it, then if you trigger the dialog box you may change the state to "PLAYER_DIALOGUE", and in your event sheet you have to condition the "control handling" of the player to the state "PLAYER_CONTROL" so your game knows when you are either moving around, or seeing a conversation.

    I just implemented the same stuff I described for my last games and workload reduces a lot becuase your conditions to trigger more stuff in the game depends on a state, instead of tons of variables and animations.

    Hope it helps

      • [-] [+]
      • Laura_D's avatar
      • Laura_D
      • Construct Team Community Manager
      • 1 points
      • (1 child)

      Hi Sotano,

      Appreciate the input, but I'm already using states - we had this discussion on stream a few weeks ago! I just hadn't put them in for the player, only NPCs.

      • That's actually very handy... for instance, an "Active" state for the player lets the user move, jump, run, use his power ups... then when you receive damage you change the state to "Damage" and you may inactivate the controls and throw the player a couple of pixels away like receiving an impact, then return to "Active" and enable movement again. And for special powers they may be "sub-states" of the main "Active" state. Is usefull also for handling animations with more complex effects. When I did this I first used instance variables for my objects, and months later I was able to develop a behavior and a plugin for handling the whole game state and each object's state.