What did you learn?

[BeyondCloister]

So now it is all over, what did you learn for your experience with creating an entry for uDG 2003?

Personally, I learnt that you cannot please everyone.

By some twist of fate it appears that the people who helped beta test and gave plenty of feedback were the ones who liked my entry and grasped its simple concepts.

It just happened to be that those who did not like it, could not work out what to do or whatever did not let these points be known before the 4th Nov deadline.

Next year I'm going to have to work out some way of encouraging those who don't like my entry to try it before then end.

[skyhawk]

do not do 40 frames of animation per direction if you can't draw that many

[applekid]

ExposÈ is the greatest lifesaver in the world when drawing graphics. Switching from window to window on minimal sized screens was all possible thanks to Apple!

[OneSadCookie]

* Don't post negative feedback

* Don't start and abandon 4 different games before deciding there's not enough time left

[BeyondCloister]

Don't post negative feedback

At the risk of this thread also being closed down ;) negative feedback is at least 100 times more important than positive feedback as long as the developer gets it in time.

[NCarter]

[list=1]
It's just not possible for me to work every evening and weekend, even when I have free time. I just don't have the motivation. Therefore, it's important to choose a project which can be developed in a much shorter period than the allotted competition time.

Real life can really screw up your plans. Again, having a less ambitious project is probably the answer.

Cartoon animation is very difficult when you have no talent for it. In general, creating media for the game takes a lot of time and effort, and I'm not always in the mood for it.

Testing other people's games is almost as much work as writing your own, and can take serious amounts of development time away from you! ;)
[/list=1]
My plan for dealing with the first three points next year is to invent a game which requires almost no external media files. I have an idea which fits the bill exactly, but I'm going to keep it to myself for now!

As for point four... well, testing games and writing (hopefully) intelligent commentary is time consuming, but it was fun to see other people's projects develop and improve. It was worth getting involved.

[Muffinking]

stop going to university... cause it allowed me to not update my game at all over the course of the voting period which probably lead to a large number of people that hated my game.. cause it sucked in the form I had it.

I seriously haven't even opened Project Builder in a month.

stupid school teaching me crap I don't want to know anymore.

grrrr :mad:

[Jake]

I learned ALOT, and I will write a postmortem about it sometime soon (regardless if I won or not)

[Louis!]

Though not a must for some weirdos (Dave) Most of us can't pull off a reat game on our own.. Having a good team is a huge plus.. What I've learned though is.. Getting people interested is one thing.. Figuring out how to deal with those people is something else ^_^...

So stay organized, stick to your design.. and take the time it takes to figure out how to parse out the work load.

Oh.. and be more of a hardass about deadlines with your people... I'm just too nice a guy ^_^... I guess..

[MattDiamond]

Great idea for a thread! Post-mortems of the winning entries are all very well, but we can take their "what went wrong" lists with a grain of salt, can't we? :-)

I won't know much until I see the scores and the list of winners. And even then I won't know for sure. But some early conjectures:

- don't bother spending time on anything subtle in the game unless you are sure that the player will play it more than once. (In other words, gameplay comes first.) In my case, I'm pretty sure the majority of players didn't notice that I had 4 different musical tracks, and that the game remembers which one it played last. They'd have to race more than one time to notice it.

- when in doubt, give more control of the gaming experience to the player. Some people apparently didn't like my choices for asteroid density and size. I could have given them different "courses" for them to choose from. I did a better job with this last year.

- tell OSC that he isn't supposed to run the whole race at top speed! :-)

Joking aside, there's a serious point here. Since players are in a hurry to try a bunch of uDG games, the players may need to be told some basic strategy up-front, or taught it via the game. Don't expect them to take the time to work much out themselves, unless you can get them totally hooked on your game almost instantly.

- the trend this year seems to be, a handful of games wins most categories. Won't know for sure until tonight, but last year each category had a winner and a runner up, plus 2 overall winners. I think 9 distinct entries won something. This year they had three winners in each category, plus three overall winners. PLUS an editor's prize. Yet: they had to increase this to FIVE winners in five categories just to get up to 13 distinct winners.

