think the hardest part of puzzle games would be the design.
The programming would be easy compared to other games
- Davaris

Davaris wrote someting on the other thread that made me think.

the "fun element" in puzzle games relies 90% in game design,
else depends on graphics, sound and other stuff.
it was just yesterday when I realized (testing a friend's
peer to peer backgammon game) that once the game concept
is fun, there isnt much left to work on. programming that took
him only 2 weeks, and thats only because he just learned
DirectPlay.

did the fact that it took him so little time make the game
flawed it's fun and playability? not at all, nor do I think when I
play (fanatically) Dexteritie's logication.
I (or every experienced programmer) would be able to program
a puzzle game in month of time. Working on the game concept &
design will take me way much more.

my point is, that when its comming to arcade/action games
the "fun element" relies more on programming&graphics.
is that the reason why we hardly see good Indy arcade games?

"One of the most difficult tasks men can perform, however much others may despise it, is the invention of good games -- and it cannot be done by men out of touch with their instinctive values."
-- Carl Jung

It depends, I think. Fitznik took me a long time to write. I had the principle game idea very early on. The old Apogee game Pananitzu had many levels with different styles. I only really liked one of those styles. I decided to make a game with all levels of that one style.

I had a playable version of the game within a month, for sure, but it took much longer to get everything nice and polished.

On top of that was the problem of levels, I had to make 63 levels that were all mind bending in their own way. I had a few people help me, but that was quite a dificult part.

Having said all that I had a flash of inspiration about a month ago and have finished a game based upon that idea. It was a much simpler game concept though (and didn't need levels designed).

With regards to programming a scrolly, action game. That is what I am working on now. It's a bigger job programming wise than Fitznik but I wouldn't say hugely so. Art is a different story. The artist for Fitznik is doing tilesets, and a different artist is doing character animation. Over all though I think Level design is going to play a big part in the end.

Level design is getting more complex all round. Games can do more so level designers have more to put in. The tools are getting better but I think it's still more work over all. It seems like it will only be a few years time when the only people that will be able to design buildings in first persion shooters would be real architects. You may end up with physics engines that make levels collapse under their own weight otherwise :-).

[I'll stop now before I drift too far off topic]

Designing good puzzle games can be extremely difficult and challenging. But once you have the design done, the technical work is pretty much all downhill.

Dweep, for instance, took four solid months of design work (which didn't include any level design). Then the art, programming, music, sound effects, and level design were all completed in the last two months. I think the game has about 23,000 lines of Visual C++ code.

The final output of those first four months was a document just a couple pages long. But that was worth 90% of the value of the project. Dweep only has about 10 different objects, but deciding just how each of those objects would interact took an insane amount of time. The final design was very different than the original concept, where I started with multiple Dweeps that you couldn't control directly (similar to Lemmings). I also cut a lot of objects/ideas that caused problems. Some of the objects I cut were batteries (used to power lasers and fans), magnets (used to attract/repel metal objects), puddles (pour a water bucket on the ground, and Dweep will get wet each time he crosses through it), and a few other ideas.

Good puzzle game design takes incredible patience. You don't feel the same sense of progress like you do with programming, where you can see lines of code and new features appearing. I see design as a more exploratory process. If you try to force your ideas to converge too quickly, it often fails to work.

Programming is like looking at a forest and determining the best way to reach the other side. Design is like looking at a forest and determining the best way to explore the whole forest. The problem is that you may explore the whole forest and not like what you find, in which case you have to start fresh with a new forest.

Steve: did you work out the entire design on paper first, before writing any code? It seems to be (sometimes at least) hard to predict what features will work and won't without testing them out. I'm curious if you worked out all the problems in your head or did you try some things via prototypes to see if they'll work?

I did only a little prototyping for the lasers and mirrors in the game. Most of the design work involved determining the set of game objects, and I didn't see a need to prototype them. I could tell on paper (or in my head) if the objects would lead to rich enough gameplay.

Hmm,

Well from experience creating an arcade game is not easy. It's true there is more coding involved but there is also a lot more balancing as well. Every time you add a new game element you need to tweak and balance the whole game, which usually requires playing it trough from start to finish a few times.

Now this process can go on for quite a while. At least when you finish a level in a puzzle game you have finished the level and you can move on. When you change one parameter in an arcade game you usually have to change some more to make it work at least that was my experience with Dreamstars.

Jai Shaw