Pearls of wisdom

[princec]

Here's one which I can't stress how amazingly useful it is enough for all you newbies still struggling to finish that first title:

Do the title screen and options and hiscores and menus etc first and completely finish them!!

Don't even think about making a start on the game until they're totally finished.

Cas :)

[Ryan Clark]

Ok, I'll bite! Why?

I've never done this before, so I'm honestly not sure what the advantage would be.

[soniCron]

Ok, I'll bite! Why?

I've never done this before, so I'm honestly not sure what the advantage would be. I'll venture a guess on his behalf: By the time the game itself is ironed out, plays well, and just a total bunch of fun, you're certainly not going to want to be working on the menus. I'm having this exact problem right now; my motivation is extremely low since all that's left is maintenance.

[princec]

Spot on. I'm bored shitless of Titan Attacks now, thank Christ I've only got to put in a few more levels and sound effects and it's finished and I don't have to do all that crappy menu work. I can't think of anything more demotivating. Apart from, say, having to rewrite it in DirectX so I can get it on Xbox 360.

Cas :)

[Ricardo Vladimiro]

And if you are working with contracted artists?

[princec]

Then get the buggers to do it first!

Cas :)

[Dan MacDonald]

Another reason is that it forces you to consider the features and style of your game. How are people going to enter your game, is there going to be multiplayer and singleplayer? When you think about saving or loading games do you allow the user to save anywhere, use a waypoint system... filling out these menus and options actually makes you think a lot about systems and their implication on the game that you wouldn't otherwise. Working on the menu's also helps you codify a look and feel and theme for the game that your happywith before ever adding a single in game asset.

That's why right now i'm building an XML + Lua based gui system that allows me to easily nock out cook UI's without ever compiling a new exectuable. So far it's been a lot of fun to work with and work on.

[Sharpfish]

I agree with this (though it does of course work better if it works for you). I would say do this AFTER a small gameplay prototype though. At least this is how I have developed the current game I'm working on. Not 100% done the menus etc as there was circulatory referencing going on between style in game and front end etc.

However, it did mean I got all the "Mundane" stuff like polished fonts, Gui animations, save game profiles (and selection boxes) etc in as I built.. which means I spent far too long on them probably (tweaking and making look nice) but the upside is, as has been pointed out, I won't have to do them at the end when I could otherwise overlook that final polish and hinder the production of the very area the customer sees first. I think it's hard to stick 100% to just doing the front end because inevitably you will need to come back and do more (if your project is midly complicated and not a straight forward "clone" type).

We are all motivated by different things though so what may work for one may not for another - though in my case I have stayed motivated knowing I have "saved" the best bit until last (the polishing of the gameplay/in game assets rather than the polish of the less interesting stuff)

[svero]

Well what I dont get is.. why is the code not the same code as ultratron. I mean how many times do you have to code highscores, or options dialogs. That stuff is pretty much ported directly over to new games for us.. takes a day or two tops and thats only if we get fancy and add some special effects or something. Generally it can be done in a few hrs not including graphics.

[Reanimated]

Thats quite an interesting path to go down. Ive always felt that leaving "trivial" things like menus and UI's would be something done relatively near the end as they can provide a boost in motivation since you dont have to really think much. So when your stuck for ages, you could just do some work on the menu system to clear your mind then head back to the main game. Well, that's what I think anyway :D

[zKing]

I actually recommend exactly the opposite. Work on the most important stuff (i.e. core game play) first and make sure you are always putting the most effort there. Why?

1) You want all your early enthusiasm to be put to the best use.

2) It's extremely easy to wake up two months later and realize all you have to show for your "game" is pretty menus. This depressing realization has killed a great many solo/indie game projects. This is especially true as things become "hard" because now all the "easy" stuff is over.

3) If you are working to a schedule, it's _much_ better when things get tight to triage out fluff from the menus than stuff from the main game.