What does this mean? If I'm not imagining things It means that even more than last year, a few games dominated the contest. We can expect this trend to continue in the future unless the rules are changed, interest in the contest wanes, or all entries become equally, amazingly good. How I personally should deal with this apparent trend is what's keeping me up at night, because I'm not liking some of the answers. (More on that topic in the future.) But I should wait for the final list of winners, my thinking on this might be flawed.

- Beta testers: my best beta tester from last year couldn't test my game this year because his Mac wasn't good enough. Of all the other friends who offered to test it for me, not one actually did so before voting began. I had FAR fewer bugs this year than last year even though my code was much more complicated (pats self on the back) but I should have posted a rough version of the game to the iDG forums a few weeks earlier than I did. This might have netted me feedback when I still had time to make significant changes.

- Of course I learned some technical stuff. Some more OpenGL, some Cocoa, some performance tuning techniques.

- Have realistic expectations. With so many fine entries, now I'm just hoping that I placed in the top 10 in a category or two. But you know what? Maybe that should have been my goal in the first place. It's not as brag-worthy, and doesn't come with any prizes, but it would be pretty cool. It would mean that maybe the game wasn't a complete write-off...

[diordna]

1. Plan more

2. Don't expect people to read the Read Me, even if the title of aforementioned file contains a threat

3. Plan more
("That's because it takes twice as much work as perseverence!")

4. Don't keep ALL ideas (you'll see why in my postmortem)

5. Start early (I started before the deadline and even now I feel like my entry is half-done)

6. Don't expect to stay motivated

7. Get an artist who's actually experienced in the kind of graphics you need, not just any old artist

[Jake]

Originally posted by diordna
6. Don't expect to stay motivated


I agree 100%. It is very hard to stay motivated. Sometimes a lack of motivation turns into a lack of time... I hear so much complaining (not just this forum, but everywhere in real life) about people not having enough time to do stuff, but what it really means is they value other things (such as TV and other things) more than programming (which isn't necessarily a bad thing), so its not really "I go to school and have chores with no time for programming but i wish i had more time" but more like "I have a busy schedule and with the few hours I have I would rather do other stuff".

[reubert]

Biggest thing I learnt, would have to be that it is possible to make games, and half decent games at that, and you dont have to be a rocket scientist to do it.

Second biggest thing is that programming can be as addictive as cigarettes.

[PhilStroff]

Originally posted by Louis!
Having a good team is a huge plus..

You betcha!

Other musings...

Focus on getting the framework for a game idea complete "end to end" as soon as possible even if it means you have to stub in crude placeholder graphics.

You can then take your time and strap on the fun fluffy parts later at your lesiure, in parallel with beta testing (beta testing? What's that?).

Plan ahead on not having enough time... make sure the project has some "optional" parts that can be sliced off if necessary due to time constraints.

If you break up with your fiance, you'll have a lot more free time to do last minute compo stuff ^_^

Hook up with talented, enthusiastic, marginally insane people and feed off their energy.

[Nevada]

1. LAZINESS IS THE ROOT OF ALL EVIL!

The thing is, I had SOOOOOO much time to improve my game (Mine desperately lacked gameplay) but I was just too freakin' lazy! I know most people say "I was too busy" or "I just didn't have enough time", but me, I had too much time but no motivation. I spent the whole time kicking myself in the ass and I still am. This being my first non-METAL game, I think I should really continue and see where I go with this.

2. Work on the little things last.

The main reason why my game lacked so much in gameplay. I am aware that gameplay should always be number 1, but I spent so much time on subtleties. Why? Maybe because I was intimidated by it. But now that the pressure's off, I'll try to see what I can do...

3. New technologies.

I just switched to C++/Carbon at the start of UDG, so I learned a crap load of new technologies. I'm not sure it was UDG which inspired it but it did coincide.

[DaFalcon]

This is a very cool thread indeed -- it sounds like the participants all got something out of it, even if they didn't win. It also makes me feel guilty because I wasn't able to play the games until a couple days before the voting deadline, and even then I didn't post feedback. If I'm not a participant (oh but I hope I can be!) then I really would like to be a part of the feedback process to help everyone out a little before the contest :-) Great bunch of games, everyone -- it was a lot of fun, and I can't wait until next year ;)

[KittyMac]

Just a few quick ones:

[list=1]
Especially when you get a brand new Mac, make sure you spend enough time running on your old machine. Its really easy to fool yourself into thinking your code is fast and efficient when running on a 1 GHz G4 instead of the 333 MHz G3

Although it is generally good to create code with an eye towards future use, sometimes it is also more advantageous to code the simpler, more restrictive method instead (specific example is the polygonal collision code... making a few assumptions about the structures or even using simple bounding boxes would have lessened the flexibility of the code but improved the performance and lessened the amount of time spent).

It's cool to have a musician, even one who has never made game music before or is even that knowledgable about computers. She simply wanted to make music, and more importantly needed something to want to make music for!

Platformers are much harder to make than I originally thought it would be. I thought things would be easier this year if I made a platformer, HA!
[/list=1]

Cheers,
Rocco

[Superpig]

1. Don't enter the competition if you don't have your own Mac. Uhm, I'll see what I can do on this come next year. :)

2. Don't rush the packaging.

[Hugh Rayner]

1. Get one or more other people to help me make the game.

2. Get people to actually download/test/vote for/comment on the game.

3. Don't make a puzzle game because people don't seem to like them. :(

4. Vote for own game.

[Jason Colman]

What did I learn ?

It's hard for me to make really simple, elegant gameplay that makes it immediately obvious to the player what to do. I hope I get better at this!

[Fenris]

Platformers are much harder to make than I originally thought it would be.
I hear you big-time. They are nightmares! :)

Although I dropped out (twice) I still have a small piece of wisdom for you all:

Take pride in this. Never forget it.

You finished a game. Hook over the FlipCode Image of the Day archive (http://www.flipcode.com/iotd) People do incredible stuff there, and it's easy to feel really bad about oneself when you see what's up there. But, remember: 95% of what's iotd'ed is tech demos or half-finished games. As far as getting into the industry goes, having finished something is lightyears further than a tech demo. Be proud, grasshopper.

Now, send your uDG IOTD:s! :)

[Bachus]

Well, I have to write a post-mortem, so you can learn it all then. But...

Gaichu finished 5th in Polish, 8th in Sound, 11th in Graphics, 15th in Gameplay, 23rd in Originality, and 10th Overall. This tells me two things: 1) Voters don't know original games. Argonaut, Detox, Lightning's Shadow, Primate Plunge, and WMD are all clones of popular games and scored higher in originality. I'm not saying that Gaichu should be voted higher, I'm saying that those games should be voted lower than 3s for being clones, and they weren't. 2) Voters wouldn't know good gameplay if it bit them on the ass. ;)

