Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  how many of you have ever...  (Read 6472 times)
0 Members and 1 Guest are viewing this topic.
Offline mill

Junior Member




popcorn freak


« Posted 2003-04-28 20:59:08 »

... completed your hobby projects? Smiley

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 Smiley

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #1 - Posted 2003-04-28 21:13:09 »

They're not incomplete projects, they're technology demos and proofs of concept... Grin Tongue

Hellomynameis Charlie Dobbie.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #2 - Posted 2003-04-28 21:38:12 »

yeah - what he said  Roll Eyes

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline mill

Junior Member




popcorn freak


« Reply #3 - Posted 2003-04-28 21:45:05 »

hahahaha lol, yeah that's one way to look at it Smiley

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #4 - Posted 2003-04-28 22:11:34 »

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.

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #5 - Posted 2003-04-28 22:12:25 »

A technology demo sounds a whole lot better though. I think I'll start using that excuse too  Smiley

Offline Frumple

Junior Newbie





« Reply #6 - Posted 2003-04-29 01:24:25 »

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.  Tongue

Quote
They're not incomplete projects, they're technology demos and proofs of concept... Grin Tongue


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

JGO Coder




Where's the Kaboom?


« Reply #7 - Posted 2003-04-29 01:36:14 »

Me too.

I have tons of (ahem) "Technology Demos".. I think the main reason I don't finish is because as soon as I figure out the hard part to get the 'demo' going I lose interest with the less exciting aspects that are needed to polish it off.

Offline leknor

Junior Member




ROCK!!!


« Reply #8 - Posted 2003-04-29 06:02:31 »

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.
Offline mill

Junior Member




popcorn freak


« Reply #9 - Posted 2003-04-29 07:55:05 »

i'm with swpalmer here. i thought about that and i think i lost interest in the project when ai, collision detection and reaction was done and i was going to work on boring stuff like menues and gamestates and all that stuff to make it a game hehe

i've never liked polishing stuff. i don't care if it's my dad's car or my game Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #10 - Posted 2003-04-29 09:17:16 »

We have a working prototype here. Does that count?

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Breakfast

Senior Member




for great justice!


« Reply #11 - Posted 2003-04-29 09:52:45 »

A working prototype? I think you mean "our work is done here..."

I have got so tired of "incomplete project syndrome" that I am starting to plan for it and try to write all my code in a very abstract and extensible way so that when I lose interest in great project X I can reuse most of the code for the new great project Y and it will pretty much work. Eventually I will complete something. Assuming I don't get distracted working on my epic novel ( 12 pages completed but needs a bit of a rewrite ) my epic album ( 3 songs written but none yet recorded ) ... hmm, perhaps I'm spotting a pattern here Smiley
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #12 - Posted 2003-04-29 09:53:35 »

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

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #13 - Posted 2003-04-29 10:12:30 »

Making an engine or a prototype is challenging and real fun. Making a game/product out of it is hard/boaring work nobody ever volunteers for.

The people I know how manage to really release games instead of engine prototypes ar real tough and busy professionals. That's a very special and highly valuable talent!!

Thats a fact that many (esp. young) people who want to enter games industry underestimate!


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Breakfast

Senior Member




for great justice!


« Reply #14 - Posted 2003-04-29 13:21:26 »

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.

Offline EricTheRed

Senior Newbie




Beware the killer bunny, destoryer of worlds!


« Reply #15 - Posted 2003-04-30 03:10:42 »

What killed ... erm, "temporarily postponed" ... most of my projects was feature creep.  My games usually will start off with a simple, doable concept.  And it grows, and grows (just one more class!), until eventually it explodes in a shower of mangled code.

I agree that once all the fun stuff has been taken care of, I never quite 'find the time' to finish the less exciting work of creating menus and such.

In school, our current assignment is to create a full, working game.  It is next to impossible to find the motivation to write the menu system and level editors, let alone create the actual content for the game.  I tried a different approach this time, however, in that I wrote the menus and editor first.  In fact, I refused to actually work on the game until the shell was finished.  Did this actually help in the end?  Ask me in a month or so! :-/
Offline mill

Junior Member




popcorn freak


« Reply #16 - Posted 2003-04-30 06:15:59 »

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

Offline bmyers

Junior Member





« Reply #17 - Posted 2003-04-30 17:20:37 »

My experience in both games and other software "projects/hobbies" has been:

1)  I can usually push pretty hard for about 18 months on something for 10-40 hours a week (over and above the other 40 hours of work per week).  If it isn't going anywhere by then I usually give up, or "permanently table" the project.  This has happened on at least 3 start-up companies that I have helped to found.

2)  Having more people than just myself work on a project is critical if I want to get very far.  There is just no substitute for having other people who are enthusiastic about the same project, who can take up the slack when I start to fade.

