I recently started creating a roguelike for the Android platform; early on I was aware of the benefits scripting would offer to such a game (mostly scripting for monster and item abilities), however I wasn't able to find any usable scripting layers. I looked into SL4A because someone mentioned it to me a while back, but I found evidence that it was no longer maintained/usable? Lots of conflicting information, if someone knows anything definitive about how to set it up or what is going on with it, I would appreciate some help with that. After that failed, I realized that I could just hard-code the scripts and run them via circular dependencies, here's an explanation of what I mean:

Monster have a method that is run to use their special abilities (ex. an orc with the ability to throw fireballs would create a fireball effect at an adjacent position on the map), the problem was that the map object and mobile object should logically be on different layers in a layered system (I'm given the impression that this is the desired design in OOP), so I created a object called the Game State Manager that held the map and had a static method to give other classes access to the current map. Meaning that objects on the lowest layer depended on objects from the top layer of the design, making the dependency circular.

I read a few stack overflow articles on circular dependencies and couldn't find anything definite there, only that it was acceptable in some cases if the design held circular dependencies by nature. But no one actually gave an example of a potential problem that they could cause (other than circular references, but my system won't run into that anyway). So my questions are:

1.) Are there any serious problems that circular dependencies can cause?

2.) Why are they considered a design flaw?

3.) Is there any better way to do what I am trying to do that doesn't require me to write my own scripting language?

Thank you for any help you can provide.

After that failed, I realized that I could just hard-code the scripts and run them via circular dependencies, here's an explanation of what I mean:

This is confusing, and your example doesn't really explain what you're doing. Can you be more specific?

1.) Are there any serious problems that circular dependencies can cause?

I imagine these are the reasons someone would discourage a circular dependency: http://en.wikipedia.org/wiki/Circular_dependency

2.) Why are they considered a design flaw?

Mostly because you classes/modules/libraries are tightly coupled. But this isn't always bad. It depends on what you're going. For a game to have objects that know about other objects, it's probably fine.

3.) Is there any better way to do what I am trying to do that doesn't require me to write my own scripting language?

I do not know anything about scripting for Android, but I imagine there is a solution easier than writing a custom scripting language.

LuaJ maybe?

I wasn't able to find any usable scripting layers.

Java8 now has Nashorn, a Javascript runtime. I believe that Nashorn is not yet available for Android but its conceptual predecessor, a library called Rhino, does work on Android. So take a look into Rhino if you want scripting.

If you're just making a game (rather than a generic framework/engine) then scripting may be of questionable value anyway, just code your game logic in Java.

1.) Are there any serious problems that circular dependencies can cause?

Nothing critical like memory leaks or crashes.

2.) Why are they considered a design flaw?

The problem is that your high and low level code now depend upon one another - you can never reuse your low-level code in a different project because it is coupled tightly with something else.

3.) Is there any better way to do what I am trying to do that doesn't require me to write my own scripting language?

Don't write your own scripting language.

If you're concerned about coupling high and low level components then look into Inversion-of-Control (IoC) and Dependency-Injection (DI). Basically, you use interfaces to decouple the implementation. Components then only rely on interfaces and are not coupled to the implementations.

For example if you want a low-level component to drive a high-level component, then the low-level component can do that driving via an interface which the high-level component will implement. Your low-level code is not actually coupled with the high-level code, it only depends on the interface.