Sorry your browser is not supported!

I was wondering if it is possible to use HTTP commands in AppGameKit Tier 1 and get the Internet Time from a site (example code would be appreciated).
The reason I ask is because that would be a good way of providing a time-based demo of an AppGameKit game to testers, that would "expire" after some days/executions, and would prevent the user to re-run it after expiration, just by changing the system timer.

you will still have the problem that u need compare this time.

maybe just add GetFrameTime() time and save/load it.
agk useing the appdata folder which is by default hidden.

What you want is a server solution where you can disable clients based on a client unique identifier. That way you keep all control server-side, and the client will only proceed beyond start-up if it receives an OK from the server. On the server you have a key-value pair in memory with the unique identifier and first activation of the client. The server checks current time at subsequent client-connections, looks up first connection, figure out the difference and sends an OK or Expired message.

It do require you to host your own server back-end. The good news is, this is very cheap. And can be done in at least a couple of ways:

1: If your ISP provide you with a static IP, just set up a little Raspeberry Pi or similar as the server. This will do just fine for hosting up to a couple of thousand clients. And have zero recurring costs.
2: Go rent a little VM from any of the more popular server-hosts. AWS, Azure, Google-Cloud and Digital-Ocean are some alternatives. I prefer AWS, but of the crop, Digital-Ocean is probably the most user-friendly. These all cost next to nothing, usually about 5USD a month, which includes a good chunk of storage and bandwith. But the best part is that as your user-base grows, it is dirt-easy to spin up more servers behind a load-balancer to handle the traffic.

Either way, set up a separate DNS and use that address to point to your servers IP. You don't want to hard-code the IP in the client, better use the DNS domain name. If you already have a website, it should be easy (and no extra cost) to set up a sub-domain that point to your server.

With a domain (or sub-domain) name, you're also qualified to use Lets Encrypt to set up HTTPS over TLS on your server. Which you will want to do.

The not so good news, is that there are a few other prerequisites you need master:
1: You need to know the basics of using Linux in headless mode (aka, no GUI, just the terminal, over SSH). Servers run Linux for a reason, so might as well learn it sooner rather than later.
2: You need to know a language that is well suited for server-applications. From personal experience, there is no better alternative than Go (aka golang). Other popular alternatives includes C# on dotnet core which is reasonably performant and not too hard to learn. And of course Python, which suffer a bit in the performance department, put is said to be very easy to learn. All these three alternatives are pretty easy on the dependencies (none in the Go case, as it results in a single static binary that you can upload and run), are cross platform so producing something that runs on Linux even-though developed on a Mac or Windows PC is not a problem. Lastly, none of these alternatives require any fancy framework to get going.

I have done similar things with a standard ISP and webspace, using PHP and MySQL.
I used SHA1 to secure the data.
Maybe somebody can tell me if this is too weak a solution, but it has done the job for my mini games.

I know this is going off topic just slightly - but talking about servers and such like

Maybe an interesting idea would be to put a Demo version of a game on Google or what ever and put the full version on a server - so when we pay for the full game (in app purchases) it goes away to the
servers and download the full game

and on the server - put a marker n the server to say this person as already bought this game so automatically download full version if and when they have a crash on their phone/tablet /pc.

Nice thought but...

Google wouldn't like you doing this.
The user won't want to download 2 versions of the same app
The user would have to sideload the app, bypassing all security on their device...if they even know how to do it.

I'm working on a client/server app and am using a solution similar to BatVink's. The client interacts with the server via php and MySql. Essentially, the php script is generating a webpage (plain text) which is read, parsed and understood by the AppGameKit program.

The connection is secured with SSL. You can connect securely to the server using the iSecure parameter of this AppGameKit command:

integer SetHTTPHost( iHTTP, szHost, iSecure )

The downside to this is that data cannot be 'pushed' to the client - the client has to request the data.

Hope this helps a bit,

Jambo

Thank you all for your answers.
I now see that this is a very delicate problem that expands beyond the scope of AppGameKit (or a single language in general) and will require more time investment.
You have provided so many answers/solutions to my question that wouldn't be easy to be found otherwise.
Again, thank you very much for your time.

@nickele upgraded

I know it looks like a nightmare to begin with - but the fundamentals are easier than you think. Start by securing some space on a webserver somewhere which can execute php files (most can, these days), and save a php file which just echoes 'hello world' or something. Follow the AppGameKit docs (beginning with SetHTTPHost) to retrieve the 'webpage' and print its output in your app. The http commands are well documented in AppGameKit, with examples; and php docs are plentiful. Then just work from there.

