After many months of development, my first iOS app Lottery Sim is now available. As the name suggests, Lottery Sim is a full featured Lottery simulator, and it knows the rules of play for the most popular number-based Lotteries. The idea for this app came from my family’s love of playing Lotteries conflicting with my background in math. Probability theory is tricky business (just ask fellow bitcake programmer Mike, lol), and reading the odds alone may not be enough to convey the likelihood of winning a Lottery.
I want players to be able to see what the outcome could be if they played their choice of Lotteries from as short as a week to as long as a lifetime and beyond (based on starting at age 18 and an average lifespan of 78, plus you can run consecutive simulations to continue adding to the stats). The results are usually soul crushing, but that doesn’t mean it’s impossible to win big. And it may be that one big win that changes the rest of your life. The point of Lottery Sim is not to promote or discourage Lottery play. I want it to provide a clear view of what Lottery play is all about, how much money you could spend over a long period of time, and what kind of return you may expect to receive. Use these stats to tweak your play strategy and help make the most of your Lottery experience.
Beyond simulations, Lottery Sim also features a lucky numbers generator with a unique approach and a ticket manager to keep track of your real world plays. Bring Lottery Sim with you to your local Lottery outlet to use it as your personal ticket manager as you fill in your real world Lottery tickets.
Was able to meet my September goal and submit my first iOS app to Apple. Should take a week or so to be reviewed. If all goes well, I will add the project page to bitcake as soon as the app is live.
Started work on my next iOS app. Right now I’m thinking about a game. I have the rules figured out but need to do a basic implementation to see if the game actually works… is it fun, is it challenging but not too hard, etc.
I was thinking about making MangAI Reader as my next app, but I’m worried there isn’t a big enough market for it. There are already a lot of comic readers on the App Store. I’m not sure exactly what functionality MangAI Reader would add over existing apps. Automatic page split detection would be there for sure. Porting the AI of MangAI would not be a fun project (seriously, I can barely follow it and I’m the one that wrote it :P). The memory and speed restraints of a mobile device may also not be sufficient. I could go the route of pairing with the desktop version of MangAI. That way your computer would handle all the heavy AI and send the interpretation data to your mobile device. I’ll keep thinking things over. Please leave a comment if you are interested in an iOS MangAI Reader.
I intend to slow down development for a while. Putting in overtime to finish the iOS app came with a cost to my health ^^;
The more I work on my first iOS app, the more it looks like a real app, the more I want to work on it… recursive motivation? It’s hard to tell how much longer it will take. Most of the code and graphics are there. I want the first version out by October (health and Apple approve process permitting).
MangAI is doing well. Waiting on user feedback for possible memory improvements in Linux environment. I’ve noticed that a lot of times when I receive an email from a MangAI user, I will email back with the information I need from her, then never hear from her again. Are my responses not getting through? I usually reply to an inquiry within 24hrs. If you don’t hear from me in two or three days, please email me again.
New to version 1.06:
-AI improvements to MPM and MSM interpretation
Better able to detect unspecified spans (1112 meaning 11-12).
Better able to detect when a hyphen does not indicate a span (50-200 is two separate numbers 50 and 200 instead of span 50 through 200).
Improved ability of MPM to find non-delineated chapter spans (foo_v3_15-20 is likely volume 3, chapters 15-20).
MSM interpretation is automatically disabled for folders with low confidence. This usually happens for small folders of scanlator notes or fanart. In these cases, it is better to sort using basic filename string comparison.
Improved MSM handling of special scan overspecification (p3_notes.jpeg is probably better placed between p3.jpeg and p4.jpeg instead of near the end of the volume/chapter since it likely explains something just read in p3.jpeg).
Various logic tweaks.
-Overhauled epub creation code
Tweaked the basic structure of created epub files so that they (hopefully) display better across all devices.
Download the latest version from the MangAI project page.
It feels like I haven’t worked on MangAI in ages. While reading manga on my iPad last night, I noticed that some of the 2-page scans were being placed at the end of the chapter instead of in-between the proper pages. Tracing back through MangAI’s MSM interpretation, I found the cause of the problem. Here’s a sample scenario:
Foo_ch25/
Foo_25-01.jpg
Foo_25-02.jpg
…
Foo_25-10.jpg
Foo_25-1112.jpg
Foo_25-13.jpg
…
In this case, Foo_25-1112.jpg refers to chapter 25, pages 11-12. “25-1112” is tricky to interpret since MangAI has to first determine that the given hyphen does not refer to a span between 25 and 1112, and then it has to determine that 1112 is an unspecified span 11-12. The first step was already being handled properly, but the second step was never given a chance since the first step, after splitting 25 and 1112 into separate entities, disregarded 1112 as being too large of a number to refer to a volume, chapter, or page.
Confused yet? I was too. It’s a rare situation, but I am now working on improving the logic.
