... completed your hobby projects?

i have only finished a couple of things in my spare time: a pong clone, some http log analyzers and a ftp log analyzer.

i have tons of half finished crap lying around. i started on a racing game about a year and a half ago but after a while it got boring and i started doing something else. it's like 60% complete and i just decided to finish the damn thing!

i'm telling you all this because if it's not finished within one month i want all of you to nag on me like crazy! this time i won't start on something new, even how damn tempting it is!

whish me luck!

in the meantime, you can tell me all about your never-ever-gonna-be-finished projects

yeah - what he said  

I *never* finished anything. And even when I did, I still say it's not finished so that people might believe it could get better.

I've been working on a 2D tank game with turrets and different weapons and such for the past year and it's nowhere close to being playable. Interestingly, I've seen quite a few other people saying that they were making a tank game, but so far, I haven't seen anything. I hope to get it done by summertime, but I've got a lot of high school exams in the next couple of months. So I guess my excuse is that I've been too busy with school.  



Actually, I tend to see my projects as proofs of how much of an incompetent programmer I am.

I think most of my failed pet projects have been due to poor planing. After a while I forget where I want to take the project and lose interests.

We have a working prototype here. Does that count?

"working prototype", that's a good one too for my unfinished-game-excuse list  

What I think people miss is how much of making a game revolves around content creation rather than engine creation. Once you've got your working prototype you need to build all your final models/sprites and animations and that is actually at least as much work. And then you need to get them loading and working properly, which is likely to need more debugging and solving tricky little problems that you hadn't thought of before and then you have to make sure the whole lot fits together and at some point you've got to remember that the whole thing needs to be fun for someone.

well, i usually begin with the most crucial code. without that it won't do anything.

FYI, on the project i picked up again, i didn't start to write the boring stuff it needed. instead i'm improving the AI! more fun, but not exactly what the project needs :/

oh crap

The harder I work, the luckier I get.

I have cunningly surrounded myself with virtual Danes to keep LWJGL ("Juggle"?) bubbling whilst I actually try to get something done with the damned thing. They keep breaking it but that's the price I pay

Alien Flux is the first thing I've come close to finishing in 10 years that's actually professional looking. The secret to success in this project has been:

1) concrete design. Fortunately had a previous game to copy it from.

2) ruthless feature cutting. Really, really, ruthless.

3) writing a to-do list every week, with even the most minute details on it ("write readme", "app icon"), prioritizing each item into "must do" and "nice to have", then categorizing each item into "difficult" and "easy". I do all the "must do easys" first - great motivation to see them getting crossed off the list in abundance

4) do the GUI first. It's so mind-f**kingly tedious doing the GUI when you want to write the game. I did 90% of the GUI before I started the game. The last 10% I regretfully have only just gotten around to starting. It's taken me 3 days just to do the nag screen and instructions screens, it's so boring. I've still got to do the hiscore entry/display screen.

5) get someone independent to do the graphics, and simply accept that they can conceptualize and design them, and their interpretations of my ideas are radically different to mine. And offering him a whopping huge royalty.

Cas

I like what I'm doing, not as a job though. There are plenty of easier ways to make money.

However, I love the engine creation part.

I finally managed to got my camera to work with a single buffer call and although it is a simple task to do, I think it is greater than anything I have done before. This one is actually creative. I believe I have wasted over 18 hours working on it. It is kicking fast too, and simple.

I design everything with parsimony. I do it untill it can't get any simpler. I believe I'm out of challenges for now, but I believe they will be met, when I get back to the quadtree with bsp tree nodes thingie. If I ever get that done, that'll be the greatest thing, then.

yeah i remembered when they included fullscreen and bufferstrategy. i just had to try those new cool features out in my own games.

IME, and from what I've been taught by people older, wiser, and much more bitter people - and in accordance with many other people's experience, going by the previous comments - there are two key problems to overcome.

1: Planning. "Not planning to succeed is tantamount to planning to fail"; you *can* succeed without planning, but it's guaranteed to be harder. The key fact that has been learnt over and over again in software development is that almost ANY planning ALWAYS saves more time in the long run than it cost to do. IBM was studying this back in the 70's, other people studied it in the 80's and 90's, and I can bet there's someone still studying it now, and discovering yet again that - even 30 years later - every minute spent planning is at least several minutes - if not 10 or 20 - saved programming.

