ID:1316918
 
Hey guys,

I'm currently developing a singleplayer game called "Apprentice". It was going to be my entry for Poplava's Maze Contest but because of poor time-management and an unfortunate miscommunication about the deadline at the very end, I could not get the game into a playable condition and didn't submit.

However, I'm going to continue development on this game and see it to completion.

This is what the game currently looks like:


You can download it here if you're interested in trying out the current build.

I would love to hear feedback from you guys! :)

I'll continue to post updates to this thread as progress is made.
It looks amazing keep up the good work.
Wow, as usual, the game looks beautiful, especially with all those particles. You even have the semi-transparent "behind a wall" effect!

Do you think you'll try isometric again if Lummox JR was able to iron-out the performance issues? Or are you done fiddling with the perspective? :P

Great writing, too. Felt very authentic and lent a good amount of personality to the characters.

Also, was I the only one who jumped when the first demon popped out of a door?
Yut Put wrote:
BYOND craps out with the mouse controls and they become incredibly unresponsive, making the game unplayable.

Deal with it.
I wasn't sure if I was the only one encountering this problem, but after a while I could no longer "click to close" the text boxes. Luckily pressing w/a/s/d closed them out!

Unfortunately, I had the same problem as Yut Put. As I mentioned previously, the mouse controls were unresponsive and I couldn't attack.

The game looks nice though, nice work Darke!
It's looking great!

Of course, there's this issue, as previously mentioned: http://www.byond.com/forum/?post=1047094
Yut Put wrote:
BYOND craps out with the mouse controls and they become incredibly unresponsive during high CPU usage, making the game unplayable.

Unfortunately there is little I can do about this, short of slowing down the game tick.
Here's a look at the profiler data after ~5 minutes of play. Looking at this data, there are no obvious bottlenecks during play (that aren't dialog-box related, that is) that might cause the mouse controls to be unresponsive.


Kaiochao has mentioned a workaround; He says he doesn't get the problem at all if he runs the game through dream daemon and then connects to it. It's kind of hacky but I guess it works :/

[EDIT]: I tried lowering world.fps to make the game tick longer. Theoretically, this will result in fewer calls to all of the various functions. The CPU usage didn't seem to improve despite the expectations. lol.
Implemented spellbook and spellcrafting. Also rebalanced a couple things so that the first level won't be so difficult.
Yes, running through Dream Daemon does actually make the mouse controls much more responsive, although it also makes the movement less smooth. That's very strange. I would have expected a hosted world to run much slower than just locally running it. I would consider that to be a bug, due to the inconsistency.

Have you thought about using JavaScript hacks to power the mouse functions? You could add in the functionality, then check if the player actually has JavaScript support enabled, and then automatically configure your mouse procs based on that. So if someone doesn't have it enabled, then the game will backfall to DM's native mouse functions. I think it would be easy to check for JavaScript. You would just have to test it out, then check for null values. I have been thinking about implementing something like this myself. In an online game, if you can take advantage of whatever amount of JavaScript support the player base has, then it will take that much weight off of the server, and result in less lag, while still supporting everyone with the built-in functions.
It's actually just the fact you're now operating in two processes, so the game logic can now be put on a different core to your game rendering/input I/O etc.
Well either way, the mouse functions are still buggy. They should be just as important as the keyboard, especially since this is running on a PC. There desperately needs to be built-in, client-side macros that can determine exactly where the mouse is, and when it's moving at all times. Even now, when it has to output to the server, these functions shouldn't have to use that much CPU.
In response to Multiverse7
Multiverse7 wrote:
Have you thought about using JavaScript hacks to power the mouse functions? You could add in the functionality, then check if the player actually has JavaScript support enabled, and then automatically configure your mouse procs based on that. So if someone doesn't have it enabled, then the game will backfall to DM's native mouse functions. I think it would be easy to check for JavaScript. You would just have to test it out, then check for null values. I have been thinking about implementing something like this myself. In an online game, if you can take advantage of whatever amount of JavaScript support the player base has, then it will take that much weight off of the server, and result in less lag, while still supporting everyone with the built-in functions.

Multiverse, you must be confused. HDK's Mouse and Keys library is excellent, but it's completely irrelevant to the problem at hand; Mouse tracking is not used whatsoever in this game, so using HDK's mouse and keys library will accomplish nothing but add more bloat to the project.

The problem here is when DreamSeeker has a high CPU usage, the mouse clicking functions will become unresponsive. HDK's Mouse and Keys does not provide functionality to alleviate this.

If you are suggesting that I use javascript to capture mouse click events and then send these to client.topic(), I'm certain that approach will not yield any performance improvements over the current native functions.
In response to D4RK3 54B3R
D4RK3 54B3R wrote:
If you are suggesting that I use javascript to capture mouse click events and then send these to client.topic(), I'm certain that approach will not yield any performance improvements over the current native functions.

Well, the problem seems to be pretty specific to the native mouse functions, so I have reason to believe that capturing through JavaScript would end up being significantly faster.
It wouldn't because capturing the mouse event through javascript will only give me the mouse coordinates relative to the screen (at best). This means that I would have to loop through all atoms within view and client.screen (And I suppose you can do a lot of pruning here based upon the icon dimensions) and determine which one was clicked.

I do not want to imagine how dreadful mouse drag and mouse entered would become.

I don't think this is the correct solution to this problem.
Is atom.Click() the only mouse proc you are making use of here? If so, there is something very wrong going on. That function is called whether it's actually being used or not, so if this is the case, then no, checking through JavaScript would not help at all.

D4RK3 54B3R wrote:
I do not want to imagine how dreadful mouse drag and mouse entered would become.

What are you talking about? If you used JavaScript, those functions would not need to be defined at all, and so any problem with them would disappear.