4) Say while you are putting the gameplay together you have a sudden lightbulb idea that causes big changes in style, it really sucks if suddenly your "near finished" menus all now need major re-work. (It's much less likely this aha moment will happen when you are playing with menus.)

5) Do them later/last will reduce the tendancy to make menus too fancy... unlike at the beginning of project when you are high with excitement and want to experiment. A neato menu is cool for about the first 5 seconds that you see it... then its just an annoying slow obsticle to getting into the game.

[DangerCode]

Here's one which I can't stress how amazingly useful it is enough for all you newbies still struggling to finish that first title:

Do the title screen and options and hiscores and menus etc first and completely finish them!!

Don't even think about making a start on the game until they're totally finished.

Cas :)

FWIW, I don't think this is a pearl of wisdom but rather a personal opinion. ;)

And I disagree with it. :D

[soniCron]

And I disagree with it. :D Well, at least tell us why! ;)

[Tom Gilleland]

I've always heard the first thing you do is the T-Shirt. :)

Tom

[gmcbay]

The first thing I do is design the box cover for the special edition collectors DVD. The second thing I do is begin thinking about what will be in the sequel.

[Ricardo C]

Way ahead of you. The first thing I do is plan how I'll spend those big fat profits.

[Fabio]

The first thing I do is resurrecting, then dying, then I get my retirement, then I pay my taxes, then I get my big cheque and then, if I am not bored, I start developing the game. Perhaps one day I'll born, too.. before being conceived, that is. ;)

[princec]

Well what I dont get is.. why is the code not the same code as ultratron. I mean how many times do you have to code highscores, or options dialogs. That stuff is pretty much ported directly over to new games for us.. takes a day or two tops and thats only if we get fancy and add some special effects or something. Generally it can be done in a few hrs not including graphics.
Now funny enough Steve, the code is identical... existing as it does in a jar file that both games share... I just thought I'd mention that because I did all that code ages ago for Ultratron I've basically not had to worry about it at all for Titan Attacks. Well, Chaz has, because he had to redo all the graphics.

Cas :)

[Sharpfish]

So looking at the argument and counter argument (And knowing I have done it different ways in the past myself) I think we have to realise that there is in fact no "hard rule" and the only rule is "get it done".

I am sure you can do a bit of this and a bit of that until you scrape through if you really lack motivation/enthusiasm but if (and important to counter ZKings points) *IF* you feel motivated by the gameplay and KNOW you will put 100% into it, what you have acheived by doing mundane stuff first is hopefully a sheen/polish that greets the user rather than 2 hours (and out of demo time) down the line.

Of course you can do it either way and polish everything, it's not impossible and many people do.. I know that the amount of time the gameplay is taking (and assets) for my game that had I put of making player profiles and all the intricacies of clicking in fields , animated guis and icon changes etc that I *may* have been more tempted to leave it out as unimportant - to "postpone" it just to ship the game. NOW I have no choice, all the stuff I wanted in the UI and Menus is in, I cut no corners because I had time and energy when I did it.

If that means I will cut corners later on in the coregame I don't think it's true (maybe for some but not all) - you know the game itself is what makes the title, in my opinion you are less likely mentally to cut corners on core gameplay because you have done all this great art/menus/UI and it "looks" like a finished game from the front - THIS is what drives you forward to finish the game.

If you start on the game (and I'm talking something midly complex not a straightforward 2D swapping clone) and get frustrated, burned out or whatever - every time you launch if you just see "TEST LEVEL" with a few variables on screen and a crappy looking front end (if any) then you see the task ahead as being an even bigger hill to climb.

The disclaimer to this is that we are all different. Some people get off on doing gui work, some more on coding save games and some on collision detection, so whichever area you generally enjoy MOST I feel you should put off until LAST because your own desires will help drive you. This could mean game first - front end last or the opposite.

And FWIW for my next game I will be flexible and adapt to whatever works that time. There should be more discipline, you would hardly get away with that in the retail industry with set plans to follow - but being able to motivate yourself with no boss or income is hard enough so stay flexible and open to "moving around" your project. Bit by bit it will all come together. :)

