Adventure game in installments.

Game Engine Works in Progress and Game Demos
21

I was much more comfortable with it at 1.5x speed. At this speed, the regular walking motion might better be represented as a jog (not quite a sprint, though). If I need to go slower and be more careful, I’ll sneak.

I still don’t like the pauses when turning 90 degrees. Maybe they could at least be shorter. The pause for the 180 degree turn makes sense, but only if I’m already moving in one direction and need the pause to “counteract” the momentum.

I don’t want to meddle too much with your game, though. When you start prototyping game mechanics, it may turn out that the character’s controls already in place either contribute to or detract from the fun, but you’ll never know until the prototypes come. It all depends on what’s fun.

22

Ha, yeah it does sound unrealistic when you put it like that. :slight_smile:
But I’ve actually already done some prototypes before now so it’s more a case of lumping them together rather than building anything from scratch.

I expect I can get a simple system working in a couple of days, but the one thing I’m not sure about is the spellchecking.
Correct spelling and grammar is a must for a dialog based RPG, but my original idea, of building spellchcking functions in to the text editor might have to wait. It might be better to pickle the dialog dictionary and at the same time export a plain text version to be spell checked in MS word. Then I can open up the editor again and do any corrections manually.

You may have noticed that I spelled the name of this thread incorrectly though so it’s best not to hold out too much hope. :stuck_out_tongue:
I tend to do a lot of my game design work late at night, when I’m tired, prone to simple mistakes and often have to go back and correct things the next day.

Hmmm… jogging is a whole other category, I know people don’t really want to wait around for a character to slowly walk around the screen these days (I actually turn off animations in some games, like civilization, you could reduce it to ASCII art and I wouldn’t care) but we’ll wait and see.

As you say, the proof is in the pudding. Once there’s actually a game to play it’ll be easier to decide what’s fun or not. I may leave the speed adjustment code in the game

23


First results from the spell checker as designed by Peter Norvig.

It’s actually very easy to set it up, so next step is to build it in to a dialog editing system with some sort of UI so I can decide to accept corrections or not.

In any case it’s not going to catch all problem words, but it’s better than just trusting to my own eyes. :slight_smile:

24

wery well done models , and awesome armature setup!! (very simple and functional)

just why the character is so little? is about 0.8 meters, should be atl least the double

the animations are well done , anyway i prefer give more priority to the movement.(ie: no matter if the animation is ended)

PS: what about classes? is a experiment or is a well definied “design” ?
[##edit ##]

25

Have you tried it and found that to be true?Tell me which ones if you did.Maybe he can improve on it.

26

Hi, it’s not often I use classes, so if I’m using them wrongly, please tell me.
I recently made the FSM using functions, but I was unhappy with having so many variables attached to the main character which were only used during specific states. I’ve tried using classes so that most variables are held within that class and die with that instance of the class. There are a couple of global variables, such as current facing which are attached to the character, I don’t know if that’s the best case, or whether it’s better to pass that variable on to the next state when it is created.

I’d also like to know if it’s possible/wise to declare class methods such as update() outside of the the main body of the class. I’d like to keep the classes streamlined so I can see their structure more clearly.

How about inheritance? I’ve tried having a few super states, such as a general movement state and then defining things like which animation to use or the speed of that movement in a subclass state. That seems like a good idea to me, what do you think?

27

Agh!!! something not quite right with my dialog tree display. It nearly works perfectly, but still some bugs to work out.

Once I get it displaying properly it should be easy to move on to editing the contents of each dialog box (that code is already working!) and then program the dialog system for the game to run off of this one.

I’ve always wanted to code a visual dialog editor, I’ve put off making any dialog based games until I had the required skills to get it to work. Hopefully, now I’ve got them. :slight_smile:

dialog_tree.jpg840×850 66.9 KB

28

Hi, i do some good thing with class when all mess can still well inside the class itself, and there are not real too many exception to manage, and overall the goal is well definied.

different for character+states => never done anything of good…

anyway the lastest setup (seem good) is create a class Character, the character , is moreover the interface of the “box” .
(the armature has another interface-> “Animator” … it reside in the instance of character)

that instance run alone some thing as on_ground check, imput and some other.(actually not need other)

then it run the current state (self.state). it run before the medod self.state.transition() to “ask” to the state if has ended, if yes return a class of new state, and the character do the switch.

the state not know in any way any gameobject. each time a state want do something have to call the char.
so in the state you never see “own”, or “armature”…
this is very matter i guess.
so, the state “use” the character , but IS NOT the character. , while (strong difference) in you blend the character not exist, seem that the “state is the character” and you have also continues reference directly to the gameobjects.
this is unavoidable i guess.
i have done in this way time ago, but was not able to make subclass, so was ever a bunch of code

anyway as said i cannot give too many counsill seeing the hugly results :smiley: , instead can be right your idea.(very good also your game of BMC ! …i need years to do a thing like that!)

for inheritance you mean ->
CharacterBase
Character(CharacterBase)

yes, that is surely mandatory to do good thing (and overall avoid tons of code)

this is how i do actually (except armature gobject is already a interface , but this way become more readable)




class State:
    def __init__(self, char):
        self.char = char
    def start(self):
        pass
    def transition(self):
        pass
    def update(self):
        pass
    def end(self):
        pass


                
        
class Idle(State):
    def start(self):
        self.char.arm.playAction(..idle..)








class Character:
    def __init__(self, box, arm, others={}):
        self.box = box
        self.arm = arm
        self.state = State(self)
        self.set_state(Idle)
    
    def set_state(self, cls):
        self.state.end()
        self.state = cls(self)
        self.state.start()
        #self.box["state_name"] = cls.__name__
        
    
    def update(self):
        self.on_ground = self.box.rayCast()..
        self.imput = get_imput()..
        
        cls = self.state.transition()
        if cls:
            self.set_state(cls)
        self.state.update()

PS: i can post your blend (thanks for sharing it ;)) with the implementation working of classes if intersest