3)  Having the wrong people on a project will kill it -- period.  This has happened to at least 2 of my startup companies.

4)  Starting small and with achievable milestones (aka baby steps) is a really good way to get good momentum going on a hobby.

<motivational spiel>
There was an old printout from aways back that Gordon Walton (who I was working for at the time) had above his desk, about Perserverance.  I don't have the whole text, but it basically was along the lines of :

Genius doesn't create success -- there's any number of unsung geniuses around.
Money doesn't create success -- millions of dollars are wasted every year on failed projects.
Popularity doesn't create success -- blah, blah, blah..
Niceness doesn't create success -- blah, blah, blah..

Perserverance, sweat and hard work, is 99% of success!
And the other 1% is luck...

Gordon is currently the executive producer of The Sims Online and has been successful in the games industry for over 20 years.

Personally, that stupid "motivational" printout has carried me through many dark and weary nights of trying to keep my "hobby" project alive in my mind, instead of calling it quits and giving up.

It's currently been carrying me about 4.5 years on my current project, which now has 9 people working on it and which I intend to make a screaming commercial success.  Grin

</motivational spiel>

Anyway, that's my $0.03 worth...

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2003-05-01 09:43:12 »

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 Wink

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 Smiley

Offline bmyers

Junior Member





« Reply #19 - Posted 2003-05-01 16:23:40 »

Good point on the feature cutting --  as Cas says it is really, really essential.

When doing game design, it is a good idea to brainstorm at the beginning, then start pruning and pruning until you get something that you can do.

And then once you've got something partially done, prune and prune again!

This happens for all games that actually get finished and delivered!

Offline Captain-Goatse

Junior Member




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #20 - Posted 2003-05-01 19:23:26 »

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.
kul_th_las
Guest
« Reply #21 - Posted 2003-05-08 17:03:17 »

Another problem I've come up against has to do with the "adding more features" issue. As languages improve (like Java, in this case), new features to the language often offer new possibilities in the game projects you work on. It's very temping to add new features to a game because of a new language feature. Try not to do it - sticking with your original design instead of bloating it further and further will increase your chance of finishing the project.

Additionally, I have to really give my support to the idea of bringing other people in (ESPECIALLY programmers). I've worked on many game projects over time, and if any of you are like me, you want to make a great game with a lot of cool things, but the weight of the project always gets you in the end, because there's so much code to write that you just loose your motivation. I'm currently working on a game project that will be the first one that I've done with another programmer - and the attitude I've had toward the project since it started in Dec. 2002 has everything to do with working with another person - suddenly my potential workload has been cut in half, and that makes me more willing to keep working. In a couple of months - after the engine is done - we've got an art guy coming in, and art is what he loves to do. So don't try to do everything yourself - get someone else to do what is boring to you, and fun to them.

I think I'd be accurate in saying that most hobbyists are at least doing all the programming themselves (if not everything else as well) - this is not only a whole lot of work, but when it comes to optimizing code, and choosing appropriate algorithms, I think it's critical to have the view of someone else's programming experience.

Also (speaking from a hobbyist's point of view) it's nice to try to start a project with close friends, but don't be heartbroken when they (perhaps people who are hard-core gamers, but lack the work ethic) decide they don't enjoy working on the game anymore. Dump them! Make contacts with multiple people who might be able to fill the shoes of a group member that loses interest. If you can avoid it, don't build the project team in such a way that any one person is irreplacible.

I find it interesting that people are suggesting that the GUI should be written first. This doesn't seem logical to me. I understand the idea of doing the boring stuff first, but it seems like a GUI should change as the project evolves - it would be rather incredible if you could use the GUI you developed on day 1 as your final GUI on day 400. I think we all hate doing GUIs. On my current project, the other programmer only joined the project on condition that he didn't have to write GUI code - and I understand. So we're dividing the work - I'm doing the GUI and some supporting classes, while he does more of the engine code. This may not sound like much fun, but I think the fun of making a game isn't so much the programming, as it is the idea that you can take an idea and make it come alive. What I get out of this deal is a game that I'm interested in bringing to life, and some help in doing it! What's better: making another "tech demo," or making a completed game that gave ample time to both gameplay and good interface? Besides - working on the GUI doesn't mean I'm not involved in the game design (which is the really exciting part for me) - it just means that the GUI is my part of the actual work.
Offline mill

Junior Member




popcorn freak


« Reply #22 - Posted 2003-05-09 14:33:29 »

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

Offline mill

Junior Member




popcorn freak


« Reply #23 - Posted 2003-05-10 11:29:09 »

... and 1.5 is coming soon as well. what are super-cool-must-have features in that release?

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #24 - Posted 2003-05-11 21:54:16 »

IME, and from what I've been taught by people older, wiser, and much more bitter Cheesy 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 Smiley). 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!"

Smiley. 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 Smiley.

Quote
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.


Quote

I have got so tired of "incomplete project syndrome" that I am starting to plan for it and try to write all my code in a very abstract and extensible way so that when I lose interest in great project X I can reuse most of the code for the new great project Y and it will pretty much work. Eventually I will complete something.


Quote
My experience in both games and other software "projects/hobbies" has been:

2)  Having more people than just myself work on a project is critical if I want to get very far.  There is just no substitute for having other people who are enthusiastic about the same project, who can take up the slack when I start to fade.