[Anthony Flack]

I tend to leave them 'til fairly late, though not necessarily last.

I don't want to have UI to load and navigate through when I'm hammering out the basic gameplay; and of course if the game isn't working out it would all be for nothing anyway.

But I actually don't hate doing UI. In a way, I get a kick out of it - I decided a while back it was time to put all the UI into Cletus because the project needed a lift... and it worked. Now, instead of it feeling like a half-finished project in bits and pieces, it feels like a mostly-finished project with some level design and cleanup left to do. I enjoy doing the UI, just because it makes such a big difference to the project for comparatively little work.

[princec]

There you go then. Proper UI = major motivator.

Cas :)

[Sharpfish]

I don't want to have UI to load and navigate through when I'm hammering out the basic gameplay

I think most people would probably have some flags for that to cut straight to the gameplay / levels on compilation (say a global var or even a quick select / key press thing overlaid on the first menu screen). I know I do, though even without it it's not too bad because the game is fairly simple, for more advanced games yeah it could be a pain - but you can always bypass the menu as I said. :)

[Anthony Flack]

Certainly - but (depending on the way things are put together) it will still be loading extra graphics in and slowing things down a bit... you could bypass that as well, but it's easier still if it's not there at all.

It's not a big thing; but I like to keep everything as lean as possible in the early stages. Also, because having a completed UI can motivate you, I like to save it until I need it...

[princec]

It appears to add 0.5s to my loading times ... not a big deal ;)

Cas :)

[Sharpfish]

It appears to add 0.5s to my loading times ... not a big deal ;)

Cas :)


same here... Still, It doesn't mean he's wrong just that we all have different methods. :)

[electronicStar]

This is the worst pearl of wisdom I've ever heard.
Actually starting by the UI was the instinctive method I was using when I started programming... when I was twelve. Later I realized that the proper way to work is to separate the work in small tasks, but the core gameplay should be the first thing to be achieved, you need to know if your game will really be playable, and the fact to play it (a primitive version of it) will give you fresh ideas for the rest of the work.
And you can ship a game without menus, but pretty menus without a game aren't worth much.
As someone else said, I like to come back to working on the UI when I hit a mental block. It's refreshing and straightforward and it's instant gratification. But you Cas, want to eat the cake before the rest of the meal.:)
As for this idea that designing the UI should serve as a motivator...well, I think you should have enough discipline and method so that you don't need a motivator.

[edit] Did someone disable the smilies or what?

[luggage]

Depends which way you look at it.

I always start with a prototype, this gets cobbled together and once I'm happy the core gameplay mechanics work it gets ditched before I start production code.

When I start production code I go the same way as Cas. Get the main menus in with the basic game then start building around it. This way you can make sure your levels tidy themselves up and you can go in and out of a game. The kind of thing that's easy to let slip if you do just the gameplay first.

It really is a matter of preference - I like to have the game's structure in place as early as possible.

[Tom Gilleland]

If I'm writing the game myself, I usually jump right into the core game coding while using what we call "stupid art". Then as I get bored on it I'll go out and build intro screens, installers, sound, menus, help files, etc. I give the stupid art to the artist who makes final art as I continue to program. Sometimes I do some of the art.

On bigger projects, three of us work on it. Myself, an artist, and a programmer. I usually start first and write a detailed game spec. This spec will change alot throughout the project. The programmer writes the core game, the artist does 95% of the final art, I do everthing else.

On even bigger projects we still have a core team of three. And then we give off specific tasks to contractors or an interns. Basically we think of it as extending the capabilities of the core three. The biggest title we've done had about a dozen people working on it at some point. But most of the work was still done by the core three.

On whatever title we do, I'm the driving force that keeps the product moving forward. So I have to stay focused on the one thing.

Tom

[lexaloffle]

