Creating my own Module

Monkey Forums/Monkey Programming/Creating my own Module

darky000(Posted 2014) [#1]
Hello,

I am loving this community so much for being very helpful and replies with simple answers rather than on stackoverflow which is complicated to understand for me. Anway, I've been wondering myself how to create my own set of modules here. I have a few questions on how to make them if you don't mind.

1. I've seen Methods created like this. How does this work actually? I am curious because I wanted to create my own game loops.
Method OnSomething:int()
     Return 0
End Method


2. How does Extern work? I am a slow learner when it comes to complex things. Read it from a few descriptions but I don't understood how best to apply this.

3. If I want something from Java to be included in my module as a method/function. How should I do this and what files should I include?

4. Once I finished my module. How can I implement it on my code? Should I just Extend it?

5. This is more of a clarification so I won't be doubting my code. If I have a class A extending to class B. Class A inherits everything from B, right?

Thank you for taking the time to answer some newbie questions.


Samah(Posted 2014) [#2]
1. "OnSomething" methods are generally just a naming convention for anything that you would call an "event". There's nothing special about them as such. Usually they're called by code in the parent class. For example, the screen-handling code in Diddy checks for changes in input and calls the appropriate OnTouchHit methods, etc.

2. The extern keyword is used to tie Monkey functions and classes to native code. Most of the time you won't need to use it unless you're writing a wrapper for another non-Monkey library to make it available to your Monkey code.

3. This is where you would use extern. Basically the process for externing a single function is:
1) Write your Java code as a static method somewhere and save it as a separate .java file in your project directory,
2) Import the java source at the top of your Monkey code.
3) Create an extern function template that references the name of the static method (ie. "classname.methodname")

4. It depends on what your module does. For the most part you can just import the module's source files in your game and all the public functions and classes will be available to you.

5. Correct. You will, however, need to implement any methods defined in an abstract class or interface(s).

You're welcome. Always good to see a new face. :)


darky000(Posted 2014) [#3]
Thanks for the information, Samah. Btw, I am not new here but I'm new to the whole programming. :)

I want to clarify some things:

1. Why would you declare a method for just naming with no data inside? Can you provide sample codes or dumb it down please.

4. What module would be likely to use Extend? Can you give me the pros and cons of importing the module rather than extending it?


Nobuyuki(Posted 2014) [#4]
1. The Strict directive mandates that methods of types other than Void must return a value. Some people are OCD about this, even if the base class method isn't abstract. Typically the only reason to have an empty method which returns "no value" is to extend an abstract method, because abstract methods are required to be overridden in the child class.

4. Extend is used by any child class -- IE, a class that inherits from the base class. Importing and extending are two different things. You import a module to bring it into your project's scope. You extend a class within that module to provide your own functionality based on that class as its parent.


darky000(Posted 2014) [#5]
Thanks Nobuyuki! That clear things up.


Gerry Quinn(Posted 2014) [#6]
A good example of the use of methods that have nothing inside is the Mojo App class. If you look at it (modules.mojo.app) you'll see a lot of such methods e.g. OnCreate() - since Mark doesn't use Strict, the version there doesn't have a type or a Return 0, but it is the same as an empty method that returns 0.

App.OnCreate() gets called when Mojo has been initialised (don't worry about the details of that).

When you extend App, you will generally override OnCreate() so as to load your own graphics and so on. Now the overridden version that you made will get called instead of the empty App.OnCreate(). So your stuff gets loaded at the right time, when Mojo is already up and running, but before anything else happens. This is why Samah says OnSomething() methods are typically events: the methods get called in a specific set of circumstances when you may want to do something.


darky000(Posted 2014) [#7]
So basically, if I wanted to create a sequence in my game loops I have to create these empty methods inside my module and arrange them accordingly? Also, the extended part gets called first before anything else, right? If so, I think I got a good grasp on how things work and flow. Thanks Gerry for dumbing it down.


Gerry Quinn(Posted 2014) [#8]
It depends on what you mean by a module. If you are creating a sort of framework that you will use for different games, then indeed you could use empty methods, or interfaces, or indeed other ways to make a framework that is easily extensible. But if you don't fully understand this stuff, it is better to just write a game as simply as possible. You need to have written a few games before you start to make frameworks for them.

If I'm misunderstanding you, be a bit more specific about what you want to do.


darky000(Posted 2014) [#9]
I am planning to create my own framework for use on different games. I have made a number of games and I am repeating some of my game loops and generic methods so I thought to create my own module now to save time rewriting it later. And no, you haven't misundertood me at all. You actually hit the spot.


Gerry Quinn(Posted 2014) [#10]
There are two common ways to handle events in frameworks,

One is the OnEvent() methods we have been talking about. Your framework game window has an empty (or abstract) OnEvent() method, and your actual game window extends the framework window and overrides the method.

The other way is to use interfaces. In this method, your framework contains an instance of IGameWindow interface and calls methods of this interface at the appropriate times. Your actual game window class implements the interface, and once the framework instance is set to an instance of your class, the methods will then get called.