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.
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.
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 ™”, 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 :).
[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]
[quote]My experience in both games and other software “projects/hobbies” has been:
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.
Starting small and with achievable milestones (aka baby steps) is a really good way to get good momentum going on a hobby.
There was an old printout from aways back that Gordon Walton..
[/quote]
(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 :(.
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).
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…
[quote]GridBagLayout works just fine in apps. i usually use the null layout as layout in games.
[/quote]
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 :D. I’m trying to cut down, but I ended up like this because:
There’s so much to explain with the open-ended questions people ask here!
…some of my posts have been badly misunderstood due to a lack of clarity and precision on my part
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…
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)
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:
all layouts apart from GridBagLayout since at the time i found it hard to use
GBL alone. this works extremely well apart from it generates a LOT of GUI code and takes time to get it right.
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.
Perhaps I should give it another chance. Your approach is good, and I have tried that before, but found I still ended up with hard-to-maintain code. If you know it well enough to use it quickly and easily, then I can see it kind of solves your problems; it certainly has enough flexibility to … but you still have to do a lot of work that should be unnecessary in a modern GUI API.
Good ones are excellent, and I’ve found they can make up for the deficiences in e.g GBL, by making the process of creation and editing simple and easy.
But the only free one I’m aware of that works is the Forte/“One”/netbeans one - and running that behemoth is more than my patience and sanity can tolerate these days.
If someone knows of a free one somewhere else, that can work on live code, automatically ONLY altering the GUI parts of the source class? I’d be very interested to see it…
[quote]yeah i remembered when they included fullscreen and bufferstrategy. i just had to try those new cool features out in my own games.
[/quote]
heh, i had an almost complete game engine in J2d done many months ago, along with a pretty feature heavy level editor and a whole bunch of the logic done - then just as i was starting to add the ‘proper’ gameplay code, lwjgl came out… I havn’t touched it since :-[
people - and in accordance with many other people’s experience, going by the previous comments - there are two key problems to overcome.