It's not a big thing; but I like to keep everything as lean as possible in the early stages. Also, because having a completed UI can motivate you, I like to save it until I need it...

Yeah - there are a bunch of things that can keep the romance alive. A title screen, level recording/playback, cheat codes, and end of level ceremonys all do it for me. They all make the game suddenly look like a game.

[Sharpfish]

This is the worst pearl of wisdom I've ever heard.
Actually starting by the UI was the instinctive method I was using when I started programming... when I was twelve.


I don't think that would apply to all of us - I know when I started coding (around 1989) I would spend months on JUST the core game - that "was" the game to me, I never even considered "Polish" back then because it was futile and irrelevent (in the context of a game made in your bedroom for your mates or Public Domain freebies). Later I learned to think about the complete process, and yes game design docs (albeit tiny versions thereof) - this didn't mean I had to follow the process linearly (either backwards or forwards) just that you had the overall effect you wanted to achieve and you just got stuck in. Now @ 31 and having worked in the industry (not as a coder though) and seen how big projects are managed, I agree you should do it intelligently and be disciplined, that is, if you are in a TEAM of more than a handful and are working to tight deadlines and using up millions of pounds. The whole point I was making (Not completely agreeing with Cas but seeing his point) is that if you are a small team/one man, then you have flexibility that you can utilise to keep motivated - if that is not a problem for the developer anyway it stands to reason that the best route is then the strict "standard practice" one.



Later I realized that the proper way to work is to separate the work in small tasks, but the core gameplay should be the first thing to be achieved, you need to know if your game will really be playable, and the fact to play it (a primitive version of it) will give you fresh ideas for the rest of the work.
And you can ship a game without menus, but pretty menus without a game aren't worth much.


I agree with the first part (I said this in my first post btw), certainly get that prototype up and running, without it you will have no game - or anyway of knowing if it will even be as fun as you thought. However once you have it and all your tech is in place, it is then down to the individual who should instinctively know which is the best way to proceed (or at least will with experience).

The second part though - that, I feel, is what the "pearl" was trying to help avoid - there are a LOT of shareware games around that play well, and look good but are let down by the small things and especially if they have poor front ends. No they are not as important as the game itself, but in my opinion they are important. Therefore I don't agree that you can (or rather, should) ship a game without a polished front end and that is exactly why I condone the practice of DOING the stuff you may neglect because you consider it less important, first! :)



As someone else said, I like to come back to working on the UI when I hit a mental block. It's refreshing and straightforward and it's instant gratification.


I do agree with that 100%. I mentioned being flexible and there is no better way of getting burned out than getting stuck on something and having nothing else to use your time on while you mull it over. I am still popping back and doing things like credits "screen", high scores pleasantry, Front end Eye candy - even though I'm knee deep in the game, I can't always stay in that zone forever and need a breather now and then - just for something different. However I feel good doing that because the majority of the front end is done and functional and 95% polished. That feels more secure to me than knowing that my whole front end was developed only in those times when I was seeking refuge from harder problems and may not have been giving that area 100% as I should.

So perhaps I could say I agree with Cas but that I wouldn't stress that it should be finished 100% as he said. Also, again I think it's obvious there are far too many ways to skin any cat and we all think differently in varying degrees so in that respect I agree it wasn't really a "pearl of wisdom" more a "this is what works for me". Still nice to debate game development practices for once instead of negative stuff :)

cheers.

[zKing]

After reading these posts, I can definately see both sides of the coin. Particularly using the menus/title screens as a mid-project motivator when things get tough.

I would agree that if you've built a game or really any major software project before you probably know how you work and can pretty much do it however you like. But for those who've never built anything big and may or may not have the skills to even complete the project, I still believe its important for them to get some solid game play up as soon as humanly possible. If anything perhaps those who wouldn't have the skills/persistance to do a full game by themselves will discover that sooner rather than later and either get some help or stop wasting their time.