Other things:

- It's hard as hell to get comments for your game. I've gotten more comments *after* the contest was over than in the entire three months before voting started. And I've had my comments thread up since August. Next year I'm keeping hostages in my basement and forcing them to comment.

- When you actually get said comments they're usually good advice.

- Three months isn't too short to develop a decent game.

- I'm cheating next year.

[NCarter]

One other point of interest: it seems that it's possible to do quite well even if you do no promotion whatsoever. I thought that as others were putting up news items, impressive uDG pages and amazing personal web sites, my game would pale into insignificance because no-one would notice it. Clearly the voters are prepared to take the time to try the entries even when they've never heard of them before. Good for them!

Originally posted by Fenris
You finished a game. [...] ...having finished something is lightyears further than a tech demo.

Finished? More than a tech demo? Whoops. ;)

[MattDiamond]

Originally posted by Bachus
Gaichu finished 5th in Polish, 8th in Sound, 11th in Graphics, 15th in Gameplay, 23rd in Originality, and 10th Overall.

Where did you get the overall rankings and scores from?

[gatti]

Originally posted by NCarter
One other point of interest: it seems that it's possible to do quite well even if you do no promotion whatsoever. I thought that as others were putting up news items, impressive uDG pages and amazing personal web sites, my game would pale into insignificance because no-one would notice it. Clearly the voters are prepared to take the time to try the entries even when they've never heard of them before. Good for them!

Finished? More than a tech demo? Whoops. ;)
Yeah...but it still kicks ass. The game has potential to become a really cool game where the player has to wipe out the enemies that have infested the cities. Throw in a little story, 10 different stage settings, 10 more enemies, and some big bosses and that's that. (I've really only spent 5 minutes with each game and if your game has these things already forgive me.)

