Not sure about you guys but I change my mind over what I think is important every few months, I guess as I learn more and try different stuff.. having just read Blah's post in VP I'm quite interested to hear what people's current thoughts on the world are (obviously if you have time outside your current projects).

For my money, this is the state of play..

Java, its a bleady hard language to make indie games in. Its big and clunky at times. However, the productivity benefits make it worthwhile and nothng comes close on that.

- Cas' molebox discovery is a wonder, I can produce a downloadable playable game in less than the gold 5meg limit.

- To make something saleable you need to be looking at 2 months max on development. It needs to be simple to code and to play. Polish is the key. Obviously this goes out the window if you've got a horde of developers and artists, but mostly thats not the case.

- Even if you do eventually sell a game without going through a publisher your not going to be making a living. It has to be more about producing games because you love it than about money.

- Reuse as much as possible - JME/Xith/GTGE/SPGL whatever. However, if its seems to be taking to long to understand it probably is. Don't be afraid to reinvent the wheel just because it goes against some engineering principle somewheer.

- If you're aiming at small quickly developed game stop engineering. Refactor it later, get something running, most of the time what you've got done is good enough and in small games development thats all that counts.

Pretty much: the golden objective is now, for me, to produce games that I can write in a month or so. I tried with Dudester but it just got totally out of hand; Puppytron and Invaders are just perfect.

I've got a niche I want to occupy as well, which is the minigame 320x320 format window, and the $9.95 "budget" indie title.

Business wise I'm no longer concerned with making a living as it's plain there's no sensibly easy money to get (compared to most other disciplines in software engineering). The more we have to write games that we don't want to write in order to make a crust, the more it reminds me I could be programming for a reliable amount of real money elsewhere and keep games development to a small hobby. My targets are now simply to make the hobby a self-sustaining activity that justifies the time spent on it. Like, I want to be able for us to be able to go on holiday with the money earned having paid for all the development etc.

Recently I've learned a lot about game design and I'm far more in tune with being able to write games that other people like besides me. My target is to get the games onto the portals as soon as possible. This was actually technically impossible up until very recently because of distribution problems brought on by Java but yeah hurrah for Molebox and Software Passport is all I can say.

- Reuse as much as possible - JME/Xith/GTGE/SPGL whatever. However, if its seems to be taking to long to understand it probably is. Don't be afraid to reinvent the wheel just because it goes against some engineering principle somewheer.

Somewhat related: Content creation is hard, and probably the reason 90% of hobby/indie stuff doesn't get finished (or takes much longer than expected). Content in this sense also includes the time taken to write UberRenderer2.0 vs. re-using something that already exists.

Time was that I recognised this and thought I could offset it by writing dead easy to use tools (Quix for example has one hell of an easy level creator, probably taking as much code as the actual game). But even then I run out of ideas & momentum to actually be able to create any sizable amount of levels.

Next step forward: randomly generated content. I suspect that I'll find a subtle flaw in this method as well, there's never a silver bullet. (Probably the fact that all my levels will look the same, and be moderatly crap).

At the beginning of the project, take the necessary time to elaborate the scenario, game design and globally the content of each level. Sure technologies and code design is important but I think many developers underestimate the importance of scenario and game design. By doing so, you clarify your toughts, validate them and reduce the risk of producing a game that is not good enough to be sold. Ho! and of course polishing is very important too!

Next step forward: randomly generated content. I suspect that I'll find a subtle flaw in this ...

It's very hard to made random generated FUN content.

I say very hard, but not impossible. We started doing research into this last year, using "fun" evaluation fuctions for A.I. based filtering techniques (here we use genetic algorythms) for post processing random content. Then attempting intergration into the content generation process for a smarter process. I can say that it was a useful experience and should we want to try making large, continuous worlds again, I do think that is one the way to go BUT...

Only if the use of it makes since in your game. Some story driven stuff won't work unless the story accounts for the potential changes/differents between different runs or othe r players.

Making random content FAIR is also tough; by that I mean the "toughness" needs to be eval-ed as well, so different players will have similiar experiences.

Thanks for the interesting replies, nice to see the state of the Onion (as a friend of mine says).

Something that the 4k games taught me was about how to pick projects that can actually get finished.

- Random content - absolutely the best way to go, works particularly well if you're working in a puzzle arena. Random content can sometimes make a game increadibly addictive, take a look a dungeon hack games, random rooms, random monster, but you still want that next level.

- Visual Media - if as a developer you can't draw (i.e. me) its nice to try and aim at being called "stylistic". IMHO, Taxi was a good example. It looked nice because it was simple but clear. Artistic ability zero, but still a nice look.

- Sounds - free sounds are worthwhile. Players don't need a thing to sound like what it is. They need an audible queue that something is or is about to happen. Consistancy seems to be the key.

- Replay Value - random events/data are increadibly dangerous here. Players of small games want to be able to get through and beat the thing, thats why they're playing a small game. If the game changes too much each time they can't learn to beat it. Replay comes from scaling up or down the difficulty a the users request.

- Player customisation - mostly pointless to allow users to customise the GUI etc on a small game. Provide options to change your ship colour on getting a certain bonus or upgrades based on points (see Cas' Invaders).

- Level designers - making these public and building a commuinity works, but only on something that is implicitly easy to understand. It also doesn't work if your level designer is awful. It also doesn't work if the game is very simple. It also doesn't work if designing puzzles/levels in the game takes alot of understanding of the game dynamic... it must be SIMPLE!

Sorry to spout, trying to rationalize some ideas by writing them down. If no one minds I might formalize some of this stuff into an article for JGF.

Somewhat related: Content creation is hard,...Time was that I recognised this and thought I could offset it by writing dead easy to use tools (Quix for example has one hell of an easy level creator, probably taking as much code as the actual game). But even then I run out of ideas & momentum to actually be able to create any sizable amount of levels.

Get a team. Survivor got somewhere because there was one person working on the level editor, another on the rendering + input engine, and another on the AI. All in parallel. Yeah, so it floundered, but I think it was pretty damn good attempt given the trials (losing the renderer author and having to restart from scratch halfway in!) and pressures (tiny time limit) we were under - and the fact that we'd never worked together before.

NB: I've still never even met Kev, nor even heard his voice on a phone.

- To make something saleable you need to be looking at 2 months max on development. It needs to be simple to code and to play. Polish is the key.

Problem, especially if you use Java: it takes 1-2 years until you have your framework ready to develop that fast, even if you have the simplest idea. Cas' 1 month is out of range for me. At least, when I'd try to target portals.

I have now two possibilities: keep Java game development as a hobby (won't have much time for that though), or if I want to be profitable, I have probably stay away from Java. With T2D, PopCap Framework, Blitzmax etc. I can get faster results

No, not at all. I mean selling J2ME games to aggregators, or for better margins publishing them yourself (if you're good enough at sales).

Tried that. Failed miserably. Mobile games are just too expensive to develop, especially the porting to other devices. And most phones suck big time. Every phone has its weird behaviour, and each month new phones arrive. Over all: just too expensive, not manageable for a 2 dev team. If you want serious money from mobile games, you have to play big.

Self publishing mobile games? Do you make money with that? If so: hats off! My opinion: it does not work, because phone gamers don't browse the web for games as indie gamers do. Maybe in the future, until then you have to go through an aggregator. And that's worse than portals.

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