But yes, I guess its fair to say that I don't leave _all_ of the menu/fluff screens work to the end. I usually build some basic structure early just so that I have basic functionality. And if an artist drops me the slick looking title screen mid way through the project, I'll definately spend the minutes that it takes to plop it into the build.

And my comment about fancy menus slowing things down: I wasn't talking about load times. I was talking about those stupid animated menus that won't take user input as they animate. Or the screen/menu depth requires you to go through 7 screens before you can get into the game. Or in order to make the menu system "cool looking" they come up with a look/control scheme which is completely unintelligable. Both games and DVD's seem to be getting a bit worse about this under the excuse of pushing their brand.

[princec]

If fancy menu anims bother you when you're developing they're bound to bother your players too...

Cas :)

[Talisman]

Do the title screen and options and hiscores and menus etc first and completely finish them!!

Don't even think about making a start on the game until they're totally finished.


I wish you said this a month ago. I'm working on my first game, and just wasted a week "making the menus". I was about to give up on them and do level design instead, but now I think I'll stick at it.

[Evanstaul]

I generally agree with this. I think it's usually true if you're the only programmer in the game. Menus and GUI are extremely boring. I would atleast make sure the core of the game engine is working at the very beginning, then around the middle I would try to finish off all the nice menu look and effects, afterwards the level designs and fun stuff in the game. But then there's also making the website, instruction guide, too much other boring stuff to think about.

[Jay_Kyburz]

Hey, M2c,

I think you should polish as you go. Fix bugs as soon as you see them and replace placeholder assets as soon as you can.

I enjoy working on a game that feels like its polished and ready for release.

The problem with this is that new features take longer to implement.

[Anthony Flack]

It appears to add 0.5s to my loading times ... not a big deal ;)

Mine's kind of big... quite a lot of graphics to load in... well, you'll see.


If fancy menu anims bother you when you're developing they're bound to bother your players too...

It's never going to be as bad, though. There can be a lot of stopping and starting that a developer will do, while a player would never repeatedly start a level, play for 10 seconds and then quit again.

[electronicStar]

Hey, M2c,

I think you should polish as you go. Fix bugs as soon as you see them and replace placeholder assets as soon as you can.

I second that, if you think you can leave those details for the end you are likely to experience a big loss of motivation.
Work like an ant, identify small task, solve them one by one,take note of appearing bugs and fix them when possible.

[DangerCode]

Well, at least tell us why! ;)

Okay, but more than anything I think it's best just to go with what works for you.

For me (or my team) I prefer to approach any project as I would a drawing or painting. Every aspect of it is started off rough and then fleshed in with just about all the pieces being of the same quality as you converge to a final product/solution.

To use my art analogy: In my experience, budding artists will often draw a picture from top to bottom, they'll focus on the face with great detail, then the shoulders, then the chest, and by the time they get to the legs they discover they don't have enough room left on the sheet.

[DangerCode]

If fancy menu anims bother you when you're developing they're bound to bother your players too...

Cas :)

In my experience any menu (any!) is going to bother you as a developer after you've gone though it for the brazillionth time. Eventually you'll be seing the UI in your sleep.

Which may be a good reason not to focus on it too early - you're going to be compelled to change it anyway.

But hey, do what works for you.

[princec]

This is the worst pearl of wisdom I've ever heard.
Actually starting by the UI was the instinctive method I was using when I started programming... when I was twelve. Later I realized that the proper way to work is to separate the work in small tasks, but the core gameplay should be the first thing to be achieved, you need to know if your game will really be playable, and the fact to play it (a primitive version of it) will give you fresh ideas for the rest of the work.
And you can ship a game without menus, but pretty menus without a game aren't worth much.
As someone else said, I like to come back to working on the UI when I hit a mental block. It's refreshing and straightforward and it's instant gratification. But you Cas, want to eat the cake before the rest of the meal.:)
As for this idea that designing the UI should serve as a motivator...well, I think you should have enough discipline and method so that you don't need a motivator.

