Maybe I should serenade you about our game's almost entirely database-driven game logic ;)

In response to Lavenblade
Lavenblade wrote:
An engine is only as 'powerful' as the programmer.

Nice, I think I've hit the cap with DM with my current knowledge of math.

JS opens up alot more possibilities for me as well.
Nice, I think I've hit the cap with DM with my current knowledge of math.

JS opens up alot more possibilities for me as well.

Fair warning:

JS is actually in many cases slower than (well written) DM unless you are very, very good. The major problem with DM is that it is server-side. JS has more resources available to it for distributed purposes so it generally seems to have a speed advantage.

If you don't understand a lot of JS-specific concepts that don't apply to other languages, and don't learn modern EMScript techniques that almost no one teaches, the entire language is just about nonsense.

The trick to writing clean/fast javascript games is doing as little as possible and trying to offload as much work as possible to native implementations exposed to the language.

Note: This does NOT necessarily apply to Unity. Unity's Javascript doesn't actually run EMscript, but instead compiles the language into a modified version of the MonoVM.
You could probably get away with having only the amount var instead of amount_range, if you allow it to be a string. Assume any string is a dice roll and send it through roll() to get an amount, so you could have "1d3" or "2d4-2" as amounts. (Checking for negatives would of course be necessary.)


Testing the hitboxes. The little guy also has hats!
In response to Bl4ck Adam
I think you mean hitbarrels.
In response to Kozuma3
Kozuma3 wrote:
Lavenblade wrote:
An engine is only as 'powerful' as the programmer.

Nice, I think I've hit the cap with DM with my current knowledge of math.

Master math and you've mastered DM? Who would have known?
In response to Bl4ck Adam
Love the look. Looking forward to seeing more.
In response to Lavenblade
Lavenblade wrote:
Kozuma3 wrote:
Lavenblade wrote:
An engine is only as 'powerful' as the programmer.

Nice, I think I've hit the cap with DM with my current knowledge of math.

Master math and you've mastered DM? Who would have known?

My thoughts similar.

@Flick: Same here.
master math lol
In response to Ter13
Ter13 wrote:
JS is actually in many cases slower than (well written) DM unless you are very, very good. The major problem with DM is that it is server-side. JS has more resources available to it for distributed purposes so it generally seems to have a speed advantage.

For V8 Engine and SpiderMonkey, that claim you've made is a bullshit lie, at the end of the optimization stage of V8, it's roughly only 6x slower than optimized C++ (probably faster now, that was several years old).

BYOND is by a large margin, very slower. Not to mention you can offload everything to workers and totally crush DM in performance.

Give me one example and I'll debunk it.

The trick to writing clean/fast javascript games is doing as little as possible and trying to offload as much work as possible to native implementations exposed to the language.

The trick is working with the VM and how it optimizes it.
In response to Bl4ck Adam
That jump though :c.

The amount of times I have had to change the collision system is ridiculous, but it gets better each time.
Purdy.
In response to Ishuri
Ishuri wrote:
The amount of times I have had to change the collision system is ridiculous, but it gets better each time.

Because the character is hunched over forward, you might want to re-adjust the north, west, and east based collision based on his head, and not his feet.
In response to Maximus_Alex2003
Maximus_Alex2003 wrote:
Ishuri wrote:
The amount of times I have had to change the collision system is ridiculous, but it gets better each time.

Because the character is hunched over forward, you might want to re-adjust the north, west, and east based collision based on his head, and not his feet.

That would require me to change his collision point based on his direction which can actually cause me to go through things if I don't add like 3 extra security measures on top of that. And I'd have to do it for every other mob which isn't really worth the hassle and doesn't really pass off more than this already does.
In response to Ter13
Ter13 wrote:
Nice, I think I've hit the cap with DM with my current knowledge of math.

JS opens up alot more possibilities for me as well.

Fair warning:

JS is actually in many cases slower than (well written) DM unless you are very, very good. The major problem with DM is that it is server-side. JS has more resources available to it for distributed purposes so it generally seems to have a speed advantage.

If you don't understand a lot of JS-specific concepts that don't apply to other languages, and don't learn modern EMScript techniques that almost no one teaches, the entire language is just about nonsense.

The trick to writing clean/fast javascript games is doing as little as possible and trying to offload as much work as possible to native implementations exposed to the language.

Note: This does NOT necessarily apply to Unity. Unity's Javascript doesn't actually run EMscript, but instead compiles the language into a modified version of the MonoVM.

Aaiko's Vylocity is what I'm using as it's just like BYOND, JS will just help me get a better understand, and I can use it directly in the IDE o:
Vylocity uses VyScript, which is based on JavaScript if I understand properly. Meaning it's not actually JavaScript.

Edit: You can use JS in DMs IDE too.
In response to Lavenblade
Lavenblade wrote:
Vylocity uses VyScript, which is based on JavaScript if I understand properly. Meaning it's not actually JavaScript.

Edit: You can use JS in DMs IDE too.

Please stop being arrogant :)

I have a beta version of the lighting stuff up if anyone wants to come check it out, it's the server named v.6 BETA.

http://www.byond.com/games/DarkerEmerald/TLC
Page: 1 2 3 ... 162 163 164 165 166 ... 342 343 344

Login to reply.