Graal Forums - IOS servers question

Graal Forums (https://forums.graalonline.com/forums/index.php)

- PlayerWorlds Main Forum (https://forums.graalonline.com/forums/forumdisplay.php?f=15)

- - IOS servers question (https://forums.graalonline.com/forums/showthread.php?t=134268621)

IOS servers question

I have been playing the different IOS servers such as Era, Zone and Classic.
It has came to my attention that all these servers are set up the same. You can view profile, location of buttons, such as the chat, and grab, etc. All the servers also seem to not have any public baddies. I don't know if this is because IOS servers can't handle it, or the creators wanted the players to thrive on player interactions only.

ALTHOUGH, of what I've seen with Delteria, it looks like they are breaking the graal barrier so props to them.

My team and I are in consideration of attempting to start an Iphone server.

Aside screen size and limitation of looping scripts, what is needed to keep in mind when developing for a mobile device? Because of what I've seen, all the servers are set up the same.

Most of the are scripting-related and fairly obvious, but I'll re-re-post this here anyway:

Quote:

Originally Posted by cbk1994 (Post 1710521)

Not specifically related to screen size (most of those problems are pretty obvious), but here are some quick tips I wrote out a while back:

Quote:

Originally Posted by cbk1994 (Post 1698634)

There are some general common-sense guidelines for lots of players, and some specific things to keep in mind on mobile devices as well:

Use as few timeouts as possible. Try using scheduleevent when you need to schedule something, but avoid 0.05 second scheduled events, too.
Avoid as much scripting as possible in level NPCs.
Avoid as much scripting as possible in general.
Set player.ani directly instead of using setAni. This only works on v6/iPhone.
Design everything to be run by touch.
Keep in mind that there are multiple mice (contact points with fingers) and use the mouse ID included in touch events.
Use clientstats aggressively to profile your scripts.
Use as few timeouts as possible.
Use the new transitions in v6 when possible.
Use as few client/clientr variables as possible. If it's only needed serverside, store it in a player. variable.
Avoid quirky things like joining classes to the player clientside.
Do as many things serverside as possible.
Avoid triggers where possible for things that can be done serverside entirely (e.g. healing player while in a bed).
Avoid abusing SQLite. With so many players, you need to be careful not to use too many queries.
Avoid writing to files. Use player attributes to store stuff when possible.
Use as few timeouts as possible.

Remember that these are guidelines and not hard rules.

I'm getting the feeling I should use as few timeouts as possible. (sarcastic)

But it looks like what I had in mind in making is out of reach for mobile devices.

Do these same principles apply to let's say a facebook server, or perhaps even a html5 (if that ever comes to light with GS3)?

Quote:

Originally Posted by i8bit (Post 1721711)

The client-relevant recommendations will apply on any platform, even PC. I would suspect that the Flash and JS versions of Graal are still going to be much less powerful than the native PC versions.

I really don't know much about how powerful the NPC-server is on iPhone servers. I'm sure they're better than the ones the PC servers get, but with so many players you still need to mind what your scripts are doing. Abuse of SQLite especially is going to be a big potential problem on servers with tons of players as the potential for locking problems is huge. I would tend toward player flags even when SQL is a bit more elegant of an approach simply because they scale so much better. Save SQL for the things that would really benefit from it (e.g. guilds).

I haven't been involved in iPhone server development for a long time but I would guess that the attitude is still to be very conservative in the use of things like SQL and DB NPCs which don't scale very well.

Quote:

Originally Posted by cbk1994 (Post 1721713)

Could you elaborate some more on the issues with SQL? I currently have a bunch of core systems relying on it. I haven't experienced any issues with it yet but I also don't have a player base to test it with. The way I currently have it set up so it puts anything in a queue that doesn't need to be set in the database immediately which setting a flag can handle such as setting an item as equipped and then whenever I have something I need to verify is done such as items being removed or added I use logic to dynamically build a query and run it to prevent a bunch of unneeded request. I'm concerned about your claim that it locks up under heavy load as I know SQLite allows concurrent reads and writes and is even used is corporate applications that require it. I assumed properly indexing was adequate enough. Is it just an issue with how it's implemented in Graal or is that more of a personal opinion?

Quote:

Originally Posted by Cubical (Post 1721715)

I'm concerned about your claim that it locks up under heavy load as I know SQLite allows concurrent reads and writes and is even used is corporate applications that require it. I assumed properly indexing was adequate enough. Is it just an issue with how it's implemented in Graal or is that more of a personal opinion?

The main problem is that SQLite does not scale well in general in environments where you have lots of things trying to read and write from/to the database at the same time. It's really not a good choice for this kind of usage; a real database server like MySQL or PostgreSQL would scale much better. They are designed for these kind of environments. I suspect the only reason Stefan went with SQLite over a better-scaling database is because it's so much simpler to implement and manage (it's designed to be embedded, after all), especially when we talk about each server having many databases and the need for the servers to be able to mess with them easily.

I also strongly suspect large SQLite databases are resulting in lots of IO traffic on Era which is causing other scripts that want to do IO to wait and results in the ridiculous locks we see all the time on Era and the other servers on Era's machine. I know Stefan was very upset a few years back about large SQLite databases on Era and blamed them for slow servers. They can cause iowait even in scripts which don't use SQL at all (although this should be lessened since Stefan disabled the option which forces writes to be flushed to disk immediately AFAIK).

Nothing wrong with using SQLite, but don't abuse it. Stefan has indicated in the past that he would be willing to set up something like MySQL for iPhone servers, although I never took him up on that offer.

Quote:

Originally Posted by cbk1994 (Post 1721717)

So currently storing all your player data would be better suited for flat files than SQLite?

I would also like to hear Stefan's opinions on what circumstances are correct and incorrect for storing data with with SQLite and it's limitations within Graal. I doubt he will respond or see this. Maybe I can catch him in game and direct him to this thread.

Quote:

Originally Posted by Cubical (Post 1721719)

So currently storing all your player data would be better suited for flat files than SQLite?

Quote:

Maybe I can catch him in game and direct him to this thread.

Email is usually the best way to contact Stefan, although you'll usually only get a prompt reply if he's interested in what you're doing.

It just seems very tricky to script any kinds of baddies or most level NPCs without having some sorts of looping timeouts.... perhaps I can find ways around small stuff but interactive NPCS are a big part of it?

Maybe it's possible, but I don't have the knowledge to make a baddie check for player, follow it, etc, with out having a loop.

Quote:

Originally Posted by i8bit (Post 1721737)

I don't think it's so bad looping if you're doing it serverside, then you at least take the strain off the players which I think is the point Chris is trying to drive home.

Quote:

Originally Posted by Tricxta (Post 1721739)

I don't think it's so bad looping if you're doing it serverside, then you at least take the strain off the players which I think is the point Chris is trying to drive home.

Yes, this is right. The problem is not really the looping itself, it's the work being done in the looping (although very fast loops doing nothing are bad as well).

Baddies should be possible as long as they are efficiently scripted. Most/all of their code would be serverside so you wouldn't need to worry about any additional load on the client. You just need to be extra careful because the server will potentially have so many players so any inefficiencies in scripts get multiplied.

Quote:

Originally Posted by cbk1994 (Post 1721720)

I didn't say that, I said you should be careful not to abuse SQLite. The scaling properties of player flags and SQLite are completely different and you should keep those in mind as you structure your server.

Email is usually the best way to contact Stefan, although you'll usually only get a prompt reply if he's interested in what you're doing.

We heavily use SQL on delteria, but ALL PLAYER INFORMATION is stored on the player, so that this data only has to be used once. We have a migration Database that keeps the players synced with newest Updates.

Player Weapon Flags:

PHP Code:


		
			
clientr.item_Weapons_WoodenSword=1,"Weapons_WoodenSword,""""","Wooden Sword",delt_woodensword-icon.png,"Your ordinary one handed sword handcrafted with wood.",0,Item/Sword,"""meleeDamage,1"",""image_id,wooden"",""gani_prefi.........

Shop Player Flags (Shop Data is even stored on the player):

PHP Code:


		
			
clientr.shop_weapon_shop=STATIC,"weapons,",Currency_Delterian,0.5,"""Weapons_Apprentice,250"",""Weapons_BasicSword,250"",""Weapons_WoodenCane,250"",""Weapons_HunterKnife,250"",""Weapons_WoodenSword,250"",""Hunter_LongBow,25

This is so player only gets the data once or when its needed from the SQL Database!

Example: How we use SQL
http://i39.tinypic.com/2woma2c.png

So from my experience its really important like Chris Vimes said above on how you utilize SQLLite.

Important things you should worry/think about.
-Abuse the crap out of transitions (they look good on idevice and facebook)

PHP Code:


		
			
//Ex:addGuiAni(obj, "moveouttop", 0.3);

function addGuiAni(parentctrl, animation, time) {

  with ((@parentctrl).createAnimation()) {

    transition = animation;

    duration = time;

  }

   (@parentctrl).bringToFront();

  if (animation in {"moveouttop"}) {

       sleep(time);

    (@parentctrl).destroy();

  }

}

-Limited to no timeouts, sometimes there needed if this is the case make sure you use if (level.players.size() == 0) return;
-Keep as much information as you can pertaining to the player on the player.
-Use as little particles as possible, although Stefan just recently enabled particle effects on Facebook Client they still work kinda bad.
-Utilize onmousedown for clicking on NPCs

PHP Code:


		
			
  function onMouseDown() {

    if (mousex in | this.x - 1, this.x + 4 | && mousey in | this.y - 2.5, this.y + 4 |) {

    echo("Clicked!");

  }

}

-Don't use Treeview (not supported)
-Don't use drop down boxes (Not supported/Removed)
-Modify your scrolls to be able to drag with your mouse, making
hScrollBar = vScrollBar = "alwaysOff"; they just look bad int he idevice world.

These are things we looked out for, I attached a code to this post, which will give your GUI Systems full Touch functionality.
// Supported Controls:
// onSwipe - Moving finger horizontally
// onHold - Holding finger in one place for a long time
// onDropped - Stopped holding finger
// onTap - Tapping finger quickly
// onDoubleTap - Double Tapping!
// onFlick - Flicking finger in a direction (scroll-only)

Example:

PHP Code:


		
			
    // ~ Personal Tab

    new GuiScrollCtrl("Achievements_Personal") {

      visible = true;

      profile = GuiDelteriaPartyScrollProfile;

      vscrollbar = hscrollbar = "alwaysOff";

      horizsizing = "width";



      x = 0;

      y = 80+60;

      width = Achievements.width;

      height = Achievements.height - y - 1;

     [B][I][U] this.join("gui_touchscreen");

      thiso.catchevent(this.name, "onTap", "onSelectFeat");  [/U][/I][/B]

    }

Class: gui_touchscreen (Attached)

Quote:

Originally Posted by cbk1994 (Post 1721720)

Sorry, I misread what you had previously posted. I get side tracked during work and misinterpreted it.