(I’m prototyping a new game (working title: “ChessQuest”) – original post here)
Three major changes:
- You have a health bar, and can die
- The trackball is now supported for movement
- Performance is literally 1.5x – 2x faster
Download link
So, a friend of mine tried it out today, and he couldn’t move around at all – something wrong with his HTC Desire (even though I’ve been testing on near-identical phone, for some reason his phone was losing the input gestures). This evening I did some improvements and fixes until it began to work “tolerably” on his phone – and I threw in some new small features too.
It’s still test stuff – not indicative of the final gameplay, but I’m trying out different basic ways of achieveing the stuff I want to achieve in the later versions.
Overview of what’s changed
- You have a very basic HUD
- There’s a couple of coloured powerups scattered around – red restores health, green increases maximum health permanently
- Enemies actually kill you now, every moment you’re touched by one, your health drains continuously
- You can choose different levels at the start – I included one of the early test levels that was easy for me to upgrade with recent changes. I’ve got another one I can probably add quickly later (one which generates 100% random mazes each time you play)
- The ultra-simple EntitySystem I’m using was running too slow. There’s no simple fix I can see – the ES really needs to be written for performance, if I want it to be high performance – but I was able to do a 10-lines-of-code workaround that took the worst piece of bad performance in my game and made it literally 5 times faster. That’s good enough for now!
- Input system has changed *again* – the Android OS has poor input management, a bit buggy, with an inconsistent programming API, which *also* runs differently on different phones – so I keep trying to do as little work on this as possible. The Android OS is desperately trying to prevent me from doing any prototyping at all – it’s begging for me to write hundreds of lines of code to make up for Google’s inattention there – but if I do that, I will lose all the time I would have spent doing game design and dev, and the whole project will be a failure. So, yet again, I’m putting on a band-aid and dodging the rest for now. But … at least now you can use trackball instead of / in addition to swiping on the touchscreen
- There’s an FPS counter on the screen
8 replies on “Prototyping: Chess Quest v0.3”
Hi, why don´t you try the libgdx library, it is quite performant, and allows you to develop for android and desktop using the same codebase.
We are using it in our games, with the Artemis Entity System Framework, and so far are very happy.
libgdx – http://libgdx.badlogicgames.com/
artemis framework – http://gamadu.com/artemis/
Nice.. I’ll try and peep at this in 2 weeks or so and perhaps you’ll be at a higher prototype level! :)
This hits home though….
>”Input system has changed *again* – the Android OS has poor input management, a bit buggy, with an inconsistent programming API, which *also* runs differently on different phones – so I keep trying to do as little work on this as possible. The Android OS is desperately trying to prevent me from doing any prototyping at all – it’s begging for me to write hundreds of lines of code to make up for Google’s inattention there – but if I do that, I will lose all the time I would have spent doing game design and dev, and the whole project will be a failure. ”
—-
Oh my, indeed isn’t it a mess! MotionEvent is an abomination of what good / proper coding and stewardship of an SDK should be like. Many of us recognized this from the get go when multitouch was stuffed into MotionEvent / the API. It only gets more conflated and worse w/ more things stuffed into it with each API level. In my middleware efforts abstracting input events in a completely component oriented fashion takes a bunch of code and is more than 10% of my efforts; over 70 platform components. The nice thing that my efforts does though is provide a way to efficiently convert to platform neutral events and provide custom plugins at a couple different levels of the input conversion process including an input filter system plugin. For trouble devices / OS API levels one can swap out one or more of the input event conversion plugins such that on the app programming level consistent events w/ normalized data are delivered or as much as possible barring say hardware nastiness re: low quality touch sensor like in the Nexus One!
Yes… I’ve spent more time making things smooth and configurable on the input conversion aspect than anything else. I think you’ll really like the functionality in my efforts especially entity / state input control.
—————-
Ahh.. now that I’m ranting on Android API / framework issues I’ll continue… ;P
One thing that totally shocked me recently and raised my ire when I rolled in some annotation usage to the core architecture for my efforts is how horribly broken annotations are in API levels 1-13. Totally borked / no caching / completely fuxored implementation likely lifted from Harmony and never tested. I don’t even know if things are properly fixed in ICS / API level 14 until the code is out, but it’s absolutely horrendous that a core Java 5 language feature like this wasn’t fixed until v4.0!. Here is a public G+ post on it:
https://plus.google.com/u/0/117904596907381647757/posts/WBxsvqgP4iP
I’m prototyping, so I don’t have time to use 3rd party code unless that code is EXTREMELY narrow in scope, and I know that library 90% off the top of my head, and the source code in the library is 99% complete, and very stable.
libgdx is OK from what I’ve heard, but it seems too broad: I’m not doing any 3D, I don’t care at all about 3D, and if I ever use 3D I certainly won’t be using libgdx … I’ll be using a high-level scenegraphed engine with proper tools integration, or I’ll be writing my own OGL ES code.
To be really useful to someone like me, libgdx needs to be split into about 5 different separate libraries, each of which can be used or ignored separately. Putting it all in one big thing means that the time it would take me to learn how to use it and fix any problems is greater than the time it would save.
Just to be clear: my biggest problem with libgdx is simply: I don’t already know how to use it.
If you’re aiming to do like Kev used to – 8 hours for a complete game – then you don’t have time to spend 2-3 hours learning a new library. That’s 1/3 of your game development budget!
@Adam
Awww. Don’t be so hard on libgdx.. ;P From what I can tell it’s approaching stability / v1.0 though it has gone through a bit of revisions in the last year. It has been more focused on 2D aspects as opposed to 3D though more 3D support is forthcoming. For the architecture decisions made (OOP, static accessors, some library / functional separation, but not too much) it’s one of the best out there. Granted the architecture choices in general excludes it from my direct interests per se, but it’s solid for it’s intended purpose.
There is a reason I haven’t released my efforts until it’s finalized or as close as I can get it, but then again I’m trying to productize my efforts too vs it being an open source project done in free time. I had the opportunity to grab a beer with Mario / Nate of libgdx recently and they are top folks. Mario said he’d fly back to SF (from Europe) and “smack me silly” if I didn’t release my efforts by the end of the year though. ;P Indeed early access release will be out before then!
>If you’re aiming to do like Kev used to – 8 hours for a complete game – then you don’t have time to spend 2-3 hours learning a new library.
I’ll prod you a little though as I recall you mentioning you spent an horrible amount of time dealing with the Android SDK during the last Ludum Dare event and that pretty much consumed your effort for those 2 days. So examining a framework that may take the ease of this pinch is not the end of the world per se.
>Just to be clear: my biggest problem with libgdx is simply: I don’t already know how to use it.
This is a fair assumption though it can just as easily be extended to the larger Android SDK which poses it’s own battles to overcome. I’m of course on the side of middleware / frameworks that reduce such battles though.. ;)
“I’ll prod you a little though as I recall you mentioning you spent an horrible amount of time dealing with the Android SDK during the last Ludum Dare event and that pretty much consumed your effort for those 2 days. So examining a framework that may take the ease of this pinch is not the end of the world per se.”
Hmm. Interesting.
So … from memory, there were two non-game-related time sinks:
1. I had to upgrade my SDK install (my local copy was way out of date), and Android’s install process is terrible.
2. Some of the *high level* OS API’s are difficult to use / understand, and I was rusty on them. I don’t mind ignoring low-level API’s, but in my experience you HAVE to understand the high-level ones – especially for core actions like “rendering” and “input” – otherwise you can’t do anything.
If I were to use a 3rd party library to fix / avoid (2) above, it would have to be:
– 100% of the OS API is covered (libgdx’s website implies that is NOT the case for Input right now – it sounds suspiciously like some aspects of trackballs etc aren’t handled seamlessly)
– the documentation is BETTER THAN the OS API docs (opening page of libgdx docs is blank – every single package is undocumented. FAIL)
– needs very clear, quick, fast tutorials so I can get the part (in this case “input”) up and running in minutes (or seconds). Sadly, there are no tutorials on the libgdx website (a “video” is not a tutorial)
…again, it comes down to two things:
1. how FAST can I get this library working (counted in seconds or minutes – if it takes more than 10 minutes, it would nearly always be quicker just to learn / debug the OS core API)
2. how SLOW might it be to get this library working (because I have to guess at 1. above, so I might get it wrong. I need to know the “worst case” scenario. If I have to wait several minutes to download + watch a “video tutorial”, it’s already failed. I can’t use that library. It would take 5 seconds to scan-read a real tutorial, and get a feel for “how long is it going to PROBABLY take me to install/test/debug this?)
@Adam:
>Hmm. Interesting. So … from memory, there were two non-game-related time sinks
Yeah, I went back and read the LD post and it wasn’t too bad.. ;) I just think things should fall within the 2-3 hour time frame to check out libgdx and be up and running efficiently with it. There are game demos / and essential tutorial source code, but yeah you are right it’s not super polished on the written tutorial front seemingly, but then again it’s not a commercial effort either (not an excuse / but there is no obligation).
Regarding libgdx though, I do have to stop short of fulling promoting it as after all it’s the fully open source alternative to my efforts. I’m glad it’s around to keep me honest though. It is the best of breed solution for what it does in the fully open source / permissively licensed camp.
> It would take 5 seconds to scan-read a real tutorial, and get a feel for “how long is it going to PROBABLY take me to install/test/debug this?
This does kind of nail what I’m hoping to get up with my efforts on launch; a solid set of tutorials. Outside of a polished / nice looking web site w/ good tutorials what else would do you think is appropriate to have besides traction / known apps & games using any given product / framework that makes things enticing enough for you to try?
Don’t care how good the website looks (this is a strange obsession of open-source projects – glitzy logos etc. All you need is a $35 wordpress template and it’ll look more than good enough).
You want to stick the answers to peoples questions on the front page.
e.g. multiple tutorials answer the question: “how much code + architecture + importing 3rd party libs + thinking + etc will it take to do typical tasks”
e.g. getting started guides answer the question: “how long will it take me to get started” (just look how long the guide is, in words)
etc