Hi

You have several options, I'd say that there are 2 that are quite common:

1) The easiest way (but not necessarily the best way) is to have a main game which is a WADE App, and each sub-game is its own App with its own html file. From each game you can use wade.loadPage(url) to load a new html file with a new game.

Pros: It's easy to manage your code with lots of small, independent files. You can be sure that there are no memory leaks across different games (the whole JS virtual machine is reset when you load a new page and memory is freed).

Cons: If the games need to talk to each other (to share some info), you may need a custom server-side script to achieve that. Sharing code across different projects can be a bit tricky (still less problematic than sharing data)

2) Do everything in a single App, but each sub-game is in a separate behavior file. To start a sub-game you create a SceneObject with the game's behavior which, when added to the scene, clears the scene and initializes the new game.

Pros: It's easy to share data and code across games.

Cons: You have to be careful about memory usage, remember to free memory e.g. for images that you don't need anymore. 

To free memory, you can use wade.unloadImage(), wade.unloadAudio(), wade.unloadAllImages(), etc. This releases all the references that WADE may be holding to the images, sounds, etc. so the browser knows it's OK to free memory. However, if you are storing those references somewhere else, the browser won't be able to free the memory. So for example if you have a global variable like this:

window.myImage = wade.getImage('somePicture.jpg');

Then the memory for it won't be freed when you call wade.unloadAllImages(). Unless you also do

window.myImage = null;

Also remember that ultimately it's the browser that decides when it's time to free memory. The fact that some memory isn't being used doesn't mean that it will be freed right away, the browser will decide when to do that at some point in the future (sensible browsers do this within a few frames, none of them do it instantly).

The same thing goes for SceneObjects and Sprites, although they are very tiny objects. If you don't store references to them, just doing wade.clearScene() will get rid of the memory used by them.

 

 

The states of ios and android could be managed? (the player pause the game,etc.)

When the game's tab looses focus (for example it's minimized), the game/simulation is automatically paused after a couple of frames. However if you want to control what happens (stop sounds or whatever), you can do:

window.onblur = function(){    // what happens when you loose focus};window.onfocus = function(){   // what happens when you get back};

This should work on any platform, including ios and android.

There is no tutorial about this stuff (yet), but feel free to ask any more questions you may have.

Thanks for those answers. Your support is really excellent.

I don't think to do a browser game but to use Ejecta, CocoonJS or something similar. With those platforms can I share info beetween sub-games more simply? which is the best one in compatibility with Wade? I want to do a game for ios and android that uses In-App puchases but it's my first game so I'm becoming confused because I don't find complete informations about doing html games and become a mobile html game developer. Can you suggest me a path considering I want to use Wade (and Wade isometrical)? (books, tutorials, etc.)

Thank you!!

Both Ejecta and CocoonJS are excellent, but I'd say that they're more suited to small, simple games. From what you said, it sounds like your game would be quite complex, but I don't really know.

Ejecta and CocoonJS dramatically increase the performance of your game on mobile devices, but there is a "price" to pay for that: you can only do a subset of the operations that you can do in a browser environment. For example, if using CocoonJS, you definetely want to use a single layer for all your sprites (using multiple layers slows things down considerably). And you definitely want to avoid any vector graphics and custom draw functions (very few of the functions in the wade.drawFunctions module would work with it). So basically you are restricting yourself to plain bitmap-based sprites, and even drawing text can be a bit problematic if you want to have some effects on it like shadows.

To some extent, the same is true with Ejecta. These may look like minor limitations, but in reality if your game is quite complex, they become really annoying. For example, what if you need text input? Like players having to input their names, or sending a chat message to other players? It would be a nightmare on those platforms, whereas it may be quite straightforward in a normal browser environment.

The downside of a browser environment is that it's slower. On the plus side, it supports a ton of features that CocoonJS and Ejecta don't support. If you use CrossWalk (for Android) and PhoneGap (for iOS), you can basically make an app that runs in a browser environment (although it's full screen so the user doesn't know about it), which is Chromium on Android and Safari on iOS. But like I said, it's slower, especially the drawing part. It may not be a problem depending on what you are doing (for example if the camera doesn't move too much), and also depending on when you are planning to release your game. That is, it may be slow on today's low-end phones, but it may be OK on the low-end phones of next year.

Regardless of the solution you choose, the gap between being an HTML5 game developer and a mobile game developer is tiny: you just make a HTML5 game, and with a wrapper it just works on any mobile platform. WADE, like most HTML5 frameworks, hides the complexity of doing mobile-specific things (for example it maps touch-screen events to click events, handles device orientation, motion, screen size, calls different functions on different platforms, etc). If making a mobile web app, you also need to be conscious about some operations that are slower on mobiles, like drawing lots of pixels per frame. WADE has a layer system and some extra functions specifically to help you with that. But ultimately, it comes down to your own experience. Continuously test your game on mobile as you develop it, so you can spot anything that makes it run slow early on, and find a workaround.

Anyway, that is all strictly client-side. It sounds like you are also going to need your own server for this type of game. You probably want to store the items that a player has purchased in a database, or something like that. So if you have your own server, exchanging data between two games won't be a problem, because it can go through your server: a game sends a message to the server with some info, the next game asks the server for that message. You would normally achieve this by using wade.preloadJson() to exchange messages in JSON format with a server.

Regarding tutorials and learning material: it really depends on what type of game you are making. The step-by-step guides that come with the samples on this website cover most of what you need to know about WADE (including isometric), so all client-side technology. They don't really go into any depth regarding JavaScript. For that, I'd recommend this on-line book. It also covers a bit of node.js, which is what you probably want to use for your server-side stuff, maybe together with socket.io - but this depends on the type of game you want to make.

 Hi,

I'm going read the online book you suggested.

Thank you!!