My favorite terms from the old Sun JDK Supplemental License:
4. High Risk Activities. Notwithstanding Section 2, with respect to high risk activities, the following language shall apply: the Software is not designed or intended for use in on-line control of aircraft, air traffic, aircraft navigation or aircraft communications; or in the design, construction, operation or maintenance of any nuclear facility. Sun disclaims any express or implied warranty of fitness for such uses.
It’s just a few days into 2014, and here I am trying to write some more again this year. I think I tried starting to do this last year as well but it didn’t last long, that’s kind of how these things go. The only time I really updated a lot was when I was posting about the development of Speeder so maybe I need to start developing another game.
I only made one Android game last year, it was mostly a vanity type project called Chipper. It’s a card game that is played back where I grew up, similar to Dirty Clubs or Euchre. I released it during the summer and didn’t expect many downloads. Looking at the developer console I’m just under 200 downloads on it, which is several times more then I ever expected. I’m calling Chipper a success, my friends who play the actual game back home all love it and the download numbers are good.
I did write one other game this year, Path Breaker for Ludum Dare 26. Ludum Dare is a 48 hour game jam where there is a theme for the game you develop over that weekend. The theme of that competition was “Minimalism” and I used very minimal graphics and gameplay to make something that came out pretty fun. The game would probably work as an Android game so I’m hoping to port it over at some point and add onto it. That might be something I do for 2014.
Most of my development work this last year was for work, which is kind of disappointing to me. Not to say work isn’t interesting, because the work I do is pretty interesting, but I really wish I had done more for myself. Above anything else I want to do more software development in my own time this year, maybe release several games this year and attempt to actually make money off of them again. We’ll see, it’s the start of the new year so I should try harder for something more.
I got a lot done today in my work to update Orbital Defense.
My goal was to get player units working today. For the basic functionality I really only need one unit in place so I just updated the basic attack unit.
First up I added in the graphics for it. In the original I wanted the satellites to rotate or at least have some bit of animation. With LibGDX it’s pretty simple to handle animation so I now have them rotating, which is nice.
One thing I had to fix in the conversion was the placement of satellites. The coordinate system is different between the standard android canvas and LibGDX. Basically the Y axis is reversed in Canvas 0 is at the top, in LibGDX 0 is at the bottom. I knew this was something to keep an eye out for so as soon as I tested it and saw the results I knew the change I had to make.
Now that I had satellites placed on the screen I need to get them to move. Moving something smoothly around a circle takes a bit more code then one might imagine but luckily all the code I had written still worked perfectly. I needed to make some adjustments based on changes I’ve made to where variables and methods are coming from, but nothing about the calculations needed to change which is always handy.
Since satellites could orbit I figured they should next be able to attack. Since I have meteors already in place, we have targets for the satellites. This was code that once I took a look at it I was able to reduce it down to far fewer lines. The general logic is still the same, i just get where I need to be a lot quicker and removed some of the redundant branches. Basically it checks to see if it still has a valid target, and if not finds one. Once a target is found it fires on it if the satellite is ready to fire. My original code for this logic took up about 50 lines, my new code for it takes up 20 and performs the same job in a more efficient way.
Part of attacking is that you want to see it on the screen, so I had to work out some better code for that. Previously I only had the attacks on screen for a frame or two, but with faster running frames this doesn’t really work so it’s all time based now. It is still only on the screen for 0.15 seconds but it is enough that you see it happening. I will probably adjust that number further as I work on things more.
Once I had code for satellites attacking in place I could just copy the same code for enemy attacks. Even though I don’t have any enemies that shoot in place yet, the logic stays essentially the same.
I do have meteors though, and the way that those attack is by hitting things, so I needed to put collision detection in place. One thing that is nice for simple collision detection in this game is that everything is more or less bounded by a circle. What makes that simple is that all you need to do to check for a collision is find out the distance between the center of the two objects and see if it is smaller than the radius of the two objects added together. Everything in the game has an impact damage assigned to it so I just subtract from the health of both objects. Of course I couldn’t leave things that simple though and I currently have two special types of satellites that don’t obey the same collision rules. The easy one is the Bulldozer satellite, specifically designed to take out meteors and other objects. It takes no damage from impact. The more difficult one is the Bouncer satellite. Bouncer satellites deflect meteors and neither takes damage. Handling these requires figuring out tangents and reflecting angles and all that jazz, which I had figured out previously and have code for. Right now I’m hoping my old code will work fine, as soon as Bouncers are added back in I specifically need to test them.
After all this added code I can then just simply check the health of all allied and enemy units and destroy the ones below 0, with a little quick explosion that I think I want to expand later on.
Basic game play is more or less in place with all these additions. What I really need to do next is add information to the screen. You currently do not know planet health or current resources, vitally important data to actually know how the game is going and what actions you can take in the game. I think I will work on those tomorrow as well as start working on the main menu screen and other non-game screens, which will all be new with the change to LibGDX.
In completely unrelated news, my Flynt Flossy shirt came in yesterday which is awesome. Here is Turquoise Jeep’s latest video:
So I kind of started One Game a Month last month, though my first game didn’t really fully come together what with being sick and having a prototype to build for actual work. For February I’ve decided to update an old game of mine, Orbital Defense and making Orbital Defense II.
The first order of business for the update is that I’m converting it over to use LibGDX. This is the framework I’ve used for my later games. I think it will help it run better and just look nicer overall. I’m still in this stage of the process, to the right is a screenshot of the current progress. The star field is twinkling, the Earth and the orbital zone are there and meteors are being created and run across the screen.
I still have a long ways to go, I need to add in all the other units, take care of unit collision and attacks, add the info bar and unit selection bar, etc. There is plenty to do here to have it converted and ready for the next step.
The next step will be updates. Since this is a tower defense type of game one big one I want in there are upgrades for satellites. This is really something I should have had in the first version but I just didn’t have a good plan in mind for how to go about it. I feel like I do now and it will work out nicely. I also want to add more satellites for the player to use, and perhaps a selection screen to decide which satellites you use. I want it to also have levels and more wave style gameplay for enemies instead of the random enemies it currently throws at you based on difficulty level. I’d like to do something more with the graphics as well, at least update how it looks so units are quite so cheap looking. Overall I just want to make it a better game that continues to be fun.
That is a lot to do, and the way I work I’m not sure it will be done this month so this might be an entry for another month. Either way, this is something I’ve decided to do so hopefully I end up with something interesting.
I finished Speeder, put it out on the Android Market and of course get no sales. The free version is doing okay and it’s generating more ad revenue then any of my other apps but that’s still nothing. It’s unfortunate but if nothing changes I’ll probably be looking for another job in July. I haven’t given up though as the idea of getting a regular job sounds dreadful. I had an idea for another new game that I’ve started work on already.
The new game is going to be a math game, and force you to try and do simple math problems quickly in order to do well. I like this because it’s something you can get better at over time, the more you play the easier it will be to work quickly. I’ll post more about it as I get more finished on it but it’s coming along really nicely I think.
I’m using libgdx to make it, previously I’ve worked just in the Android Canvas to write things, but I wanted to try out something using OpenGL and nice game framework. Libgdx seems to have the best documentation and demos and tutorials and such of the game frameworks I looked at. I’ve been able to figure out how to do anything I need to do in it by looking over their website and forums so I’ve been happy.
I’ve also been goofing around with Haskell in order to learn it. Haskell is a completely functional programming language as opposed to Java which is an imperative programming language. It’s a different way of thinking when you write programs in a functional language and a lot of people think it will be the way to go in the future. I’m starting to feel good about what I’ve learned in it so I’ll probably fiddle around with writing some stuff from Project Euler, algorithm stuff like that seems perfect for what Haskell does.
Not much else to talk about, it’s getting nice out so I’ll probably start going to the beach soon, I’ll post some pictures from there because that place is rad.
So today I did a bunch more coding in Speeder. I implemented scoring, which will continually increase as you are driving with modifiers that increase for every car you successfully pass. If you collide with a car your modifier will go back to 1.
To go with that I implemented collision detection for the cars. It isn’t fully what I want but it stops cars from clipping through each other, or mostly your car from clipping through other cars. Other cars can still clip so I’ll have to do some work to stop that.
I did some initial work on power-ups too that you can pick up on the road. So far I have 4 different types in mind, tires that will let you move left to right quicker, nitro that will speed you up going forward, allowing you to get more points faster, simple point powerups that give you a bundle of points in one go, and a cowcatcher that will go on the front of the car and let you plow through other cars, not losing your modifier or taking damage. Tires and nitro might be permanent upgrades that can help the game to go quicker, points will be instantaneous and the cowcatcher will take damage of its own over time and eventually fall off so you go back to normal. I don’t have graphics for any of those so I might go about putting those together sometime this week.
I also put into the game the idea of lanes, so that traffic you are driving through is lined up in these lanes. To go with that some of the collision stuff I still need to implement will cause cars to shift lanes, and I want other cars that shift lanes themselves in the future. Right now I just have them being drawn with debug output putting a rectangle around them but I eventually want them drawn to look like a normal road.
So to go with that here is a new screenshot, you can see the lanes and my debug score and modifier output up top. I’m also collided with a car in a screenshot which of course you can’t really see if it’s not in motion.
I also realized in putting this together that anti-aliasing has to specifically be turned on for Paint objects in Android. I went back to my old games and enabled it for some stuff so that the graphics, specifically text, look a lot nicer now.
So I didn’t really write any code today but I did do some writing on game design. I’ve worked out how I want collisions to be handled in game, I worked out some powerups and how scoring is going to work and such. All important things that it is good to have worked out before you get too deep. I’ll probably write down more stuff as I think of it over the weekend so that come Monday I can jump into implementing them.
Since I didn’t write any code I don’t have any new screenshots, so instead here is a sketch from the Kids in the Hall:
So with Wordel out on the Android Market (you should download the lite version or full version) I am starting up on my next game. My first thoughts were a shoot ’em up or another tower defense game, but last night when driving around I decided I wanted to make a car driving game with the working name Speeder. The main hook of the game will be that it will use phone tilt to move the car back and forth on the screen as you race down the roads avoiding other cars and obstacles and such. I’m going with a top down view, similar to a Spy Hunter on NES type look. I’ve decided it would be a good idea to keep track of what I do in the game every day by writing a blog entry here possibly including screenshots and such so here is the first one.
So today I started work. Luckily I’ve done some testing to see how tilt works on the phone so I had code I could copy over to get the right data to move the car back and forth on the screen. I’m keeping it’s vertical location on the screen fixed for right now, not sure if I’ll change that later, but the horizontal location changes based on the tilt. It moves faster or slower depending on how far you are tilting the phone and has a spot in the middle where it won’t move. It will stop at the edges as well so you don’t go off the screen.
I’ve also added in basic enemy cars, though I guess they are really just other cars since they don’t attack you or anything. They move from the top of the screen down towards you right now and they move based on a speed you pass them. For now the speed is the speed I have set in the player car but I’ll want those moving at different rates in the future, the way I have it set up will facilitate that well I think. The cars start just off the top of the screen and are removed just off the bottom of the screen so they smoothly enter and exit the screen. For right now I have a counter to determine when I generate a new car and a max number of cars but that will be changing once I get further into the game.
I don’t have collisions between the player car and other cars put in place yet but that shouldn’t be difficult to add. I have some more designing to do to figure out how I want to handle collisions for both player cars and other cars or even obstacles and such in the future.
I’ve designed some basic sprites for the player car and other cars, nothing fancy but I think they look decent for a start. Here is a screenshot that shows what I have so far, not a lot but I think it is a solid start:
You should follow me on Twitter here or kyrutech here
So this is something that has been bugging me for a while that I just now figured out today by reading the right thing.
Basically in Android when you are making layout objects you have several options on how to present these objects. One of the options is padding, the amount of space around the edges of the object you are placing, but not exactly. Padding is the space inside the object between the edge of the object and the content. So if your object is as wide as the screen, padding pulls in from the edge of the screen, if your object is 100 pixels wide, the padding pulls in from the edge of the 100 pixels.
In most cases that is fine, padding is exactly what you want, but where it was a problem for me were Buttons using a background defined by a StateListDrawable. See with a StateListDrawable you can define exactly how things like buttons look when they are pressed, not pressed, focused, and so on. For this to work the StateListDrawable is set as the background to the object, which is where padding doesn’t work. Since background is not content padding has no effect. This drove me nuts until today.
After finding just the right post on StackOverflow I realized what I needed to use was instead the layout_margin option. The margin around an object is in effect the padding for the entire object in comparison to the parent. So if my object is told to be as wide as the screen, a margin will pull the entire object from the edges of the screen meaning the background along with everything else.
In hindsight it makes perfect sense and I can’t see why I didn’t realize it before, but now that I do I just wanted to post about it so if anyone else has the same trouble maybe this will help them.
And since this is a boring post if you don’t care about Android, here’s a Morning Musume song
Work on my word game comes along well. I still need to decide on a new name for it since Word Drop already exists.
I have single board gameplay finished up. Basically you decided if you want to play on a single board for 1, 3, or 5 minutes and see how many points you can score. I don’t have any high score tracking in yet but I will track high scores for each time.
I also have basic gameplay for continuous mode set up for me to test. Basically you are given a goal score to achieve in the time given to you at the beginning of each level. If you make the score goal you get bonus points for the amount of time left on the clock when you finish and move on to the next level that will have a harder goal to reach. I have to make sure my score goals work out and that passing from level to level works as intended as well as making sure game over if you don’t make your goal in the time given works. I believe I’ll just have one high score list for continuous mode, though if I make different difficulties available for that mode I’ll split up high score tracking for those.
I want to make a board clear mode, where you are making words to try and clear the board, but I need a good method of checking the board for words. The way my word dictionary is currently implemented that might be a difficult thing to do. If I was still using the trie it would be simple, in fact I have it all written up, but the trie killed memory. I may come back to this as a puzzle mode with levels set up with a soluti0n in mind that lets you completely clear them, but I do still need a check for remaining words.
I have a weird issue where my X tile displays in gray after modifier tiles show up on the board. I have no idea why it would do this but it does it every time. It is pretty low on my list of things to work on right now, but that’s something I’ll have to check into at some point.