[edit] Did someone disable the smilies or what?
If you've never heard a worse pearl of wisdom then we'd certainly like to hear some of the better ones from you eh?

I've been coding for quarter of a century now and I've written countless little games in that time and for the last 3 years I've been writing "professional" quality games and I claim that this method is the one that gets the best results in practically every aspect. Maybe when I get experienced writing games I can put it off a little.

However, I've never prototyped a game ever. I just write them and they turn out OK. One good bit about doing the title screen & menus first is that, as DanMc. says, it gives me a theme to work from right from the beginning, but doesn't actually nail down the game. The title screen and menu code in Ultratron is identical to Titan Attacks, and in fact it's going to be the same for the next 4 or 5 games I write. I wrote it first, now I never need to look at it again. Chaz does of course, because he does all the artwork for it and fiddles with the XML GUI layouts, haha ;)

Once your title screen and menu code is all kosher you are then free to write any game you want on the other side of it. Prototype away. Just be happy in the knowledge that you won't have to write it all again once you're burned out after 6 months intensive game coding!

Cas :)

[Sharpfish]

And my comment about fancy menus slowing things down: .... Or the screen/menu depth requires you to go through 7 screens before you can get into the game.

I am not singling YOU out for this, it just reminded me of a good point. It is "good practice" to make the journey from the IIS (initial interactive state/Main menu) to the first gameplay screen as short as possible, I think the "recommendation" is no more than 3 screens/changes or something like that (there was some research done, but your instincts should tell you this anyway).

My point is if you have 7 screens (or more) you should look at somehow trimming it down anyway.

My game (while relatively simple - ie not an RTS ;) ) has 2 "clicks" then you are in.

Click one > START
Click two > select Continue/New/etc from game menu then game starts.

Things like profile selection are best done from the main menu seperatly (or automatically). Of course if you NEED things like "select Car", "select Character", "Select Area" then you can't get away from it and I agree - but in most cases less is more when it comes to the transition from frontend to game - which is probably why I don't see it as a problem - YMMV of course :).

[Anthony Flack]

As for this idea that designing the UI should serve as a motivator...well, I think you should have enough discipline and method so that you don't need a motivator.

You might not absolutely need a motivator to continue with a project, but it certainly doesn't hurt. None of us are robots. We do better work when we feel enthusiastic. And after working on a project for over three years, most of that time late at night when I'm drop-dead tired and would much rather not, I'll take any extra motivation I can get.


in most cases less is more when it comes to the transition from frontend to game

I've been thinking about this a bit too, and while I can appreciate that it's good practice to get into the game as quickly as possible, I also think there's something to be said for guiding the player in gently - a series of very simple "choose this or that" screens can get people into the game in a much neater way than a single bohemoth setup screen.

Of course, resuming a game should be a much simpler affair. One thing I picked up as good practice from console games was to have whatever you chose last time being the default highlighted option, so you can just click-click-click and you're away.

[Jeroen Stout]

I used to make UI's first "when I was little" and none of them resulted in a game. I did also make some games first "when I was little" and none of them resulted in a menu.

Though generally I'm a bit against menus first; menu's are the most basic task and if you start doing them whilst in a creative mood you're greating a great menu without a great game behind it directly as all your motivation is scared off by having 'no actual game', my general throught is. Usually I make the engine first based on some testing content, I make a bit of content, and when I need my save function I build a menu around it.

[Savant]

I'm with the "UI early" camp. The UI is the first thing the user sees when they start up your game and, as such, is responsible for the first impression and the users vibe when first starting to play. It's important, so do the base work early enough that you can polish/refine it as the project progresses.

[Jay_Kyburz]

For me (or my team) I prefer to approach any project as I would a drawing or painting. Every aspect of it is started off rough and then fleshed in with just about all the pieces being of the same quality as you converge to a final product/solution.

Yes, I like this as well.

But when doing this you have to be careful not to be too ambitious because when it comes time to cut features to get the game out on time, you'll be throwing away some work.

