mobile | Learn C Games Programming Blog

Tag: mobile

My other side project continues

Posted on November 11, 2020November 8, 2020 by David

Smartphone — Image by Gerd Altmann from Pixabay

This is the social mobile multiplayer game I have mentioned before. The initial game creation program is mostly working. I say mostly because I will still be adding to it. It does however create all of the game data in about 30 seconds for a game that can hold up to 10,000 players. It then creates the output files which are read by the mobile apps. These apps have yet to be created but I’ve decided to do some early testing using non-mobile apps that I’m working on.

What I want to do is prototype the mobile app, not particularly visually but functionally. To this end I’m creating a C# client desktop app that does everything that the mobile app will do. It can read the data (directly rather than via a webserver) and let me create new orders and upload them back to the server (or in this case my development PC).

This client will be crude and not great looking but lets me test that data is coming and going correctly. I use JSON for everything, as a data transfer format as well as storing all game data at rest as opposed to a database. It lets me hold all game data in dictionaries (with a bit of tweaking it is possible to save/load lists of objects to JSON. After loading I convert them to Dictionaries using an Id field.

                var bytes = File.ReadAllText(Lib.PeopleFilename);
                var list = new List();                
                list = JsonSerializer.Deserialize<List>(bytes);
                persons = list.ToDictionary(x => x.Id);

It works and is quick. The downside of using a Dictionary is that it occupies more bytes per element than a List. How many? Well it’s never easy to figure. .NET does not really encourage discovering how things are implemented. This GitHub project by developer Ludovit Scholtz shows the memory used by various .NET Generic Collection Types (HashTable, Dictionary, ConcurrentDictionary, HashSet, ConcurrentBag, Queue and ConcurrentQueue) with various string lengths in a TestObject which as string, an int and a DateTimeOffset.

Storing a million objects in a Dictionary <int,TestObject> with a null string occupies 48,222,240 bytes so roughly 48 bytes per entry. I believe a List is closer to 20 bytes overhead per element. So for slightly more than double the memory use, using a Dictionary gives a tangible performance yield.

Completely off-topic but how to tether an iPhone to Windows 10

Posted on August 28, 2020August 24, 2020 by David

Thanks to an apparent hardware failure in my internet modem (power light remains stubbornly off), I found myself without internet except on my iPhone which has 20 GB of 4G data allowance.

Normally in a month I use less that 0.25 GB of the 20 GB $G monthly allowance data because of fast WiFi at home and at work but I do use it for phones and messages. It’s convenient on rare occasions when I’m out though to have internet access ability on a phone.

Unfortunately for reasons best known to Microsoft or Apple or both, iPhones no longer seem to tether with Windows 10. They did for Windows 7 and it’s a real PITA.

But there is a way to manage it. Just use an Android phone as well. If the Android phone had mobile data then no problem but even if it doesn’t, it can tether to my iPhone over WiFi. And my PC can tether to the Android phone using a USB cable and that is how this is being brought to you.

Now for some mobile networking

Posted on August 17, 2020August 11, 2020 by David

Not the face to face type but actual networking. This is needed because I’m working on a game server. My mobile game (Manana Banana) will become networked enabled and thus multiplayer. C# is ideal for this type of thing but I’m not using the networking capability of MonoGame instead managing the whole lot myself.

Back a few years ago when I was a full-time mobile developer I wrote an app that was used by taxi drivers. It was a conversion of an Android App (I wrote it from scratch running on an iPhone based on the Android source code). There’s a curious architecture with such apps because not only is the a user interface but in the background the app was “chatting” over 3G to a central server (written in VB6 I kid you not) which sent an “are you alive?” message every six seconds to every driver’s phone.

It was not a traditional client-server architecture but the kind of system where the driver could send a message to the server or the server could send a message to the driver.

What this meant was the app was always keeping one eye on the 3G, getting messages and then it might for instance popup a screen saying “There’s a job from x to y. Do you want it?”. If the driver said yes then the app would receive details and show the driver the route to the pickup point. If the driver didn’t respond within 30 seconds or said no then the program would pass that back to the server,

What is a ConcurrentQueue?

C# has an advanced data structure called a ConcurrentQueue<t> which is a thread safe generic queue. I used two of these, one for a receive queue and one for a transmit queue in conjunction with a thread that never finished. All the 3G stuff was done using C# TCP/IP clients and ran in this thread. Messages that came in were put on the receive queue and could be popped off and processed in the main program. Messages to send out from the main program were put on the transmit queue and sent out in the thread. It was a very clean way of separating the main application running in the main thread from the 3G running in a background thread.

Compared to the Android program which was all running in one thread and polled the 3G, I was told by my drivers that my app felt much more responsive! The screenshot above was a very early image of it. It had a very simple UI where each screen of controls (Views in iOS parlance) was built up dynamically.

Also C#/Xamarin has a way of getting from a thread to the main thread on iOS. You cannot update any controls from any thread only from the main UI thread. There’s a method called InvokeOnMainThread for the Xamarin iOS controls. See this Microsoft/Xamarin documentation on how to use it. So that’s what I’ll be doing in my networked game.

Interestingly because I’m managing everything, the TCP/IP messages can be very small, under 20 bytes each. This allows a very high throughput.

Trials and tribulations of mobile development

Posted on July 28, 2020July 20, 2020 by David

Mobile apps — Image by Gerd Altmann from Pixabay

Compared to desktop, I find mobile development somewhat frustrating at times. On iOS, you have a right palaver with certificates and provisioning profiles before you can even run a program on your device. Android is nowhere near so bad, but you have the fragmentation problem I mentioned yesterday. Too many different models with different screen sizes and resolutions.

C# is a nice and powerful language and well suite dto mobile, though to be fair so are Swift on iOS and Java/Kotlin on Android. Android software is a bit of a mishmash. You have to get the right SDKs to match your phone’s OS. Then you have to create a simulator if you are not testing on a device. iOS has its own issues, generally involving needing a Mac before you can put code on the iPhone.

MonoGame is a nice framework. Compared to both Android and iOS native development (no JavaScript here!) it’s a lot more straightforward to work with. You override the Game.Update method for reading keyboards and touchscreens. Then you override Game.Draw to output graphics. In that respect it’s even easier than using SDL for games. It’s a little like WinForm programming.