Freitag Software
The Joy of Writing Software
  • Home
    • Links
  • My Software
    • JavaScript Programs >
      • Dots
      • The Code Cracker
      • The Deserted Ship
      • Flying Text
    • Java Programs >
      • Dot Animation
      • Operation Rescue >
        • Mazes for Programmers
      • Battleship!
      • Blackjack
      • Draw Poker
      • State Pattern Demo
      • Falling Blocks
    • Android Programs >
      • The Oracle
      • RPSLS
      • Gemini Falcon: Asteroid Miner
      • Gemini Falcon: All Boxed In >
        • Gemini Falcon >
          • Privacy Policy
          • A Game Oddity
      • Ay Caramba
      • Dots vs Dots
      • Ants vs Ants
    • Twine Stories
  • Random Thoughts
  • Book Reviews
  • Teaching
    • Real-Life Stories
    • Flying Text
  • About
    • Contact

What to do next? 

1/11/2015

 
Now that I've finished Gemini Falcon: Asteroid Miner, what should I create next?  The world is my oyster -- as the saying goes. I want to do something where I can program an interesting AI (artificial intelligence) for the game. And of course it needs to look awesome! 

I have all kinds of ideas, but which one is best? I'll be working on this for awhile, perhaps for all of 2015, so it needs to be worth my time. Of course I would love to develop a fully realized game universe with all the bells and whistles, but, being a single app developer, that is not realistic. Several of the games I've thought about would require months of just developing artwork and then several months of developing animations -- and that's before writing any code at all. 

So I think I need to avoid realistic game environments and focus on abstracting the game elements so I can focus on the game mechanics I want to code. No realistic art -- just shapes, colors, movement, and cool code under the covers. ​

Details nobody will ever notice

12/30/2014

 
I enjoy programming because I can see results immediately, or at least relatively quickly. I code, I test, and it either works or it does not. Cool. 

But a lot of code also contains functionality that most users will never see, and yet that code is important to include to round out the application. For example, in Gemini Falcon: Asteroid Miner, if the player elects to fly missions without doing any upgrades, the program will start to speed up the ship in tiny increments until it is almost as fast as it could be after the first upgrade. Otherwise it would be impossible to complete all 60 missions. And, as a surprise, after 55 missions of no upgrades, the impulse engines are actually faster than the regular engines! At that point it will be better to run out of fuel -- which I made certain to happen by eliminating the fuel clouds in the later levels. Of course the player will be nervous about running out of fuel since it has been critical to find fuel clouds until then. 

Another detail, when a player has trouble completing a mission, the player may notice the number of coins required to fix the Gemini Falcon goes down, as does the time required to repair the ship. But the player may not notice the mission becomes a little easier each time they crash also. I did that to encourage the crash-happy player to continue playing and not to become discouraged. ​

Some Gotchas

11/24/2014

 
Here are few things I've encountered recently that I had to spend some time figuring out. 

In-App Purchases: 
  • I created a test value for my in-app purchase id, no-ads-test, and then I purchased it. So far so good. But when I created the real in-app id and deactivated the test id, my app received an error saying that it could not find prices for a purchased product. So I activated the test id again, and all was well. The result is that in the Google Play Developer console I have a bunch of active test ids that are only active so I can buy new in-app products in the production version. It's just irritating not being able to clean it up. 
  • When I created an alpha or beta version of Gemini Falcon, I added several people including myself to the Google Play Console / Settings / Gmail accounts with testing access. Again, so far so good. My testers could purchase in-app products without actually being charged for them. But when I created a production version of the app, the testers still could not buy in-app products. I had to remove their email addresses out of the Google Play Console / Settings / Gmail accounts with testing access area. ​
Not Power of Two
  • When I was creating and modifying Gemini Falcon's artwork I reduced the size of some files and added to others, but I didn't keep them a power of two (512x512, 512x1024, etc). This worked fine on my Samsung phone, but it didn't work at all on my friend's Nexus phones. 


