Tech Blog

Pokemon Project Update

When I released my Pokemon game for the first time on June 4th, I did so through a private link as I wished to continue working on the game. You can find the link on my projects page.

I took some time off from working on it but now have come back to it as I have continued to dive into more network programming using a combination of UDP and TCP. 


I want to release an app but I can't use the store, how do I update it?

The answer to this one is confusing at best. There can be no store release due to copyright infringements, so going through the mainstream application stores is out of the picture. So the question  then became, if I were even to update my app, what would it be?

Damage calculations, that was my answer. For small updates they would be focused around move calculation missteps that got past me. So I then figured out my solution, why have the client's do the calculations when I can simply update the server? This would rule out P2P networking but because of the lack of access I would have to update the application this method would be best. 

The issue with this is that I can fix the multilayer updates far faster then the client side updates as I still want that much desired AI match for when you want to play but cannot connect to the web. 

I would even try to enable new sprite download with the online version as well as the play mode updates as well. Most things can indeed be done on the server side!

What if it was like a major update?

No choice there but to update the clients, but what would a major update look like. A new generation, that would only happen on major releases and the off-line mode would only be affected. Possibly a new GUI update, making it cleaner or something.

Network Traffic

I have been up in the air on what to use, until recently I made my decision. It would be a headless server hosted by Microsoft Azure, and have a SQL data base through them as well (so you can save those teams and login). Using a headless server with some sort of GUI just to give me stats would be great, asynchronous tasks and we should be all set, I want to be ready for scalability but I don't necessarily anticipate 10,000 CCU (concurrent users) at the same time, and even if there were that many users, the amount of data coming through would be pretty minimal, it is a turn absed game after all.

Sounds great when can we expect this?

That is the biggest question isn't it. I will need to go through and pretty much strip out my code and make way for a new architecture. I doubt I will have much to do that is different in terms of calculations currently (using current generation moves and stats does make it easier). The JSON architecture of sending the move calculations to each client and simply getting communications with the server is probably the hardest part. I have been doing a lot of networking for work by happen-chance recently so I am very fresh on that but hooking it up to a web server is something I have never done before, which is really exciting. I would love to say by the end of April I could be all the way to beta, so that is my current time frame.

I'm looking forward to using more technology I haven't worked with especially making some cool server architecture stuff. I can't wait to post more about it.

dan flan