2: Determination/energy/realism/etc. (I don't study software engineering etc any more, so I have no idea what the current terminology is ). Essentially, on a project where "visible progress" does not progress visibly (think about it - and recall the semi-serious quote "every project is 90% complete for 90% of the time"), two things drop off rapidly:

 - Your conviction/energy/determination/etc
 - Your accuracy/cleverness/diligence/etc

I've heard (and witnessed) quite a lot of nutty ideas for overcoming this, but by far the most consistently effective is "getting a new perspective"; the easiest way of doing this is usually to have someone else around, who has a different world-view to your own. Part of the benefit of multiple people with different skills working on the same thing is the "bouncing ideas" and even "gaining strength from each other"; if the AI code is turning out to be impossible, its probably NOT at the same time that someone accidentally deleted all the artwork. So, you can usually count on other people to balance your mood - and even to listen to your problem and say "I don't understand; why don't you just do X? What am I missing?" whereupon you go:

  "DOH!"

. The easier way out of this problem is of course to work on projects where progress progresses - hence the frequently given advice to people starting a first game to "do something REALLY simple, so you get successes rapidly". I'd also say that Cas's use of a pre-existing design is in this same area - it not only reduces the time and effort needed to plan, but it also gives you a ruler to measure your progress by, and feel that you are getting somewhere - and that it's the *right* somewhere!

I strongly suggest that anyone interested in this (and some of the people quoted below) look at Extreme Programming (XP); it's not a "perfect solution to all your problems (tm)", but some of the techniques are VERY helpful on things like games where you invest a lot of long time without the game seeming to improve much. On the face of it, XP can seem to make it more difficult - because it "slows you down" in your coding; in practice, you feel you are always moving forwards, one small step at a time (because of the way XP works).

P.S. Hope you don't mind being quoted en masse - you all made such good points I just wanted to highlight them .







(P.S. great motivational spiel )





...and one thing I slightly disagree with:



Not to pick on you, but just to offer some advice: I agree that your GUI could evolve in a way that makes it non-sensical to do it first; but IF this happens, you probably haven't learnt how to make GUI's properly. GUI's are intrinsically very very easy to extend and modify - unless you don't know the tricks of the trade (sadly, most tutorials, books, etc don't teach these tricks ). They tend to be much easier to extend than general OO code. One of my major bitches with java is that a lot of the GUI stuff isn't as extensible as it should be. There are also a lot of methods that are far more complex to understand and use correctly than they should be.

I'd hope that you are already very familiar with the M/V/C pattern (or architecture, if you prefer...) if you create ANY GUI code - it's used extensively by Swing, and Sun has good documentation describing it, and how they "modified" it. Personally, I can strongly relate to their reasons for altering MVC, but I'm still sitting on the fence as to whether their changes are worthwhile.

There's quite a lot of "patterns" that cover GUI stuff, although I'm afraid I don't have good resources to hand .

Yeah. IIRC, it's an amalgam of the patterns first mentioned in the very first famous Patterns book...but it's been a long time since I looked!

To be brutally honest, MVC is just the most simple OO approach to building a GUI - it's the way a lazy OO programmer would do it (a more diligent OO programmer would have more than just three aspects). IIRC, the Listener pattern used very widely in Swing and AWT comes from the first source - certainly it works particularly well with MVC GUI's.

Essentially, you make classes whose purpose is:
 - "to hold, manage, access: data" (models)
 - "to view, format, beautify: data" (views)
 - "to alter, manage the alteration of: data" (controllers).

In addition, complex features like skinnable GUI's are much easier to support in MVC. All you do is alter your views to be skinnable; NOTHING else needs to change. Another classic feature that often makes GUI code get horribly unclear and bug-infested is complex feedback on data-manipulation (e.g. verification that you typed in a phone number that ONLY contained digits, or perhaps a popup-dialog that appears when you set a font-size of less than 3 - i.e. unreadable) - these are easily implemented inside Controllers, and easy to maintain if they stay there.



If you have a really good GUI API, then things like layout should be trivial - both to implement and to alter (note: Swing and AWT are not really good, they particularly suck at layout, and BOTH still have several major bugs I'm aware of in their layout engines).

In this case, you should be able to make a great GUI from the start. Then at the end, when you have beta testers, you make small changes with ease.



IF you use Swing/AWT it doesn't quite work that way. If you use AWT, it works nothing like that way (note: my sole reason for not making any more apps and applets that are 1.1-compatible is that, inadequate as Swing is in many ways, it's also excellent in some fundamental areas, and MUCH better than the AWT).

IME, for most projects you need to create (or beg, borrow, or pay for) some fundamental extensions to Swing to make it "work properly". One of the excellent features of Swing is that it is very extensible (although I can off the top of my head think of two bugs in the Graphics class that have existed in 1.2, 1.3 and 1.4 that mean you have to re-implement some Graphics methods just to get a fully working JComponent class!).

For instance, NEVER use JTable. It is crap. There are actually companies that SELL alternatives to JTable, because it's so crap (and you could do so much better!). Try not to use the JTextXXX classes in java < 1.4, because there are really really major bugs that weren't fixed until 1.4. IIRC, the oldest one even has an API doc suggesting you don't use it - and use the newer alternative instead! (it's the one that tries to behave as similarly as possible to old AWT style TextXXX classes)

For my two most recent games, I "completed" the JLayeredComponent class, which is basically a half-arsed attempt at a GUI component that is missing most of the required functionality. I'm not sure if the programmer at Sun got bored, or if they never meant it to be publically accessed, and only built it to be used by their own internal-frames classes etc. It was about a week's work, all told, but now I have really effective easy-to-use JComponent that you can add additional JComponent's on top of, making it trivial to separate the different theoretical parts of your game into separate rendering classes. And for effectively no performance hit!

When doing this, I used the following main concepts:
- Always make each model an interface
- For each kind of view and controller you create, make an abstract class (normally called a "base class") that implements some or all of an interface (i.e. you might have NO abstract methods)
- Always make your abstract view or controller implement ALL the mouselistener, keyboardlistener etc methods with empty methods
- Put lots of useful methods into the base classes
- wherever you take an M V or C as an argument to a method, code the method to accept the base-class version of that M V or C

Now it's really easy to add new custom GUI components - they get all the benefits of the WindowAdapter, MouseAdapter etc just by extending ONE abstract class.

You can now also have GUI's where most components are instantly interchangeable, because they are supertype-identical, and all code was written to only use methods common to all your M V and Cs.

Finally, I suggest that things like your own "Popup DIalog Editor" are crucial - you write them once (Sun's ones are utter crap) and then you can use them forever more. If anyone would like one, I've got one that I'll giveaway - as long as someone volunteers to start a SourceForge project for it, and is prepared to maintain it. It allows you to create Dialog boxes on the fly with loads of features but is really easy to use, and can even load itself from an XML description - making it even FASTER to change your API.



Yeah. ALL the Layout Managers are broken in at least one way. The most commonly used (and most useful, in many ways) BorderLayout is (and always has been) f***ed beyond belief - due to a rather simplistic/lazy implementation that was never improved. I have great sympathy for anyone using them - they ought to be a delight, and instead are a curse. There are even JavaWorld articles dedicated to providing full source for a better layout manager that actually works AND is easy to use...this is pretty tragic. Shrug. If I had the time, I'd make my own Layout Manager, probably one that implemented most of the table-layout features of HTML (I haven't yet found a public domain one that does that). HTML tables do it SO well that Sun should really pull its pants up and just copy it!

All this is, of course, In My (Not So?) Humble Opinion...

For some definition of "works". My definition for a LayoutManager includes the concepts of:
"easy to use"
"very quick to use"
"easy AND quick to visualise mentally what you will end up with"
and most especially:...
"very easy to arrange hierarchically, so that you can make new sub-sections of your GUI without having to refer to the layout of the rest of it each time you start changing a sub-section".

IME, GBL fails on being slow to implement (it's a real pain doing any serious layout in it) and requiring you to think about ALL elements of the design at the same time. This is NOT how a LayoutManager should work - they are designed specifically to reduce the complexity of laying out an application.

In fact you could say that GBL is not a true layout manager: it does hardly any "management" of the layout, and is really just a convenience class wrapping the key functions of Container and Component - making it easier to write a true layout manager. I see it more as a "base implementation" for LayoutManager authors .



Noted . I'm trying to cut down, but I ended up like this because:
 1. There's so much to explain with the open-ended questions people ask here!
 2. ...some of my posts have been badly misunderstood due to a lack of clarity and precision on my part
 3. I'm working on massive distributed systems at the moment, and I fear that the ultra-precise, specify-everything-carefully approach is leaking into my technical conversations outside work...