This is what it looked like on a Nexus phone ------> 
Picture

Lots of Details

11/15/2014

 
Writing and publishing an Android App is an interesting process with lots of little details. I started doing this because I enjoyed coding and seeing how the code turns out. I love an elegant solution that is clear and easily understood. But I soon discovered that writing code is a small part of creating and sharing an Android App.

Creating a basic Android App consists of many parts: 
  • Installing, understanding, and using the IDE  (Eclipse or Android Studio) 
  • Understanding how to use the IDE's emulator
  • Understanding the Android environment (phones and tablets to start), including the lifecycle of an App 
  • Coding in Java
  • Understanding and using multi-threading in the Android Java environment 
  • Coding in-app purchasing
  • Coding application data backup through Google's Android backup service 
  • Understanding and using data encryption for app files 
  • Writing and modifying XML
  • Understanding the difference between using Android resources and assets  
  • Being comfortable navigating and using developer.android.com
  • Being effective in debugging your App
  • Being effective in researching issues in stackoverflow and other resources
  • Creating artwork for the app. Games require lots and lots of artwork. My deficiencies in this area soon became very apparent! 
  • Ability to use the Google Play Developer Console to publish alpha, beta, and production releases 
  • A website for your "organization" and perhaps for each App 
  • A privacy statement for each app
  • Finding or creating sounds / music for your App
Once I had the necessary knowledge and skill, the major areas that take up most of the time in writing an App seem to be (based on my limited knowledge and experience!): 
  • Designing the App (and not winging it!) 
  • Writing the Java code 
  • Creating artwork / creating the interface 
  • Adding sounds / music 
  • Publishing the App
Writing my first App was not be a quick and easy process, but I found it to be rewarding. As I learn more I expect the process to become quicker and, indeed, I wrote the Ay Caramba! app in a single week (of course I had already written the content years before and I only had to write a container App to display it to the user). I look forward to knocking out Apps as often as I care too!

Creating App Interfaces

11/13/2014

 
I started writing Android Apps because I enjoy coding and creating and seeing the fruits of my labor. Years ago, when I first started learning Java for fun, I stopped before I immersed myself into creating interfaces for the code I enjoyed writing. It was clear to me that creating the interfaces I could imagine was beyond my abilities and would take years of study and experience. So I reluctantly set Java aside and concentrated on other subjects that interested me.

Enter Android. I discovered that writing user interfaces was fairly easily so I could enjoyably code in Java behind the scenes instead of spending so much time on the interface with the end user. ​

Burned Out

10/8/2014

 
Tired. So very tired. 

Not of my programming projects exactly. I'm tired because as I continue to improve my latest app, Gemini Falcon, which is turning out rather well I think, I think of new bells and whistles to add to it. The idea that it will never be done is scary, and the idea that if I stop development now it won't be as perfect as I could make it if spent more time on it is frustrating. 

The only major item left is to decide how to monetize it -- as if I'll make any real jack on it anyway. I could just release it for free; or I could add full screen or banner advertisements, which I hate to encounter when I'm playing a game; I could add in-app billing, which would require a lot more work (sigh); or I could create a limited free demo version and a fully featured version for a small amount of money.  

I don't expect to make any money on this, so why am so concerned about it? In the back of my mind I worry that if I gave it away and millions of people loved it and then I would miss out on a life-changing amount of income. That would be a bummer!  ​

Creative Angst

7/28/2014

 
When I have an idea for an app, a program, an essay, a story, a play, or some other creative piece of work, I can visualize the final form and I work towards that. I jokingly say that I'm working on tedious details of the project rather than the imaginative creative portion of design -- although during the tedious phase there are always plenty of opportunities to be creative. 

I really enjoy these times and frequently find myself "in the zone" and time flies by. I can easily code for 5 hours without realizing any time has gone by at all. Experiencing flow like this is a lot of fun and working on my creative projects allow me to feel that directly and reliably. 

