I recently wrote a game from scratch in one week over at my blog (http://jonbho.net). In C, and the source code is available. Still pending to revamp the design and publish it, hope to do so in the next few weeks.
Kloonie games used to make a game in under a week about once a month. I used to enjoy the lessons he learned and seeing the evolution. It eventually resulted in crayon physics which was a really interesting game. http://www.kloonigames.com/blog/
You might be interested in Shining Rock Software's site [1]. Its a single developer creating a world-building game called Banished, and he has some good insights into the problems of building a complex product on his own.
Great work, you have inspired me to go and write some code.
Could you explain a bit further how you structured your game? I'm using LibGDX too but find the Actors, Scenes, etc. a bit confusing, are you using any of these?
How did you learn LibGDX? With the official documentation and wiki, it seems very complete, but not sure if there's a better resource.
Initially, I also got confused by Actors, Scenes, etc. and did not use it. I figured it out later, but a lot of code was written already. In my code I have a lot of arrays and objects that represent the objects in the game. For example, I have an array named Fleet that keeps track of all aliens. The I have an array named Bullets, and one named Particles and one named FloatingTexts, etc. Now, all these would be Actors and you would place them in Scene instead of having a lot of separate array.
I also used Sprites for some stuff, but I also have a lot of pure batch.draw() calls for one-off copying directly from texture. When you use the Sceen model, you use Actors instead of Sprites.
I used to make games using SDL, so I'm used to blitting the graphics purely by coordinates and just build my own stuff over it, but Scene-Actor stuff is very well done, I will use it for my next game for sure. It also comes with some nice UI elements, which I also had to invent myself in mine code.
The best resource was asking questions at Stack Overflow. You can also google for some stuff, but beware, some of the code out there is suboptimal as you can see in my post about making screenshots.
A few years back I set out to make an angry birds clone called 'Silly Squirrels' just to learn more about how a game is made, I ended up using Box2D and libGDX and made similar progress relatively fast. It was low level enough for me to really appreciate the structure of a game (rendering loops, game logic, art, physics, etc) without having to dig too deeply into any one.
Really great that you documented your progress, I imagine it not only helped inspire others, but also serves as a great refresher if you step away for a few months and come back.
Yes. It also served as an incentive to keep me going. I did not want to have an empty day without making any progress, especially as some people were reading the blog from the start and I did not want to lose their attention by skipping.
A cool idea and very impressive time management (though I am not sure how much time he spent every day). I liked the fact that he spent very little time in polishing the graphics by selecting a simple enough setting and refrained from creating his own music even when he knew how to. Often it is too easy to get sidetracked on such thing when one should be focussing on delivering a great gameplay which the author seems to have rightly done.
It was mostly 12-14 hours a day, with maybe 2-3 days of 19 hours. Actually, I'm feeling a little sleep deprived now, so I'll probably make it up in the next couple of days.
There where other stuff I also did, like doing a lot of testing and bugfixing, or reading the docs, but those were too boring to blog about.
I'm curious about the decision to not use Cocos2d, which would include a nice GUI for quickly designing 2D game scenes (CocosBuilder). Are there any particular downsides to it, or was it just not considered at all?
My own experience with Cocos2d is very positive, but I've only used it for some game prototypes, not full projects. (Cocos2d-html5 on browser and Cocos2d-x/js on native, sharing common JavaScript codebase.)
Actually, I did look into cocos because RoboVM is still not cosidered proven and I plan to develop or port to iOS at some point.
The main problem is googlability (did I just invent a word there?) of cocos stuff. Google is indexing all the old cocos iOS stuff higher and it's really hard to find anything, especially if you never did develop for iPhone and have no clue if the article you're reading is about old or new cocos. The docs are great, but often you need to find examples of different specific topics and those are usually on someone's blog or similar page where only Google can take you. Also, on some forums I found this way, people were trying to help cocos2d-x devs, but those helping were iOS devs and answers were like "this is the way it works on iOS but YMMV", as they were unsure if the API has changed or not.
Maybe it's a great library, but all this left me with too much confusion, and I picked something that was rather straightforward and still supports desktop and iOS if I decide to port.
I've had similar problems googling for Cocos2d help. OTOH, because you can run the CocosBuilder-generated game in the browser, it is very easy to experiment in the JavaScript console and figure out how the various JavaScript bindings of the C++ classes work.
My own judgment is that it's relatively difficult to get a Cocos2d project to work across all platforms (HTML5, iOS, Android). But once it works, the development iteration loop is very comfortable and fast, because you just refresh the browser to try the current version of the game.
CocosBuilder is now abandoned, I think. The creator is building something similar (cocos2d only, not cocos2d-x) and the cocos2d-x guys are building CocoStudio (Windows only, no javascript, for now). Although I love the idea working with javascript for cross-platform development, the whole project feels immature.
The Settings screen displays an email address that you can send feedback to, but it’s not clickable, so rather than memorizing the address and then composing an email, I’ll just write my feedback here.
I got stuck on Wave 70 – the grow-when-shot boss just wouldn’t die. I think it is a bug. At first the boss grew when I shot it, but after a while it didn’t change, and always stayed the same size and pinky-purple colored. I kept shooting it for 3 to 5 minutes and it still didn’t die, though none of the previous bosses took longer than 40 seconds to defeat. All the while, the boss kept dropping minions, which I was able to kill normally. I could only just see that when I shot the boss, a “10” points indicator floated up from the boss, partially cut off by the top of the screen. I’m on a Samsung Galaxy Nexus.
Also, I lost my progress in the game when I tried to change Settings in the middle of the game. This was because of a UI problem. The pause screen has buttons at the bottom for “Exit game”, “Settings”, and “Continue current game”. After continuing to the Settings screen and looking it over, I pressed the bottom-left button with the left-facing arrow. But that turned out to be the “Main menu” button, which dropped me out of the game completely, making me lose my progress. (Luckily, I didn’t mind too much in that game, since I couldn’t progress past level 70 anyway.) I see that if I press my phone’s Back button instead, I can return to the pause screen and then press Resume – but there should be an explicit button for this too. I think the best fix for this is to replace the “Main menu” button with a “Back to pause screen” button if you got to the Settings screen from a pause screen.
I also noticed that I can’t press the Reload button while my other finger is still touching the screen just after shooting a bullet. That is, multitouch doesn’t work. It is a little annoying to have to stop shooting completely to reload. But then again, having to reload manually at all is also annoying, and it’s part of the game, so you could call this behavior a feature, since it makes reloading harder.
Finally, I was a bit confused about the name of your game when I read your blog on my phone, since the Play Store link ends with “com.bigosaur.backyardpanic”. Maybe it’s too late now, but it would be less confusing to change your app’s package name to “com.bigosaur.droneinvaders”.
Apart from those problems, your game seems like a fine phone game, with enough gameplay elements to make it interesting. Having to manually reload is not as bad as it could be, since you give feedback that you are out of ammo and have to reload from multiple sources – flashing Reload button, missing ammo bar, small “Out of Ammo” white text, and click-click sound effect. And it’s impressive that this game was put together in so short a time.
Wave 70 is not a bug. The trick is in the Grows When Shot description. This boss gains energy when shot, but loses when he releases a drone. You really shouldn't shoot at it at all, just destroy its minions until he shrinks to zero. Hmmm, maybe this was a design error on my part, mixing deep thinking in a shooter game, I'm not sure?
As for the settings going back to main menu, you're right, this is a bug. It used to work properly, but I refactored some code just before releasing and this got broken. I'm uploading a fixed version as I write this, it should be up in the Play Store in a couple of hours.
Having to pause shooting to Reload is deliberate. At first, there were no Reload button, but adding it added a dimension of difficulty to the game, and made it more interesting.
As for the package name... it's complicated. As you can see in my blog at Day 1, I choose this name at first, and then I built a libGDX project using it. At some point when I finally decided on Drone Invaders name, I tried to refactor and Eclipse was not able to do everything. libGDX projects are set up by some kind of a setup wizard, that does some find/replace of strings and whatnot, so it seemed impossible that I would be able to do this manually. Although, not that I think of it, maybe I could create a new empty project using the wizard, and then copy all the source code there. However, I would lose all the ratings and stats I have so far on Google Play as it would be treated as a completely new game. :(
And I guess I will have to make e-mail clickable now ;)
"Hmmm, maybe this was a design error on my part, mixing deep thinking in a shooter game, I'm not sure?"
Not at all, sounds like a classic final boss achilles heel to me. I haven't played the game so I don't know how blatant the clue to defeat the boss is.
Before each boss shows up, a short message shows up for about 2-3 seconds, telling the player what that boss is about. In this case, it says: Grows When Shot.
The only thing is that this is not the final boss. This is the boss on level 70. Next one where you need to figure out the message meaning is on level 120, and there are even more bosses after that.
Looks amazing! I've recently undertaken a similar challenge, but I'm afraid that Android is going to be a lot more intensive than iOS since there are so many more device shapes, sizes, etc. to deal with. I'm curious, how did you test and tweak for the great range of Android devices?
I developed most of the game on SGS2 which has 480x800 resolution which covers more than 70% of the market (depending on whose stats you look at). Then I tested on Nexus 7 and Nexus 10 tablets, and bunch of phones that friends have and I've seen ugly streching effect, so I first tried just to keep the aspect ratio with black bars (letterboxing and pillarboxing), but this did not look too good.
Then I enlarged the background nebulas and stars textures and the game adapts to the screen. If you have 16:10 screen it fits perfectly. If you have wider screen, there would be some free space at the sides. On Nexus 7 and 10, that's just some 10% and it's hardly noticable.
On devices that are wider than 16:10, say some phones with 480x854 resolution, I simply extend the playing field upwards. So it's actually a little bit easier to play on those devices as aliens have more space to travel before they reach the bottom. I thought about increasing the initial speed modifier for those devices from 1 to 1.0675, but I did not do it. I somehow wanted to speed of the game to be constant.
Using libGDX as a library makes testing all this very easy, because you can run in on your desktop as a regular Java application and you can resize the window to whatever you like. I have 1680x1050 monitor, so all phones and most tablets fit the screen.
The only thing I regret is not having Nexus 10 at the very start and make the game optimal for 2560x1600 resolution. There are many popular Android games that do not support this fully (graphics get blurred). The only 2D game I've seen so far is Angry Birds Star Wars II. So maybe if I supported this high resolution, I would have a better shot at being featured in the Play Store, since competition is low. If this version goes well, maybe this is exaclty what I will do next: build a HD version.
original mac version took a week, ported at weekend, polished following week. i did have help on the art side (i.e. almost all of it is not mine) and the audio track was composed by someone else
the thing is though, then once you have a good stock of code to work from. this sort of thing shouldn't even take a week (!)
libGDX is awesome! Without knowing anything about it, I built a simple Bejeweled Blitz clone (but with a hexagonal playing field) in one weekend. Too bad it's kinda stalled now, making very slow progress, and I don't even know why.
Has anyone else done this sort of thing to much success?