Separate names with a comma.
Discussion in 'Indie Basics' started by princec, Jan 14, 2006.
There you go then. Proper UI = major motivator.
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.
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...
It appears to add 0.5s to my loading times ... not a big deal
same here... Still, It doesn't mean he's wrong just that we all have different methods.
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.
 Did someone disable the smilies or what?
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.
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.
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.
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.
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!
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
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.
If fancy menu anims bother you when you're developing they're bound to bother your players too...
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.
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.
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.
Mine's kind of big... quite a lot of graphics to load in... well, you'll see.
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.
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.
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.
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.
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!