At some point during the project I eventually hit a place of darkness where I cannot see through the tunnel to the other side or even see if there is another side to see through to. When I'm programming it might be after I've done everything I know how to do and now I have to implement some new functionality that I've never done before and some functionality I have no idea how to implement. Those are dark days when I discover the garage needs cleaning, my bike's chain needs to be oiled (again), and look! There's a Big Bang marathon on television!  

But, after some angst and some downtime, I return to the task at hand and begin to tackle it. On my best days I am enthusiastic, optimistic, and look forward to learning something new. It's a challenge I embrace. On my worst days my head aches and I despair of ever getting it to work like I want it to. 

The important thing for me to remember on my dark days is that I've been there before and all I can do is to keep making progress and trust that I will eventually see the light at the end of the tunnel -- and then it's all tedious details again. Joy! ​

Embarrassing  Things I've Done

6/18/2014

 
Here are some embarrassing things I've done related to programming...
  • I was tired and forgot that the For / Next loop in java is a 'while the variable' type of loop and not a 'until the variable' loop. I spent more than an hour debugging this when a nap would have resulted in finding the problem immediately. Sometimes a rested mind is more important than plugging away at a problem that I know should be easy to find.  
  • Not backing up something and losing some work. I seem to have to relearn this every couple of years. 
  • Forgetting to copy a file to the Assets folder and wondering why my change was not working. I took a break for dinner and realized the problem in mid-chew. 
  • Forgetting the format of some simple code statement. That's why I have reference books close by. A waste is a terrible thing to mind. 
  • Trying to show someone the results of hours of coding when they couldn't care less. 
  • Trying to explain to a non-programmer the cool piece of code I've written and how it blah, blah, blah. They don't care. 
  • Telling my wife it's done, finished, complete. And then finding a bug when I'm proudly showing it to her. Arrrrg! 
  • Spent 5 hours re-installing Eclipse, the Android SDK, and a bunch of drivers, and finally discovering that a recent upgrade to my phone tuned off Developer Mode and the USB access between the phone and my computer. This is something to check if it appears Eclipse can't find your phone through the USB connection. 

Placing text and knowing where to accept touch

4/30/2014

 
When creating Major Bob, I had to place text on the screen in specific places and then know when the text was touched so I could do something. To be organized, and to save time, which is the purpose of being organized anyway, I created a spreadsheet to do the calculations for me. (I'm lazy that way.)

Below is the data for the main menu. The 'Play ' menu item was placed at (10, 218) and the other text areas fell into place. I just had to enter the data in the yellow cells. The Rectangle (10, 218, 300, 42) statement indicates where the 'Play' touch area is located. A reminder of what is what is at the bottom of the screen because I'm sure I'll forget all about this by the time I start my next project. ​
Picture

Miscellaneous 

3/31/2014

 
  • Back up your project often! I back up everything every coding session so I can look at the code from any day I want to. 

  • Be prepared to rewrite the code every time you learn something new that is really good. When that happened to me I didn't despair since I knew this was a good thing. It means I'm learning. I rewrote this little App multiple times and each time the code was much improved. It felt good to have a more solid code base than before. 
​
  • As a game developer and programmer, it's a good thing to be able to do tedious work well for hours at a time!
Forward>>

    Author

    David Freitag - 
    Someone who enjoys programming and software development.

    Archives

    January 2018
    December 2016
    November 2016
    September 2016
    August 2016
    May 2016
    January 2016
    December 2015
    May 2015
    January 2015
    December 2014
    November 2014
    October 2014
    July 2014
    June 2014
    April 2014
    March 2014

    Categories

    All

    RSS Feed

This website documents my love of programming.  I hope it is useful and entertaining for you to read. 
An old programmer learning new tricks... 
(c) 2017 David A. Freitag, all rights reserved.