29

@MarcoTT

Ah, I get it! :slight_smile: The armature and character box should be included in the initiation of the class. That’s a much better idea.
I didn’t think of that. I’ll do the conversion myself, it’ll be a good learning experience.
I don’t know much about the normal working of classes, so it’s good to get some advice sometimes.

RE: The dialog editor/manager.
I got the dialog boxes lined up and working correctly, and the editor is going a long quite well too. I’ve integrated the spell checker and the end result should be quite useful to me. Once I’ve tied up all the lose ends I’ll try making a dialog demo, with the player interacting with a computer terminal or something.

30

Wait, how is the character class run? From inside the script attached to the character, or do you use a scene manager script and run it from there?

I’ll take a look at it tonight and see if I can make something that works.

31

Looks like it will be nice project… However, could you tell what is gone be it’s storyline about?

32

Ah, that’s top secret for now. :slight_smile:
The main character emerges from artificial hibernation on an abandoned spaceship on a strange planet.
She has an important mission, if only she could remember what it is…

I know, amnesia is so Cliché, but it works quite well as an RPG hook. As you find out more about who you’re playing as, and why they are where they are and what they should be doing… You may find yourself interpreting your mission parameters differently that other people would, and it gives you a chance to develop the character a little more as you’d like.

33

it run from a script attached to the box… anyway the character should be registred inside some list of characters, from when there are other characters :smiley:

i forget to reply to this:
"I’d also like to know if it’s possible/wise to declare class methods such as update() outside of the the main body of the class. I’d like to keep the classes streamlined so I can see their structure more clearly. "

it seem that is doable , when you add one function to an instance of class it just add the argument self, as first argument.
so you have just to add it, but not know if worth.

maybe (if i understand the goal) is better add a method/state in the class.
that usually is called main
and you can also call 2 method in one shoot, one is the initialization , that run immediately
the other is the state/method.
(this way you can avoid to set the new state in the end of the old state that can be redundant


class Move:
   def __init__(self):
       self.set_state("idle")


   def update(self):
       check_for_transition()
       if not transition:
           self.main()


   def set_state(self, name):
       getattr(self,name)() #run immediately
       self.main = getattr(self,"state_" + name) #set the new state


   def idle(self):
       playAction()


   def state_idle(self):
       if imput.jump:
           self.set_state("jump")


   def jump(self):
       playAction()


   def state_jump(self):
       if cond:
            self.set_state("idle")

never tried but not seem bad

34

Well, I took MarcoIT’s advice and redid the FSM. The result is much easier to manage.

Here’s where it’s going so far:

35

really? what of two?
i guess is better the first.
where the states are a sort of “container organized” without identity that read and call method of character only (basically the state can be also a dictionary)

video -> simply WOW O.O’ (perfect)
now movements are not more “static”

36

Thanks :slight_smile:
I used the first example, as it was easier to understand. :slight_smile: And it seemed clearer.

I’ve been reading about classes and inheritance and I keep seeing:

In python you may or may not call the base class constructor, but it is good practice to do so.

So I wondered about that. It seems that as Blender uses modern Python just calling:

super().__init__()

Would be enough to make sure that the ancestor classes are all initiated correctly. It also opens up the chance to make custom mix-and-match functions in the subclasses, which could be useful for me.

def update(self):
    super().update()
    "some extra stuff"

So I could have an update() function in the MoveState (=the parent class for all movement types) and a modified one in Walking (= child class just used for animation and some post initiation setup) instead of specifying exceptions in MoveState. I really need to test this stuff out though since I’m not 100% sure about it.

Anyway, it’s much more streamlined now, and I’ll be adding some more movements soon.

37

An up to date gameplay video is here:

And you can test the blend here:
No Name Adventure Game

Oops! You’ll need the dialog dictionary if you want to run it:

test_dialog.zip (1.55 KB)

I could do with some feedback. One thing I don’t like about the player setup so far is the inability to walk on slopes.
Maybe that will be the next thing I work on. Or I might just skip it and get the dialog system back up and running.

38

Holy Shades of Valve assets, Batman!

39

I think the footsteps need to be quieter or at least a bit more subtle. The current sound of walking on gravel doesn’t really work with the concrete environment.

40

Thats right, I’m building a library of sounds right now for different types of sufaces. I’ve got some code for that already.

There will be a volume setting in the options menu too. On my PC everything is too quiet but when I listen to the youtube video on my phone it’s really loud! Sound in the BGE is a pain in the neck.

The crate and barrel textures are just place holders, ripped straight from Google images. :slight_smile:

I fixed the problem of walking on slopes, it was down to a too high z limit in the motion actuator.