This is probably not such an issue for you indies.

[Sharkbait]

I usually start off by re-using a game application framework and since each part needs filling in, I code in (or rip out from an older game), a rudimentary intro screen.. so I'm pretty much forced into doing the UI early. However, I also find it useful as the core game state usually requires parameters that are set from the menus - parameters that would otherwise have to be hardcoded manually several times during development.

I also find it a much more logical progression and gives a feeling to the game that it is beyond a simple gameplay prototype.

[Chris Evans]

I'm in the "do the UI later" camp.

I always work on the core gameplay first. Especially since the early stages are usually pretty organic with lots of experimentation, I don't want to be constrained by a UI.

I guess if the game is really small and simple (or you're making a clone ;) ), then doing the UI first is okay. But for medium to large sized games I don't know how you can complete the UI first without having to toss elements later.

As with a few others here, I also use the UI as a mid-development motivator. It usually only takes me several days to do and makes my demo look like an actual game. But also I want my UI to be designed around the game, not the other way around. People don't play menus.

[Savant]

I think when people (including myself) say "early", it's a relative term. Doing the UI before you had your basic gameplay locked down would be ridiculous.

[luggage]

I use a prototype to lock down the gameplay. If that works I ditch it completely and start again with the 'proper' game. I'll sometimes use Blitz to prototype with too.

That way you're not concerned with pretty code but seeing if different ideas 'work'.

[princec]

I think when people (including myself) say "early", it's a relative term. Doing the UI before you had your basic gameplay locked down would be ridiculous.
Ridicule away :) Technique's worked great for Ultratron and Titan Attacks, and in fact I've already got the UI for the 3rd in the series done and I don't even know what it's going to be yet :D

Cas :)

[princec]

I prefer not to prototype - because my games are all basically trivial gameplay that's been seen somewhere before. In fact I wonder why nearly anyone in here prototypes as I've seen precious few even vaguely original titles from anyone. Nearly all the mechanisms are worked out for you by someone else. You may as well get right on and create the game and then spend the rest of the time tuning it.

Cas :)

[Kestral]

After getting the full list of todo items listed, I will generally put any toolset work and core gameplay items up at the top. Then I will put the "nice but not absolutely necessary" items all the way at the bottom. Taking what remains, I sprinkle the boring items amongst the fun items. When I get to a boring item I have some energy from the fun work I just finished, plus another fun one to look forward to just around the bend.

[Game Producer]

Here's one which I can't stress how amazingly useful it is enough for all you newbies still struggling to finish that first title:

Do the title screen and options and hiscores and menus etc first and completely finish them!!

Don't even think about making a start on the game until they're totally finished.

I disagree. Making graphics first is always a bad move. Instead - use placeholders, test for usability - and finish the graphical elements *last* in your game.

If the first thing you do is the GUI with full graphics (or other gfx) there's a big danger:
* The graphics might need to be changed *

Core first, visuals later. For my opinion.

---

I know there are developers who use spike solutions i.e. they make some part of the game fully finished... if you belong to that camp, then I guess you could make those menus etc. complete.

making a nice visuals in the beginning might attract some press in the early stages. But... as far as I can recall, developer put too much emphasis on visuals in the beginning.

[Grey Alien]

What I like to do is get the basic gameplay up and running and then make the menu so that I can put the game out there for people to try. Then I can start really working on the game, plus you get more ideas about improving the menu too.

[papillon]

While it may need changing later, doing options early may help remind you, especially if you haven't done a lot of games before, to HAVE options and allow for them. which can be much easier to do at an early stage! :)

[Teq]

If you're developing a new engine from scratch, then this isn't as bad a pearl as its sounds, I'm acually working on UI first, mainly because I'm implementing some rather strange font routines, which in turn will be used to gauge the performance of the engine by displaying info, etc, have been playing with photoshopping bloom effects, etc using opengl scales to work out if its even worth rendering in software or just go straight into glsl with it.