I also really like the over-pixelated look and you have very easy controls. The gameplay and moves can very easily flow into a DragonBallZ game. Use that tech demo and push it to the big boys ;)

[David]

I just split the lightmap/optimization posts into the OpenGL and 3d forum

[BobimusPrime]

I see that my original post which was addressing what I learned in the uDevGame 2003 competition got taken from the "What did you learn?" thread in uDevGame 2003 and placed in an optimization thread for OpenGL. That's very interesting.

Maybe you should toss my response to Matt's post in that thread as well considering that's where his post currently is. (Thanks for fixing this :) )

[whogben]

all to often I got bored with Y3K and so skipped it to work on games I cared about. Next time I will try to pick a game I care about and then work on that.

[Carlos Camacho]

- I'm cheating next year.
I hope this is a joke. If not, coming from a winner, and a game that did well in the contest, I am extremely dissappointed.

[Holmes]

I figured I might as well start here since I have to write a post-mortem.

On the subject of voting:

Place a link to voting in the game itself. This is for two reasons:

The first is you'll get many more votes, meaning less from uDG contestants who may be inclined to vote a bit lower on games to increase there own vote (not accusing anyone, just human nature). We tracked voting links on our website. Of the 223 people we directed to the uDG voting page, 205 were directed from a link in the game itself.

The second reason is that the voters you get will be more inclined to vote favorably. By putting the link in the game itself, you can be assured that a larger percentage of people voting for your game were actually able to get the game running. By refraining from adding the in game voting link until the voting starts you are also much more likely to get voters who have played the most recent version.

On Playing Nice With Other Toys:

Pause the game when in windowed mode and the application is not the foremost application. If you can, avoid even redrawing the screen, this puts CPU usage down. People like being able to switch back and forth between chatting and your game without being blown to smithereens.

On Teams:

If you have an artist, don't spend lots of time making your coder art. I spent hours making my horrible photoshop art, and in the end very little of it remained in the game.

If you don't have an Artist, get one!

Be nice to your team, share your wealth! Last year I gave my musician the Harmon Kardon speaker set we won out of uDG. This year I'm giving him Reason 4.5 (if we can get it). I also promised him (sarcastically at the time since I thought it was an impossibility) I'd buy him an iSight if we won first place. Well we did, and I'm keeping my word. Sharing profits, even if you can just say "if we win I'll give you..." helps team motivation.

Listen to your team. Your team is best critique of your work. They are both familiar, so aren't afraid to tell you you're not the king of the world, and they've tested the game more than anyone else (besides yourself). It's hard to bend from your will. I originally had Argonaut as a non-scrolling game where you're ship would wrap around the screen. I eventually bent under the pressure of my team and a few others and made it scrolling.

[Bachus]

Originally posted by Camacho
I hope this is a joke. If not, coming from a winner, and a game that did well in the contest, I am extremely dissappointed.

Of course it's a joke.

But if a bunch of this year's winners mysteriously "disappear" sometime between now and next year, I'm certainly not going to be involved.

:D <- See? Smiley. It's a joke.

[Bjoernke]

I learned that I had a project of too much complexity. The testers/gamers couldn't figure out what was happening in Pantheon, and I did not invest enough time in relation to this complexity (aka didn't get finished). On the other hand I had a very complex game, not only in relation to the user interface but also in code and internal structure. And I'm kinda proud that i was able to handle this kind of project all on my own. I also think that this would have not been possible in this way with a c like language (as ppl in the chat know i don't like these). Next time i will make something simpler, and also use more time on the projecting phase, nothing beats a good thought out concept.

[Carlos Camacho]

Time to raise this thread back from the dead. Some of you learned some things in 2003. Did you apply that to 2004? And what did you learn in 2004? (Besides that people love to hate bugs.) Before answering, be sure to read all the comments from 2003.

[skyhawk]

if you have polish, then nothing else really matters

[arekkusu]

Except *cough* gameplay.

[JustinFic]

1) Learn to use the contest to gauge your own strengths, weaknesses, and limitations as a developer. Personally, I found that I can easily project my visions of gameplay into the game and throw in a dash of personal style to boot. My weakness has to do with my artistic talent, and the fact that I don't have any.

