Is this a result of your choice?

Hi guys,

Today i just lost a game because the game started to lag non stop i had about 500 tanks on my screen and the enemy was hitting my commander and even after trying 50 time to move him away he wasn't responding at all the result is that he died without me begin able to move him away, I have literally watched him die without the possibility to do anything.

I really hope those kind of issue won't appear at all in the final release otherwise its unplayable, If the game lagg for a few hundred of tanks i do't want to think when planet or asteroid are supposed to crash each others,

I firmly still believe that webkit and javascript wasn't the right choice and hope that we won't be us (the customers) who will pay for consequence of this choice.

Illidan

Well what do you expect? report it and move on to the next bug.

*sigh* I'm fairly certain that neither the netcode nor the underlying server architecture is written in JS dude. Also, this is an alpha release, performance problems are part of the experience. If you think present performance gives ANY indication of release performance you're clearly unacquainted with alpha software.

The only thing that uses webkit (and JS) is the UI. The rest of the game is normal programming stuff.

Why are people bitching about javascript, the language as a whole is decent.

If the underlying problems had ever really been fixed, it would be. But the chief issue with a game like this (if it had been written with javascript in critical areas) is the terrible terrible memory optimization that Java has. Java is unable to allocate memory, it just dumps it into a pile. If the core game code was written using java it would rapidly run out of memory beyond small battles and there is nothing that they could really do to fix it. There are some work around hacks that can be done, but nothing solid.

Thankfully the core game code is not written in javascript. The only thing is the UI, as people said, and that will not impinge on the memory usage of units.

The game uses OpenGL cause it is cross platform.

This is from the Wiki:

OpenGL

OpenGL is a specification implemented in the C language, though it can use other programming languages. It is built on the concept of a state machine, though more recent OpenGL versions have transformed it into much more of an object-based system. As an API, OpenGL depends on no particular language feature, and can be made callable from almost any programming language with the proper bindings. Such bindings exist for Ada, BASIC (BlitzMax (often used to program games), PureBasic, Visual Basic), C#, Delphi, Fortran, Go, Haskell, Java, Lisp, Lua, Pascal, Perl, Python, and Ruby to name some.


So yeah, they're probably using 5 different languages to build the game.

Pretty sure Java allocates memory in ways that don't cause out of memory exceptions.

Pretty sure Java has very little to do with JavaScript.

Both are correct.

Let's rename Javascript to NotJavaScript so that there will be less dudes on the Internet.

How someone could make some kind of theory about a language when they can't understand the difference between java and javascript is beyond me....

I knew it, PA is written in FORTRAN ... we are all doomed. :shock:

Java and Javascript are similar like Car and Carpet are similar

Why do you think simulation lag would have anything to do with a frontend clientside UI?

Makes no sense.

The earth is shaken by your loss. A national tragedy.

*goes home and plays PA for another 5 hours

what if the carpet is shaped like a car and the car has the same pattern as the carpet?

Fortran is extremely performant, particularly on massively parallel systems. The vast majority of the code I run at work is Fortran90/Fortran95.

However, it really doesn't play nice if you want to develop in an object orientated framework, or if you intend there to be a lot of graphical rendering of your code. Plus, as fast as it can be under some circumstances, coding with it feels a little like going to your doctor with a problem, and him getting out a jar of leaches.

I very much doubt that any performance issues in PA are significantly at the fault of JavaScript. I suspect that many of criticisms raised of it in this thread are due to Minecraft players who heard that some of Minecraft's performance issues are due to being written in Java, and then assuming that means the same thing is happening here due to the webkit UI using JavaScript for some features.This is despite the fact that Java and JavaScript are completely separate, and the only reason they share four letters is because Netscape wanted to capitalise on the success of Java when they released their scripting language back in the 90's.

The webkit stuff only handles the UI elements. Things like health displays and economy status bars. The actual core simulation and the client-side rendering engine is not written in a web-development language. The simulation and renderer simply pass basic information to and from the webkit part for dynamic UI elements (e.g. how much metal the player has, or the health of a unit). I'm not an expert, but I imagine that overhead from running a webkit environment along with the simulation and rendering components is pretty minimal. If you can run a web browser window in the background of any other modern game, then the performance hit is probably less than that.

To get back to the OP, I have a pretty terrible internet connection and have noticed situations where the game starts to lag because hundreds of units are pathfinding. I monitor how much bandwidth each program is taking, and when I stop the 200 units from pathfinding PA's bandwidth usage (~80 KB/sec) cuts in half. That's a lot of tiny packets.

This is the sort of thing that will get optimized through development, and is nothing to worry about. Maybe in the future just ask if people are having similar problems instead of trying to find things to blame. I know it's frustrating when you're being competitive, but you have to cut some slack for a game so early in development.