4)  Starting small and with achievable milestones (aka baby steps) is a really good way to get good momentum going on a hobby.

<motivational spiel>
There was an old printout from aways back that Gordon Walton..</motivational spiel>



(P.S. great motivational spiel Smiley )

Quote

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.
5) get someone independent to do the graphics


Quote

Additionally, I have to really give my support to the idea of bringing other people in (ESPECIALLY programmers).

... but the weight of the project always gets you in the end, because there's so much code to write that you just loose your motivation.

... the attitude I've had toward the project since it started in Dec. 2002 has everything to do with working with another person - suddenly my potential workload has been cut in half, and that makes me more willing to keep working.

...So don't try to do everything yourself - get someone else to do what is boring to you, and fun to them.


...and one thing I slightly disagree with:

Quote

I find it interesting that people are suggesting that the GUI should be written first. This doesn't seem logical to me. I understand the idea of doing the boring stuff first, but it seems like a GUI should change as the project evolves - it would be rather incredible if you could use the GUI you developed on day 1 as your final GUI on day 400.


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 Sad). 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 Sad.

malloc will be first against the wall when the revolution comes...
kul_th_las
Guest
« Reply #25 - Posted 2003-05-13 19:13:44 »

Well, I have to say that I'm not familiar with the acronym "MVC" so perhaps there's a good chance I have something to learn here.

MVC - referring to "model-view-controller"?

I've always built my GUIs with a minimum required UI first - meaning the least fancy UI that I can get away with and still provide full functionality; then coming back to things when the game is fully working (as far as the engine is concerned) and completing the graphics and other UI components when the game is otherwise finished.

So - if you don't do it this way...educate me. Give me the skinny on the MVC model.

EDIT: When I talk about making changes at the end of a project, I don't mean rewriting, for example, the rendering code used to represent the world. I mean instead the rearranging of components, or the adding of some extra GUI features (perhaps to make something more accessible). The rendering code I write changes little over the life of the project (so long as it works, that is).
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #26 - Posted 2003-05-13 20:08:21 »

Quote

MVC - referring to "model-view-controller"?


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.

Quote

I've always built my GUIs with a minimum required UI first - meaning the least fancy UI that I can get away with and still provide full functionality; then coming back to things when the game is fully working (as far as the engine is concerned) and completing the graphics and other UI components when the game is otherwise finished.


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.

Quote

So - if you don't do it this way...educate me. Give me the skinny on the MVC model.


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.

Quote

EDIT: When I talk about making changes at the end of a project, I don't mean rewriting, for example, the rendering code used to represent the world. I mean instead the rearranging of components, or the adding of some extra GUI features (perhaps to make something more accessible). The rendering code I write changes little over the life of the project (so long as it works, that is).


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...

malloc will be first against the wall when the revolution comes...
Offline mill

Junior Member




popcorn freak


« Reply #27 - Posted 2003-05-14 06:33:53 »

GridBagLayout works just fine in apps. i usually use the null layout as layout in games.

and damn you write essay-long posts blahblahblahh Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #28 - Posted 2003-05-14 07:52:37 »

Quote
GridBagLayout works just fine in apps. i usually use the null layout as layout in games.

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 Smiley.

Quote

and damn you write essay-long posts blahblahblahh Smiley


Noted Cheesy. 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...

malloc will be first against the wall when the revolution comes...
Offline mill

Junior Member




popcorn freak


« Reply #29 - Posted 2003-05-14 08:04:54 »

nothing wrong with long posts it's just that i've noticed you always write very very long posts (not just in this thread but in all the others as well) Smiley

perhaps you are using GridBaggy the wrong way? dunno what the correct way is but i usually use GB for the main big layout and add panels here and there.

i then use another layout for the panels depending on what's in then.

i've tried three aproaches in Java over the years:

1. all layouts apart from GridBagLayout since at the time i found it hard to use

2. GBL alone. this works extremely well apart from it generates a LOT of GUI code and takes time to get it right.

3. GBL and the others at the same time is what i use nowadays and it's very fast to write and i can make it look whatever i want it to look like.


i haven't tried a GUI tool in Java yet.. it's on my 20 km long todo-list though.

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (25 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (13 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (43 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!