If you don't have an Artist, get one!

Amen. Leading into:

2) Team up. Have at least one programmer and one artist. Ideally, have a musician and some web development skills amongst you as well. Being a lone wolf sucks. Even if you CAN do everything, you won't be able to do it as fast as two people. Plus, it's burnout protection. Motivation is contagious. So team up!

3) For uDevGames 2005, the winning entry will feature you fighting off drunken zombie insects in a nanoscopic mining spaceship in Ancient Greece. While you're doing this you have to use your set of giant pincers to dig through the snow and find all the gold nuggets and send them in a horse & cart to Bristol, before the whole freakin' place fills up with water. You heard it here first! :ninja:

[ThemsAllTook]

Pick a project that's appropriate for 3 months, not one that should take 6 or more.

- Alex Diener

[skyhawk]

3) For uDevGames 2005, the winning entry will feature you fighting off drunken zombie insects in a nanoscopic mining spaceship in Ancient Greece. While you're doing this you have to use your set of giant pincers to dig through the snow and find all the gold nuggets and send them in a horse & cart to Bristol, before the whole freakin' place fills up with water. You heard it here first! :ninja:
I'm getting right on it!

[PowerMacX]

Gameplay. Gameplay. Gameplay. At least 0.09 more!
Also:
* Add features sooner, instead of waiting for bug reports before enabling them
* In-game instructions!
* Bullet-time isn't fun for everyone... at least the way I implemented it...
* SDL_mixer has built-in OGG support... I shouldn't have spent an entire week :blush: trying to build a custom version of OpenAL to play it when it was already available in the sound API I was using to begin with!
* Blender export scripts work fine until you need them.
* Texturing models is HARD without the proper tools.

Finally, gameplay can mean "simple". If it doesn't, a tutorial level is a must...

[Taxxodium]

2. Don't expect people to read the Read Me, even if the title of aforementioned file contains a threat

So very true, I forget how many times I have received mails from people using my apps where the only replay I gave was: "please read the Read Me file"

As for what I've learned, even though I didn't participate (except for the music stuff):

1. Just enter the contest, even when I have no idea of a game in the first month
2. Be more active on the IRC channel
3. and like it was said many times: plan!

Next year, I'm entering the contest so be affraid :p

[willThimbleby]

if you have polish, then nothing else really mattersCynically I have to agree with you, people seem to vote 5-irritation instead of 0+enjoyment. Not even gameplay will save you.

In-game instructions!Spot on.


Simple is good, and some types of games (really good games) like (the ones that require more work) Industrial Revolution can't compete with the simple and polished in *voting*.

As for my tips
1. Don't use ODE
2. Don't bother with OpenAL
3. Test Test and Test
4. Keep it simple and polished

[phydeaux]

* Bullet-time isn't fun for everyone... at least the way I implemented it...
* SDL_mixer has built-in OGG support... I shouldn't have spent an entire week :blush: trying to build a custom version of OpenAL to play it when it was already available in the sound API I was using to begin with!
* Texturing models is HARD without the proper tools.


