Client progress

[tricxta]

Some issues with animations have been fixed and they seem pretty stable now. This leads to the part I’ve not been looking forward to. It’s time to start defining the engine scripting API. This is basically writing the equivalent of commands.rtf by deciding on what to name variables/functions/objects, what features are needed, and how to organize everything in general. This is really only annoying because any changes later on will break scripts anyone has written. It needs to be as perfect as possible from the beginning.

GS2 had a somewhat decent API I found, that might be a good starting point.

[Codr]

I spent some time refamiliarizing myself with the script engine code and somewhat redesigned the way it interacts with the rendering engine. I think the script engine in a much better spot now for me to more easily make API functions available to it, though I guess I’ll find out for sure as time goes on. I just finished this as I need to go to sleep, of course. So I’ll test it a bit more tomorrow and start figuring out how to make events work. The current goal is to get all of the framework pieces in place to allow input > event > script > reposition animation.

GS2 had a somewhat decent API I found, that might be a good starting point.

I’m sure I’ll reference it repeatedly for ideas, but I’m definitely not trying to mimic it. Keep an eye out for new posts asking for input too, as they’ll surely come along in the future.

[Codr]

I just ran a quick test of the script engine and it generated 100,000 random numbers about 8 times slower than pure C++ code, while in debug mode. This is pretty awesome for a language that’s currently interpreted and not compiled into assembly code. (Such as JIT versions of Lua/JavaScript, for example.) My concerns about it not being fast enough for the client are clearly unjustified. This is looking great for the project as a whole. Sorry, I had to post. I was excited/relieved by this result.

Anyway, the updates to the script interface are adequately done for now and are great changes for me as I work on the client API. I’m starting planning/work on making events possible now.

[2ndwolf]

That’s awesome. Can’t wait to code in CodrScript.

[Codr]

That’s awesome. Can’t wait to code in CodrScript.

I can’t even settle on a client name. Let’s not start on the language. :whatever:

[Spooon]

Someday?

-edit Hey, guess what. You can’t put the TM character so you’ll have to deal with the question mark, that’s what.

[Codr]

I’ve been stuck trying to figure out a good way to link script variables to objects within the game engine. I’ve got a few ideas, but none of them are very efficient. There has to be a better way. Work has also been exhausting and I’ve not wanted to think about this problem much, so I’m hoping this weekend will give me the time to come up with a solution.

Here’s a basic script illustrating the problem:
obj = new Sprite;
obj.x = 5; //This needs to update the actual Sprite object’s x. The object isn’t stored with the variable. That would be bad for the renderer.

There are numerous ways to make this happen, but none that I’ve been satisfied with so far.

[Chicken]

Possible to store like a pointer to the object on the heap or something? Then obj.x is a shortcut for some something like obj.getObject(id).x

Not a lot of thought went into that idea, so forgive me if it’s retarded lol

[Codr]

You’re on the right track, but there are lot of factors to consider. I’m not going to go into every detail, but for example, the variable won’t always be a particular type.

[Codr]

I’m trying to get back into this. Summer is still here, though, so activity probably won’t be very consistent. I don’t think it ever has been anyway…

As I recall, everyone was wanting a means of starting to develop content as soon as possible. While a level editor can definitely be a first goal, a lot has to be completed to even make that a reality. I don’t want to make it an external program, as that complicates future cross-platform functionality.

The milestones to cross to get to a level editor are:

• Script engine interface completion (currently in progress)
• Development of necessary user interface controls
• Development of the level editor scripts

I can’t attempt to put a time frame on this, but it doesn’t seem terribly far in the future, depending on how active I am with development. A new WoW expansion is coming in 2 weeks, too. I’m hoping it won’t keep my attention long, as they tend not to anymore.

One question I have is… is a level editor even worth it without scripting support? While that could be added, it would be incomplete, as the game engine hasn’t even been fully developed. I don’t have a plan for all of the engine’s script API. I think it would be best to limit the level editor to scriptless objects only until later, but again… is that worth it?

[Yggdrasil]

As long as there are objects to be used to make general levels that could be improved later when scripts get released, I think it’s worth it. Some people might also benefit from getting their level designs done before they start scripting.

[urza]

Glad to see someone is still motivated enough to work on a project like this.

Having the level editor without scripting support would also allow for more extensive testing of the tile system. Unless that’s already been done… In which case ignore me.

[Glyde]

I support this project fully and would love to see its development through, I am too busy to help myself.