Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Jul 2011
Offline Last Active Yesterday, 04:10 PM

Posts I've Made

In Topic: Is it inefficient to use Unity to turn 32kb of Javascript into a mobile app?...

22 August 2016 - 12:13 PM

They may not really need everything that std::string provides, but you may as well have it.


Hmm, its closer to pointing people towards Qt, just to use QString to concatinate two char* together ;)


But yes, I see your point but I still do see too many Javascript developers dragging in JQuery for very trivial things.

In Topic: Is it inefficient to use Unity to turn 32kb of Javascript into a mobile app?...

22 August 2016 - 09:57 AM

Followup Question: Is using a massive library for a single function also inefficient?  (I suspect it's a different process than what's going in with Unity.)


Personally I feel that dragging in a library just for a single function is a bad decision overall. It is not elegant and often causes problems with maintanance later on.


However... I must be wrong on this because I see so many Javascript developers drag in all sorts of crazy dependencies for doing extremely simple tasks. I am sure you have already seen the word "JQuery" pop up many many times on help forums. Always, without fail just to split a string, some weirdo will suggest JQuery.


But that said, I am in the fortunate position of being able to avoid working with developers such as these ;)



It reminds me of the time when someone dragged in the GLM maths library into our database project just to use the vec3 length function. The compiler we had on our build server didn't support such an old version of GLM and so when it came out why he had done this, It certainly didn't inspire much confidence in any of his later decisions. I think he later went on to use glm again, just for glm::detail::tvec1<T> or something just to zero initialize member variables... I did chuckle ;)

In Topic: Implementing PvP for a simple, non-trivial, javascript mobile game app

21 August 2016 - 04:20 AM

True if you are already using a lot of Javascript in your game, node.js makes sense so you can share some code.


And yes, most languages are better than PHP, certainly Python I find to be nicer. However I always recommend PHP because there is a lot more free hosting services that provide PHP than any other scripting languages. I guess I am cheap like that haha.

In Topic: Is it inefficient to use Unity to turn 32kb of Javascript into a mobile app?...

21 August 2016 - 04:18 AM

I personally don't like Unity, I find it time consuming and messy compared to other solutions but I know it has a lot of marketing behind it and many of my students do seem to like it.


Perhaps just be aware that Javascript in Unity (actually called Unityscript) and Javascript for web browsers are very different. So you might have to end up recoding quite a lot of your work if it is already standard Javascript.


You can make an app that just surrounds a web browser and run your game in that, it would work. I don't know what the components are called but you can pretty much just drag and drop it in using the visual designers.


Edit: What unity does for web exporting is convert its compiled .NET code (Unityscript/C# etc...) to C++ with il2cpp then it uses Mozilla's free and open-source transpiler to compile the c++ to very low level Javascript (asm.js). This is faster than normal javascript because it can be optimized well (although isnt very human friendly to develop with directly). The output binaries are very large because Unity, as an off the shelf product provides a lot of things even if you dont use them and doesn't strip out everything you dont need.

In Topic: Implementing PvP for a simple, non-trivial, javascript mobile game app

20 August 2016 - 08:19 AM

HTML5, or more specifically WebSockets does not allow a client web browser to host a server so regardless of if using Emscripten (via Unreal or Unity) or directly writing Javascript, it cannot work. You will need a server somewhere that can act as the game server for all your clients to connect to.


If you are interested in writing an app for phones or tablets, then these can of course host the server.


However, a slight hack you might be able to get away with if your game does not require much bandwidth to play: Use free Internet Relay Chat (IRC) servers to act as the "game server". Some of these support WebSockets or provide websockify proxies so that Web browser javascript can connect.


IRC such as irc.blitzed.org or freenode employ anti flood protection and limit clients to about 30 messages a minute. So if your game can get away with this, then it could work for you. I actually use this technique as a cheap and dirty list server for my multiplayer games.


If you need to scale up and host your own IRC servers one day (and remove the message cap) IRC is a standard (albeit pretty ancient though still popular) and you can find loads of very robust and tested open-source IRC servers.


As a rule of thumb, if your game is 2D, just plain Javascript and HTML5 canvas are often the easiest development platforms. If it is 3D then perhaps look at using an engine or perhaps Three.js (WebGL is a little too time consuming to use directly for most games). As for a database, then you are going to need a server anyway, perhaps use a RESTful type API in PHP and then SQLite? Loads of similar solutions here.