A couple notes here- I felt there was not any point for bullet-time in your game, since you didn't have to do anything particularly intricate to avoid enemies. Since it didn't help you any, it just wasted your time (this is similar to bullet-time in Prince of Persia/Sands of Time- my friends and I played through the game and almost never used the feature in combat, just for dodging traps, since intricate movement was required. In Max Payne you need it for jumping corners, as you'd again need intricate movements to avoid all the incoming enemy shots. Bullets moved a lot faster in Max Payne than Okugai, as well, if I recall correctly.)

SDL_mixer does support OGG, but SDL_mixer functions very poorly and eats up a lot of CPU. It does work great if you just want something very simple and fast to get up (I think I implemented Audio in my game in about an hour, tops.)

Texturing is probably easiest if you have something to give you a texture atlas. The way I ended up going is just linear-mapping different parts of my models, which probably didn't look as good as it could, but was certain sufficient.


As for my tips
1. Don't use ODE
2. Don't bother with OpenAL
3. Test Test and Test
4. Keep it simple and polished

I have to agree with this for the most part, but I think if you have some experience with ODE or OpenAL you probably can use them without a hitch. I used ODE for the first time in this project, and it worked great for me. Your problem was that you made all cars boxes, which hurt the dynamics. OpenAL I heard a lot of people had success with.

I have to echo what a lot of people are saying- if you spend a lot of time going for rich, intricate gameplay, you are leaving yourself open for losing on polish, which in turn probably determines a weight on the rest of your categories (it's a lot easier to be superficial about judging, so a lot of people will only notice the polish, and not give much thought to much else.) This is just if you want to win, though, but I think there are other goals of the contest, such as finally getting to try and make a game that you've been itching to.

[willThimbleby]

I do have experience with both of these, and BitRacer uses fairly involved ODE. My problem was that ODE forced me to make all cars boxes. The other geometries aren't good enough for fast collisions.

My issue with OpenAL was that AFAIK (on the Mac) it provides nothing more than 3D spatial sound (no doppler etc). I can do that myself much more easily, without the hassle of OpenAL.

[skyhawk]

the only reason I used openal, was that I already had it in the engine... so why not just use it?

though in the future I might consider FMOD

[PowerMacX]

A couple notes here- I felt there was not any point for bullet-time in your game, since you didn't have to do anything particularly intricate to avoid enemies. Since it didn't help you any, it just wasted your time (this is similar to bullet-time in Prince of Persia/Sands of Time- my friends and I played through the game and almost never used the feature in combat, just for dodging traps, since intricate movement was required. In Max Payne you need it for jumping corners, as you'd again need intricate movements to avoid all the incoming enemy shots. Bullets moved a lot faster in Max Payne than Okugai, as well, if I recall correctly.)

I know, I was only going to implement bullet-time when you were about to die, so you could "transfer your spirit to another body", but couldn't finish it on time. Still, I found it useful when trying to get to the ship with low health, especially on level 3.

SDL_mixer does support OGG, but SDL_mixer functions very poorly and eats up a lot of CPU. It does work great if you just want something very simple and fast to get up (I think I implemented Audio in my game in about an hour, tops.)

I made a very simple C++ wrapper for OpenAL, which I used on my CMG entry wanna-be "Failed", but the 3D effects were very disappointing to say the least. As for SDL_mixer eating a lot of CPU, you're probably right, but the game was mostly GPU bound, so I could spare a few CPU cicles ;)

Texturing is probably easiest if you have something to give you a texture atlas. The way I ended up going is just linear-mapping different parts of my models, which probably didn't look as good as it could, but was certain sufficient.


My solution: sphere mapping :p

I have to echo what a lot of people are saying- if you spend a lot of time going for rich, intricate gameplay, you are leaving yourself open for losing on polish, which in turn probably determines a weight on the rest of your categories (it's a lot easier to be superficial about judging, so a lot of people will only notice the polish, and not give much thought to much else.) This is just if you want to win, though, but I think there are other goals of the contest, such as finally getting to try and make a game that you've been itching to.

I just saw the polish scores... I want to see that 3rd decimal! :cry:
I guess I should have added a background picture to my .dmg :lol:

[JustinFic]

I have to echo what a lot of people are saying- if you spend a lot of time going for rich, intricate gameplay, you are leaving yourself open for losing on polish, which in turn probably determines a weight on the rest of your categories (it's a lot easier to be superficial about judging, so a lot of people will only notice the polish, and not give much thought to much else.) This is just if you want to win, though, but I think there are other goals of the contest, such as finally getting to try and make a game that you've been itching to.

Well said. IMO, you're either going to focus on gameplay, or everything else. The reason for this is that testing your gameplay takes so much more time than testing graphics, or sound. Want to test a new sound? Put it in, and play once. Does it sound good, yes/no? Bam. You've tested that sound.

Testing gameplay requires playing through your entire game many many times. Want to throw in a new weapon? You have to test it in normal gameplay, and make sure it's balanced with the other weapons. It may very easily break balance, so now that's more work to set things right, and the fix could unbalance something else- it gets complicated pretty quickly.

The result is that you'll spend the vast majority of your time on just getting your gameplay spot-on, and won't be able to spend as much time as is needed tightening up your app.

But honestly, this isn't a problem if you just team up. The programmer focuses on the gameplay, and the artist focuses on providing polished art and sound.