The Contest Aftermath

Started by
9 comments, last by dmnxia 19 years, 4 months ago
I thought it would be interesting to hear everyone's thoughts on the contest and on how development went, now that the deadline has passed (and post some screenshots of your entries). For me, I had to work down to the wire, I turned mine in with only 10 minutes to spare before the deadline hit. I didn't have a well developed concept of what I wanted to really make until 1.5 weeks before the deadline. First, I thought a space shooter would be neat, but decided against it, then thought some kind of boat racing game would be good, but ruled against that too. It finally evolved into the finished project at 5:45 PST today (just in the nick of time). The game features the player as the ship as he tries to collect as much treasure as he can before the serpent (that green thing) sinks his ship. The serpent chases him faster and faster the more treasure he collects. It was a bit of a rush job and is a little bit rough around the edges (I also really pushed the performance of the phone), but I think it turned out ok: Anyone else want to share?
Advertisement
First of all my journal has a bit of a progress report on my contest entry.

Quite short after the start of the contest I had a 'brilliant' idea of making a freefrom racing game. By only storing a track cross-section and a spline of some sort, the used memory could be reduced drastically, since the entire track needn't be stored in memory. Sections of it could be generated on the fly from the spline and the cross-section.

I though about this for a while, and started coding a spline editor in my own engine. Did a little bit of design on the game.

Then about a month before the end, I started coding the game on top of my engine (I didn't have access to the pc I installed BREW on, and I didn't feel like installing it on my laptop). That went okayish, so after a week or so I had a running version on the pc.

I wanted to do freeform tracks (loops, rotating around track) but when I tested that kind of track the physics broke. So I kept it to a 2d plane for now. Then two weeks before the end I started porting everything to BREW (had access to my regular pc again). That went pretty smoothly, so in 3 days or so all my current code had been ported.

After that I tweaked, fixed bugs (often where I'd forgotten to convert from float to fixed16.16 format), and moved functionality to BREW whenever I found out that I needed to (memory allocation/deallocation, file access, then the bar file). I looked around for models to use, and found a skybox on the internet. Basically I was pretty much done with it last weekend. Since I had some time left, I decided to add some voice samples to spice up the game. That went smoothly as well, although I haven't been able to get the .wav files to load from a .bar file, so they are seperate.

Then on sunday evening I was sort of contacted by the person whose model I had requested to use, and he offered to redo the graphics (he had been working on a GBA racer hobby project). I was okayish with the graphics I had, but updated my pc version so it used the same textures as the BREW version, and sent that to him so he could have a go. Monday evening he sent me updated textures, and I tried out a few of his skyboxes. Finally fixed everything, and was ready to enter. He offered to create a splash screen to finish off the game, so while he was making that, I coded in the splashscreen, and an hour later the splashscreen was in.

I had written most of the documentation in the weekend as well, so I spend the rest of monday evening wrapping up everything, and checking if the game would work standalone.

And the funniest thing? The original memory saving idea didn't even get implemented, I just calculate the entire track at initialization. Doh.
hi. great work, u 2 there. i like your games. the first one seems a little bit more fun(that's because i like to play snake on my cell phone :))). i want to post some shots too, but i can't acces my web server. bad luck. maybe next time :).

so why you guys think that there were such few submissions(as rhino said)? i think that there are attracting prizes, so there should be a lot of people. the development time was enough (4 months), becuase, if we look at the other opengl es chalange, at kronos, there are 6 months and a much bigger project to do(there is are no hardware limitations, only the library is). so why?
Meeshoo, I can provide hosting for a couple of screenshots. Just pm me if you're interested.
I wont be surprised if the Khronos contest sees less number of entries as well.
The more applications I write, more I find out how less I know
Quote:Original post by meeshoo
so why you guys think that there were such few submissions(as rhino said)? i think that there are attracting prizes, so there should be a lot of people. the development time was enough (4 months), becuase, if we look at the other opengl es chalange, at kronos, there are 6 months and a much bigger project to do(there is are no hardware limitations, only the library is). so why?


I was considering entering but my inital run in with lib and getting something to compile and run on the emulator put me off... that and I didnt really have an idea
What we've been hearing from a lot of people was that they perceived the contest as being too hard, which is unfortunate. Although there are definitely some challenges involved, I think that people are able to get up and running pretty quickly.

Anyway, I just wanted to post a quick note that judging will probably be delayed until after the holidays. Most of the people at Qualcomm who will be doing the judging will be out of the office, so there isn't much we can do about it. But just so you know, the number of entries was small enough that pretty much everyone who entered will receive a prize.
i don't think the contest was too hard, because after reading the tutorial here on game dev, all makes sense, and the sdk is pretty well documented.

well, np with delaying, because i guess almost all of us, the students, are going to be on holyday too. personally, i will spend my 1'st day of the year at the countryside, away of the internet and my noisy phone. so happy holidays to everyone, merry christmas and a happy new year :)
I found out a month or so after the contest had already started. I still was trying to get something together but school hadta come first. I had a camera class written, which was easily adapted to use fixed point, not much other existing code of any use though. I did find that a lotta the brew functions annoyingly either didnt work, or weren't documented well enough, so that I had to waste a lotta time figuring them out. For example the function that loads bitmaps from resource files only seems to work on some files and not others (and I dont mean it reverses the colors, it just doesnt load them!). Just when I THOUGHT I'd figured out exactly what specifications my bmp had to have in order to load it properly...it turned out there was something else, which meant I had to spend time writing my own code to import images.
hey, why do you say the sdk is poor documented? i've find it quite well documented, and very easy to use, because once you've got an interface to some object, you know how to get interfaces to all objects. the bmp format supports only bitmap images. if you want to create something different, i've created a binary file where i've put the data exactly under the format i was loading it, so i had a texture converter and generator. if i wanted R4G4B4A4 i put exactly those bits in the file. and all ran perfectly, even transparency. it's correct to say that it's not so easy like windows programming, but i consider that the contest chalanged us to make applications old school. during devel, i fell like programming an 2x86 pc. we were forced to do all kind of tricks to replace the normal functions with fixed point ones and i think that was very cool.

This topic is closed to new replies.

Advertisement