I'm studying JavaScript because I want to make voxel games (like minecraft type style) eventually. I've been told to use WebGL, but I've seen a lot of examples of minecraft type games using voxel.js.
So which should I use? Which one is better for voxel based web games?
"Which X is better" is rarely a good question. It depends on what you're trying to do, what you already know, your personal tastes, and a lot of other things.
That said:
voxel.js itself uses WebGL.
If you don't use voxel.js, you're going to have to roll your own voxel framework. That's a significant undertaking that will distract you from focusing on gameplay.
I haven't coded anything significant with voxel.js, but I've experimented with it, and it seems to be really solid. Also, it's still under active development, so its capabilities will only grow. Unless you need a specific feature that someone hasn't already written a voxel.js module to handle - and you don't want to write that module yourself for some reason - using voxel.js is the sensible choice.
So I'd say, don't reinvent the wheel. There's already a free, high-quality solution to your problem.
Related
I know javascript, but I've never learned any libraries or frameworks. I've never used jQuery or Phaser.js or anything like that.
Would it be better for me to spend the time and learn how to use Phaser, or are there actually benefits to handcoding it in javascript?
It's a top-down, 2d, action/adventure dungeon crawler. I know pretty much how I can build the whole game using mostly-simple javascript. But I don't know if doing it this way will inherently make the game more dense and cause it to run slower, or lead to more bugs. On the other hand, maybe it will do just the opposite. Will straight javascript run faster than if I used a framework?
I'm not a master of Javascript. I'm closer to a beginner, but I've made at least 30 or 40 games on codeless softwares like gamemaker and stencyl. I'm familiar with game programming and I've made one game before in Javascript. I know I did a lot of things incorrectly on that first game, So maybe a framework would help?
The main benefit of doing something yourself is that you will learn - but it will be a much slower process.
Everything will take longer.
Will straight javascript run faster than if I used a framework?"
If you do it from scratch you can invest a lot of time optimising the specific things you need. This time may not pay for itself if its something the framework already does reasonably fast.
I think there's a tremendous benefit to understanding the raw language, DOM API, event model, etc. Every framework has leaky abstractions that will be much less painful to deal with if you understand the (imperfect) language and DOM.
My advice would be to give bare JS/DOM a try first, but understand that both have a lot of legacy baggage. If that's too painful, try something that abstracts SVG/Canvas or whatever you're planning to use for your game.
I was thinking about making a game using as3 and javascript together but i have yet to see any. i know that the two languages can work together but i can't find games that use them both.
If anybody could tell me about any games like this or if it is somewhat impossible to do so could you tell me why?
Not that I am an expert from what I understand they cannot use the same canvas and it is almost certain that communication between the two languages will be slow. So any game is almost certainty going be made in one or the other as it would be far easier and better overall to just pick one language. Now if you need JS to do the networking while flash does the rendering and game logic I know a friend of mine was looking into doing something like that. But I would classify that as a Flash game that just happens to need some JS on the webpage to run right.
Maybe you should clarify what you mean by "making a game using as3 and javascript together"
I agree with all the comments so far and I think it's worth thinking about whether or not you can accomplish what you're trying to do with either one or the other without using both, that should probably be your course of action.
As for original request for an example, this is (at least so far) by far the coolest example I've seen so far. It's a Pong game where one half of the board is Flash and the other half is HTML/Javascript. It's worth noting this example makes use of the <canvas> tag and therefore can only be accomplished using HTML5, but it's still pretty sweet.
http://labs.codecomputerlove.com/FlashVsHtml5/
I tend to agree with #Jonathon. Say you want to have a set of html controls that drives an option set for a flash game... maybe those controls are integral to gameplay.
Well, great. ExternalInterface is robust and powerful, but why use it in a situation like this?
Flash is robust and powerful by itself, and doesn't necessarily need any help to do much of anything. I will definitely run some javascript to plant the swf on the page, assist in networking, or set some default variables, but beyond that, flash doesn't have much to gain from reliance on other tech (save for server communication). Certainly not speed. I think you don't find many "true" dual tech apps like this for precisely this reason.
A bigger question, that is more apropos: do you need flash to accomplish your goals? I love working with flash, but if native browser tech can accomplish the same goal, then its an unnecessary layer. And if it can't, well, then Flash it is.
For the time-being, as far as games are concerned, frameworks like tweenlite, pushbutton, flint etc... still give flash a convincing lead.
Cheers
I am new to computer programming and have some experience programming with python. I am thinking of developing a program that does physics simulations (projectiles, circular motion, damped simple harmonic motion systems etc.) as a hobby project. I would like to write the program that it could be run by a non-technical user(my fellow students) on a variety of platforms (mac, windows etc.) without any setup and python doesn’t seem to be a good option for building such a program so I am looking for an alternative. JavaScript has caught my attention, as it seems to be quite powerful on modern browsers, especially in conjunction with HTML5. I would like to know whether it is suitable to use JavaScript for this type application, and some information as to where I should start (I have no JavaScript knowledge)
Thanks in advance!
Yes I did have a look at the similar threads on the site but I want write something by myself than using a 3rd party library (other than for the frontend, if possible) :)
What is actually your question? :)
Can you write a physics simulation in Python?
Yes, of course.
Can you write a physics simulation in Javascript?
Yup.
Will it be useful?
Yes, probably.
Will it be efficient?
Not as efficient as an implementation with C, to be sure. But for small-scale simulations should you should have quite enough power with current JIT javascript interpreters. Tens or hundreds of objects on 30fps looks like a safe approximation, I think.
Can you make use of modern HTML when writing a physics simulation in JS?
The simulation and the display are two different things, but yes, if you want to make a graphics frontend to your simulation, the modern features of HTML and CSS could be certainly useful. But if you write it in any other language, you still have nice choices for visualization.
How to learn JavaScript?
There's plenty of tutorials online, but I don't know any particular one to recommend; perhaps anyone else can fill for me here.
As mentioned by Kos languages that are as High Level as Python or Javascript might constrain you. But later on you can still move critical parts to C-Code. (-> Regular shared Library or even Browser-Plugin)
For JavaScript I recommend you the Mozilla tutorials: https://developer.mozilla.org/en/javascript
Check out the "JavaScript Guide" in particular and keep in mind that not every Browser supports JavaScript 1.7. By the way, you should also checkout jQuery. Actually it might be easier to start right off with jQuery because you need some highlevel library anyways.
By the way: You might also want to check out Processing. (www.processing.org) It might be perfect for you as you are new to programming and it has a lot of awesome vizualization features. It basically a simplified Java with a very easy to use library. You can checkout the pre-installed examples and start playing around. Be sure to check the Reference on the website / the forum if you are stuck with problems. Processing runs on the JVM and is therefore cross plattform.
I recommend Processing very much because you can directly see results and in any case it might be interesting for Prototyping even if you think of using another language in the future to suit your needs.
Actually there is even a JavaScript version of Processing though I never used it...
EDIT: If you plan to choose JavaScript, you should use Firefox in combination with Firebug. It makes life easier when debugging...
I am holding back on seriously pursuing ProcessingJS pieces mostly due to the bloat of the library. I have found that pieces like Ball Droppings do not use the library's Processing syntax parser, which is good, since I imagine it would slow down the page more, especially adding to the initial load and setup time. Still, I am wondering if it's worthwhile to use it basically as a big utility library like UnderscoreJS. For example, how good is its implementation with SVG compared with the other libraries out there today like RaphaelJS? Has anyone gone through the implementation of the Processing API extensively enough? When I skim through the I see a lot of boilerplate I don't really need, as well as a couple instances of questionable coding practices. But the library still seems to perform decently, at least on the ProcessingJS homepage, although the examples are set to run at 15fps, and not the (in my opinion) minimally acceptable 24fps.
I think it strongly depends on the project you are working on and the background knowledge you have with the processing library.
Processing.js is a great choice if you already have learned the original processing api (java) and want to leverage your existing knowledge in the web environment. It might be the only choice if you want to port an existing project to the web - actually this is probably the best time to use it.
If you are a JavaScript programmer and don't know much about processing you probably will dislike to write Java syntax in the browser and everything becomes even more problematic if you have to mix it with js. The API doesn't feel like JavaScript and there is a lot of code that could be written more elegantly.
Regarding performance it is not a bad choice, actually most projects run smoothly and I can definitely recommend using processing.js on circumstances like those explained above.
Here is great list of various javascript engines out there:
Javascript Graphic/Game Engines
It is hard to recommend a single library, as the requirements are specific to each project.
For simple graphics/diagrams: RaphaelJs is really nice and performs decently
how good is its implementation with SVG compared with the other libraries out there today like RaphaelJS
Processingjs doesn't use SVG as far as i know, it only uses canvas. Raphaeljs only SVG. There's an interesting read here and also at wikipedia about the difference. The main difference is SVG stores the vector data of objects so you can easily change position, colour, etc... of stuff but also provides mouseover events. Canvas - and processingjs - does no such thing, it draws to the canvas and forgets everything so you have to do more work. Don't know about performance difference between the two.
As far as the processingjs API is concerned, I don't have any clue as how it is implemented but since John Resig of jQuery is involved it can't be that bad to say the least.
I agree with user hlfcoding that writing java in browser feels weird. I am too looking for a cleaner solution for my future canvas experiments.
I fail to see how re-rendering for each frame in JavaScript can be seen as performant.
That's exactly how canvas works, you have to calculate and render every frame in js, it's not processingjs specific. I don't think that's such a performance hit, behind the scene a browser running SVG does the same anyway.
I want to use a javascript framework with MVC for a complex web application (which will be one of a set of related apps and pages) for an intranet in a digital archives. I have been looking at SproutCore and JavascriptMVC. I want to choose one framework and stick with it.
Does anybody know what the distinguishing features are when comparing these two?
I want something that is simple, straightforward that I can customize/hack easily, and that doesn't get in my way too much, but that at the same time gives me a basis for keeping my code nicely organized, and event-driven. I also plan on using jquery substantially.
I know sproutcore is backed by Apple, and looks like it is getting more popular by the day, and it has a nice green website :), whereas JavascriptMVC looks less professional, with less of a following and less momentum behind it.
I've done the tutorials for both and I was impressed by SproutCore more (in the JMVC tutorial you don't really do anything substantial) - but somewhere in the back of my mind I feel that JMVC might just be better because it doesn't try and do too much - it just gives you MVC functionality based on a couple of jquery plugins, and you can use jquery for everything else, so its flexible. Whereas SproutCore seems to have more of its own API etc... which is also nice in a way... but then you're kind of stuck within that.... hmmm I'm confused :).
Any thoughts would be much appreciated.
Being a JavaScriptMVC contributor, I'm extremely biased. But I'll try to give the best answer I can.
JavaScriptMVC has also taken years to develop. But instead of focusing on ui functionality, it focused on the layers just below that. There are a few reasons for this:
You can find a jQuery widget to meet almost every need. There's no reason to compete these plugins. Instead, JavaScriptMVC tries to work with them.
Most people need one or two custom widgets / controls. JavaScriptMVC wants to make building and maintaining these pieces as easy as possible.'
Flexibility+API. I'm not sure exactly how to say this one ... but here's my best shot ... With JavaScriptMVC, we wanted every layer of the application to be as easy to understand and maintain as possible. This is why we picked jQuery as our low-level library. It's API is about the best abstraction for the dom possible. People typically go directly from the low-level API to build the Widget/Control. This is why most jQuery widgets' code look very dissimilar. We wanted a middle layer that organize our code and promote best practices, while providing enough flexibility to meet almost any requirement. So with JavaScriptMVC, you get very solid low and middle-level layers. But, you don't get widgets.
JavaScriptMVC has testing, error reporting, and documentation baked into the framework. The testing is the most impressive part. It has integrated selenium and envjs testing.
My recommendation would be to go with SproutCoreif your requirements can be built pretty straightforward with SproutCore. But if you know jQuery, have to build a lot of custom controls, or need really awesome testing, use JavaScriptMVC.
Funny, because just a month back or so, our team evaluated exactly these 2 frameworks head to head. We ended up choosing JavaScriptMVC, and I've been working hands-on with it for about a month.
I like it ... but, I was a HUGE proponent of SproutCore. I had never heard of either framework before we eval'd them, but once I saw SproutCore and looked under the hood, I was very, very impressed. Honestly, I don't think there's anything out there that can give you the kind of power it gives. Yes, you'll have a learning curve, but it's the kind of thing that lets one person accomplish the work of 5 or 10 once you know it.
So I'd use SproutCore in a heartbeat.
That being said, JavascriptMVC (aka "JMVC") is nice. It doesn't really give you a ton on top of jQuery itself. You will still have some infrastructure to build yourself (depending on how complicated your requirements are). This is both a pro and a con. One nice thing about it is that, if you need to dig into the details of some piece of JMVC, you can ... it is not so incredibly huge that it is impenetrable.
In summary, there's not a thing wrong with JMVC. But there is, in my opinion, nothing even in the ballpark with SproutCore.
I think that the main difference between them is that SproutCore includes a GUI while the JMVC is something low-level without any graphic, so if you need a GUI you can't use JMVC without including other scripts like the jQuery UI or jQuery plugins.
You said that "JMVC might just be better because it doesn't try and do too much" i don't agree with this, it took years before SproutCore 1.0 was released, so developers had the time to make a great product.
I suggest you to use SproutCore, maybe you'll have to learn more things, you'll spend more time to practice and understand everything, but you'll learn how to use a very good framework that can be usefull also for future projects.
Sproutcore-2.0 eliminates the ui-constraints and plays nice with completely custom app-uis.
http://blog.sproutcore.com/announcing-sproutcore-2-0/
http://blog.sproutcore.com/dispatches-from-the-edge-dropping-in-a-sproutcore-2-0-application/