When you're up and running, you'll want to be able to develop and test locally, rather than uploading your php files to a remote server somewhere every time you want to test your code. I recommend MAMP for this (there's a free version) and MySQL Workbench (again, this is free). MySQL Workbench will allow you to see, build and interact with your database.

To create php files, you could do worse than NetBeans (also free!)

Eventually, when you're deploying your app, you'll probably want to look at securing the connection by getting an SSL certificate and getting AppGameKit to connect securely to your server. Again, that's not all that difficult.

If you're going to be accessing a SQL/MySQL/etc. database (and you probably are) then make sure you've looked at all the security implications around SQL (e.g. SQL injection). There are plenty of resources online for this.

Go for it! Don't be put off!

Hope this helps.

Jambo

Like Jambo, I highly recommend you go for it. It is a great learning experience that you'll come to draw upon again and again. No matter what tech-stack you decide to learn first.

Learning the basics of building a RESTful HTTP service is the cornerstone of just about any data-driven app. Mind you, it is a big field with quite a few gotcha's for new players - especially when you venture into the area of security and account control - not to mention building for scale and flexibility. But that is for later.

Right now, I am assuming neither is a problem. And unlike Jambo and Batvink, I'd not recommend PHP, as it isn't an environment in and by itself but is reliant on a host of dependencies to get anything useful done. Also, getting to grips with an SQL database may be overkill for such a simple project and limited traffic. Plus, it is yet another dependency to bring on. Which can be translated to having the need to dockerize the project to ensure that the dev-environment is cloned exactly to the server environment to avoid any nasty surprises as updates and patches comes rolling in. Then we're suddenly deep into linux devops and deployment land, which can not be said to be beginner-friendly.

I am a big believer in keeping it simple. The less moving parts, the better. The less dependencies, the better. The less different environments to jump in and out of, the better.

Which is why I'd highly recommend using Go. Google "golang restful api" and you'll find plenty of examples on how to build a simple server. With no external dependencies. Just one binary that you can upload. Go is easy to learn, and there are plenty of tutorials, videos and free e-books available to get you started. And once you're hooked, you'll miss all the features that make life so easy in that language. Not least of which is the tooling. After installing Go, get VS Code and the Go extension for it, and you're up and running in no time. If serious with programming (in particular programming server-apps), I'd recommend also changing over to Ubuntu 16.04 or at least if running Win10 and not wanting to experiment too much with your current set-up, get the Windows Subsystem for Linux Ubuntu 16.04 BASH installed.

As for keeping track of clients, you can either get the device uuid, hash it using SHA1 and send to the server (never send this unhashed, as Google and Apple will get very cross and not allow your app onto their stores if/when discovered) and use this as the ID, or have the user create an account where the server assigns an ID.

Then on client first-connect, search existing IDs, if not found, create a key-value pair where the ID serve as key, and the current date is the value. This get appended to a flat text file (preferably JSON encoded, but most any encoding scheme will do). The entire list you keep in memory for speed and efficiency. If we're generous and say each entry is 100 bytes, then in a megabyte of RAM, you can store over 10.000 client ID/first connect date pairs. Even a Raspberry Pi (and cheap cloud VMs) come with 1Gb of RAM, where at least 800mb is available after the OS have gobbled up its' share. Anyhow, the only time you should read from the list-file, is during start-up of the server.

I would not bother with any database stuff until either you got several thousand users, or you expand upon the API to also keep and handle more types of data that would benefit from the relational goodieness of SQL queries. And even then, I'd only use the database as storage, and cache everything (well, what is most used anyway) in an in-memory key/value management system like Redis. When scaling, anything that hits the disk - or worse, an external resource like a common DB serving several API endpoints in a distributed system, each SQL query comes with a significant cost in response-time.

Thing is, as long as the external API remains the same, taking the same requests in and providing the same data out, how you go about handling it behind the scene so to speak, doesn't matter. You scale and optimize that depending on demand. You don't fret it doing complex stuff to handle huge traffic before you need to.

Hmmm, this suddenly became quite a long post. Writing server apps is what I enjoy the most, so I'm easy to get into a rant on the subject. It's nice and pure, with none of that silly UI/UX headache or compatibility issues to worry about. Just nice well behaved text under one environment that isn't liable to change under my feet

On board a pirate ship, eh?

Cheers!

I guess you won't be bothered with time zones, since you want to deal with "Internet Time".

It seems to have a few drawbacks though, so I would advise against it.

Surrender the booty!


Good idea, but I would stick to getting the Date and Coordinated Universal Time (UTC) from a server.

because spoke about a demo, other people just provide the first level and disable save or achievements.
or just end the demo after a short time.

using a server side self made web service make sense if you have a bunch of games.
if you have web hosting with IIS you can do this quite easy with visual studio 2017.

i found a single url from a time server but it used not a http port, so it can be a problem with firewall.

Again, thank you very, very much dear friends for your precious answers!
In fact, I started feeling guilty because you dedicated so much of your time in order to present me the magnitude of the languages/commands/applications needed for what I (as a newb!) thought would not be much fuss.
Markus:
Thank you for the interesting alternative.
BatVink:
Thank you for pointing this about Google .
Jambo B:
Indeed there's a lot to learn, but your encouragement makes me appreciate the (programming) journey ahead! Thank you!
Dybing:
I suppose there wouldn't be problem if I tried experimenting in a virtual environment (virtualbox)? Also thank you for the detailed post!
Conjured Entertainment:

I think "On board a pirated ship", is better!
That's what happenedto Greece.
Thank you for pointing out the UTC time parameter.

I'd just hard-code the version of the app. An http command (over ssl) to your server with the version to verify if it's usable or not. As you update your game, keep a list of version numbers on your site. Match the version sent by the app with your list and see what expiration date you have set. Removes all date/time from the app and puts the control on the server.