It's very slick and cross browser/platform at the click of a button, which is leading non-technical types to conclude the entire engine is intrinsically better than what we use now. Is it simply that they've taken the time to implement all the per-browser/OS plugin versions of Unity WebPlayer and polish it, or is there anything deeper in the way the engine architecture is set up?
Unity takes scripts written in C#, UnityScript (based on JavaScript), or Boo (based on Python), and compiles them into mono assemblies. Those assemblies + the 3d models, sounds, and textures required by your game are compressed into a .unity3d file that is loaded by their browser plugin. Since almost all of the game's logic is in managed mono assemblies it runs cross platform with very few platform specific quirks.
They've recently rewritten their plugin detection and installation code so that it is very easy to drop a block of javascript into a web page that shows Unity content if the user has the plugin, or other content (image, flash, video) if they don't. I believe their plugin supports all A-class browsers on Mac and Windows, and the plugin can be installed without restarting the browser.
One advantage of the Unity engine is that you can take a lot of off-the-shelf managed assemblies and include them in your project and call them from Unity code. But you have to be aware that these assemblies can really bloat the size of the .unity3d file.
Another advantage is that you can easily write components that expose tunable parameters that can be modified by non-technical people.
And yet another advantage is that a well written project can be ported to/from iPhone, Standalone, Android, Web, etc. in under a day. I've personally done iPhone to Web by just modifying my input handler and changing texture compression.
One big disadvantage is that since the application is running managed code it is not too difficult for a curious or malicious person to decompile the assemblies into completely readable code. So you need to think about what someone could do with that info (cheat in multiplayer, write bots, falsify high scores, etc.). It is possible to obfuscate your assemblies, but it isn't trivial to add this step to your build process.
Related
Everything that I have coded upto this point has been launched from Command Prompt or the IDE itself. I would like the ability to deploy an application such that launching it doesn't require a tutorial for novices. .exe, .apk, .app, ELF. Double-click and go.
I recall creating .exe files from Python as being restrictivly difficult. I was thinking C# and found .net/maui. It doesn't support linux, which I could maybe look past, but it also doesn't appear to support creating .exe files.
Java is more low level than I would like to deal with. Learning a new language that runs virtually could be the solution. I havn't done much investigating as this wouldn't be the ideal. (Edit: JVM requires an additional install, so that's not going to work.)
I don't have any experience with web developement, but it seems like a promising route none the less. It is not clear to me if I can create a local icon-launchable webpage that will run an application in your browser sans-server. Additionally, I am not sure how far my known languages will take me before I have to then learn CSS or whatever.
Thoughts?
Electron seems to be popular choice for cross-platform development in case you don't mind developing with JavaScript.
QT is another cross-platform framework that was around for a long time.
Specifically for .NET, there's MAUI (mobile-focused, no Linux), Avalonia UI, Eto Forms, AlterNET UI. The last one is desktop-only and still in beta.
I have found that there are plenty of frameworks for browser plugins.
my first question:
which one of the following frameworks specified for plugins and which one is not specified for plugins:
FireBreath, OpenForge, Kango, BabelExt, Nixysa project, JUCE project, QtBrowserPlugin project .
my second question:
Is there another popular plugin's framework other than those mentioned?
my third question:
What is the main differences of these popular plugin's frameworks?
Indeed is there any comparison of these frameworks, the comparison could be in each of following terms:
usability (for a page as a NPAPI plug-in or for a browser as an
add-on extension),
simplicity (in developing),
speed (on execution),
extensibility (of developed add-on),
availability (in Windows 86x and 64x, Unix, Linux, mac and other
platforms and also mobile platforms specifically android, ios, ...),
flexibility (for new technologies),
reliability (in terms of security),
accessibility (open source or not),
portability (in Fire-fox, chrome, IE, Safari, Opera, ...),
applicability (in drawing, communicating, calling from external
server, threading, network accessing, etcetera),
stability (in changing the policies, for example in deprecating
NPAPI)
Also I have read Cross-Browser Extensions API? which I think it is about extension's framework (not plugin's framework)
I'll be honest -- this seems like something you should be able to answer with some google searching. I appreciate that you're at least trying to apply suggestions on how to better ask questions, though, so I'll respond on the few that I know something about.
FireBreath is a C++ framework for creating browser plugins, not extensions. It works as an NPAPI plugin for browsers supporting NPAPI plugins (previously this was all but IE, but Chrome dropped support for them this year and Firefox plans to at the end of 2016) or as an ActiveX control, giving it equivalent functionality to a browser plugin in Internet Explorer. FireBreath 2, which is working but poorly documented so far, changes the APIs from being synchronous between the browser and plugin to being asynchronous and adds an emulation layer to let them work with Google Chrome using Native Messaging. It's the most complete and up to date of the plugin frameworks, as far as I am aware. I am its primary author, so feel free to get your own confirmation of that.
Nixysa is a tool that takes definition files and outputs code for a NPAPI plugin. I haven't used it, so I can't tell you exactly what it's capabilities are. It hasn't been updated since 2012, when PPAPI support was added; this is unlikely to be useful, though, since PPAPI has changed significantly since then, and also since the only PPAPI plugins that can run without special command-line flags to chrome are ones specially blessed by the Chrome team.
JUCE is a GPL library with a commercial licence available which has some support for creating browser plugins. I have no idea as to how powerful it is these days; it seemed well written when I last looked at it, and takes a much more minimalistic approach than FireBreath does; FireBreath gives you a framework and tries to make everything Just Work, whereas JUCE seems (I could be wrong) to be more of a "provide the building blocks, but don't try to make everything look the same" type of thing.
QtBrowserPlugin is a defunct unmaintained project which at one time allowed creating browser plugins (probably just npapi, but not certain) with QT. Indications are that it probably doesn't work anymore.
I have no idea what the other projects are. If I were you, I'd try doing some research. Google is your friend.
I wish I could pose more specific questions on this topic, but what I'm really looking for is a bird's eye view - a blog post, something from Adobe, documentation or even a book that outlines an approach, because I've had a tough time finding something comprehensive.
I've primarily been developing in a 2 man team with Flash Pro for years - an artist and developer. I've also worked in larger teams, using the same workflow:
AS code written as class files using Flash Pro editor, with minimal code on the timeline (only stops and an occasional function call when the timeline hits a certain frame).
Library assets are linked to AS3 classes where needed
Assets are placed on the main stage & main timeline, for maximum convenience of the designer.
Apps are published and built by exporting to swf with Flash Pro
No source control whatsoever except telling each other if we are going to change the fla.
Our shop is on the verge of bringing in more coders to develop a series of Flash browser games, and I'm thinking it's time to bring this workflow into the current reality. We'll want to have something that suits both artists and coders (minimizing complaints from either camp), as well as git support for source control.
Finally, my questions:
How are most developers authoring games currently? I've read a popular approach is to create art assets in a fla using Flash pro, link them to classes and export to a SWC. Code is then developed in Flash Builder, where assets are embedded.
If I take the SWC approach, is all code stripped from the timeline of MovieClip assets?
I'm aware that Flash Builder has an option to create a 'Flash professional' project which integrates the two and seems ideal, but going back and forth between Builder and Pro seemed to be crash prone. Does anyone use this approach reliably?
Will CS6 give us any advantages over CS5.5 to make it more developer friendly; ie. code-completion, etc.
Is there a way to set up workflow so the artist could make changes and then build/run the game from Flash Pro, and the developers could do it from Flash Builder - or would everyone need Flash Builder to run?
Are there any good 3rd party tools that provide code completion and an all around better development environment then the flash IDE (as an alternative to Flash Builder)?
Do people see Flash Builder as a 'must have' when working in teams or in general Flash dev?
Thanks for answering any part of these questions, or just simply sharing your experiences, opinions, and personal preferences. Any knowledge will be a big help at this point!
That is a lot of questions for one question. I'll try to somewhat cover the main topic of workflow.
The approach you describe with a pure ActionScript project with swc:s linked in is probably the most common approach (at least when it comes to more complex projects) as you want to separate code from content as much as possible. Usually I work with one artist so we sync up on functional design and then I define how the scene objects should be structured (i.e. a container clip, with XYZ child clips, naming, linkage and everything) to make it fit in with current framework or new supporting code.
You do not want any code in the flash pro timeline whatsoever, you want it all in your ActionScript files. Ideally as a programmer you shouldn't have to go into the flash scene project. However, in reality you probably will. I usually try to keep this to my own placeholder scene so I don't contaminate the production files with test and placeholders. You also really don't want several people editing in the same scene at once. One approach is to split up into several different scene projects. If you make a card game you could have something like this: card.swc, mainScene.swc, opponents.swc. That also allows for some concurrency if you are working with multiple artists.
Keeping the flash pro files in xfl format makes it a bit more source control friendly and you could actually merge two versions of the same scene but it can be a bit complex at times.
I usually solve this by making quick functional placeholder graphics that can later on is replaced by an artist (or render graphics from code).
When it comes to IDE:s, I think the most popular ones are FlashDevelop, Flash Builder and IntelliJ IDEA (With Flash Builder as my personal favourite). Get started with one and try some of the others in due time. Make sure the functions you use all day long are really good. However, if you have only been working with the flash professional environment before anything will be a drastic improvement on productivity.
I for one prioritize searching, refactoring and ease to follow the program flow, which simplifies debugging and getting into other peoples code quickly. But it all really comes down to finding a tool that runs on a frequency you can tune your mind into.
I hope that answered some of your thoughts and questions. Do not hesitate to follow up with more of them.
I am currently working on a small project in QuickBasic that requires the use of MIDI files.
As the DOS environment I'm using DOSBox 0.74, which provides emulation of the Gravis Ultrasound card.
So far, I've been able to access GUS only by using the PLAYMIDI.EXE file in the C:\ULTRASND directory. However, it is impossible to launch it from inside QuickBasic: the SHELL statement creates a child COMMAND.COM process, so when PLAYMIDI.EXE starts playing in the background the child process finishes and terminates, and the music stops. All of this means that the only way to launch PLAYMIDI.EXE is through a batch file before the actual program, but it also means that there is no way to control the music from the QuickBasic program. Edit (Jul 24, 2011): It is actually possible to launch it using SHELL (my mistake), but the TSR version of PLAYMIDI.EXE takes a lot of memory, so there isn't enough left for my program. The question still stands.
Therefore, my question is whether there is a Gravis Ultrasound library for QuickBasic available.
Edit (Jul 19, 2011): Might be in another language as well, as QuickBasic can link those too.
P.S. Sound Blaster library available here, but I don't like the sound it produces.
Resources
libTiMidity: http://libtimidity.sourceforge.net/
Assembly Gravis Ultrasound library: guslib11.arj
Assembly tutorials (including QBasic): http://www.petesqbsite.com/sections/tutorials/assembly.shtml
Direct Sound 4 QB++ : ds4qbpp12.zip
Bells, Whistles and Soundboards: bwsb.zip
QMIDI 4.1: http://www.phatcode.net/downloads.php?id=191
As an huge fan of QB, I'm happy to see someone still using it. So I made it a point to find an answer for you. Here's what I've found. There is an ASM Gravis library on this page. Using the ASM tutorials, you should be able to combine the two. FYI, here's another great resource. Good luck.
You could look at DS4QB++, which allows you to play music and sound effects using the Windows API. I haven't tried it with later versions of Windows though. There's also BWSB which is DOS based and can play MOD/S3M files. Both available on my old QB site:
http://piptol.qbasicnews.com/files.htm
QB64 uses TiMidity, i guess via _SNDOPEN.
I am on searching special features of GWT which are present only in GWT and not in other web framework. I am a student and I am not well acquainted to the many web frameworks on the market, so if u can help me increasing my list of special GWT features, it would be a great help. Some which i know are:
1. GWT allows using java to program
web. (only, it also allows merging
javascript through JSNI of course)
2. The developer does not have to be a guru in browser incompatibilities
to develop web sites which works on
a variety of browsers because
incompatibilities are handled by GWT
through differed bindind
3. GWT allows easy integration of popular Java Tools such as ,
hibernate through gilead
4. GWT enables server implementation not only in java but also other
languages such as php
5. GWT enables code splitting which improves application interactivity
by allowing javaScript file to
download only when required
6. In essence GWT is toolkit, it does not force a way to program,
other layers can be placed on top of
it to program such as placing MVP or
MVC framework on top of GWT and then
develop app
7. GWT MVP is great because first it allows collaborative working, faster
testing with JUnit and the event bus
allows many updates in client side
application by placing event on the
event bus
8. GWT compiled java files to obfuscated mode which is first small
and make the application safer
because bots fails on the javascript
generated during the obfuscated mode
In case in the 8 points, i've mention something which not special to GWT, then let me know.
There's also 'perfect caching', which is the term used to describe the way that GWT optimises JavaScript for each browser.
Instead of building a large JavaScript file, with code that can handle all of the various browsers, GWT builds multiple JavaScript files at compile time, and downloads only the one that is relevant to the browser type that is being used.
EDIT: Every time you make a change to your Java code, GWT changes the name of the corresponding JavaScript file. Web servers can turn on caching for the JavaScript files (so that browsers won't re-download the same file), assured that the name will change when the Java code changes, and the browser will then download the latest version.
EDIT: I also really like the CssResource feature. By creating obfuscated CSS style names, GWT effectively gives each widget its own namespace for CSS styles; for example, I could define a 'pretty' style name on two different widgets, and have those styles using different CSS rules. Of course, it is possible to share CSS styles between widgets too.
Image resources are cool too. They optimise the way that images are downloaded and accessed.
Don't forget internationalization.
I think you pulled together a pretty decent list of differentiators there already. I think that one point worth adding is the RequestFactory feature in the most recent release, which, if you will, is simplistically speaking and RPC for data and makes it quite easy to develop Create, Read, Update and Delete - type (CRUD) of applications.
There are other, more important/wider accepted GUI-Frameworks that are based on Java.
There are for example Struts and JSF. That's why some of your points don't fit only for GWT, but for all GUI java frameworks in general, e.g. bullet point 1, 2 & 3.
But to add another one:
I think GWT is an easy way to code an AJAX-application, because it hides the AJAX stuff quite well. Wouldn't you agree?
Furthermore, GWT is a proprietary framework (which is somehow a unique property). JSF is standardized and Struts is lead by Apache.