Have migrated this conversation to the new freeplay forums.
http://www.freeplay.net.au/forum/viewtopic.php?f=3&t=5

Also setup a facebook event: http://www.facebook.com/event.php?eid=259316630303

Coming out of the indie game conference Freeplay we are talking about getting together more regularly in Melbourne and comparing notes, networking and having a beer.

Thoughts and discussions . . GO!

Great talk Rory, thanks for speaking. Oh, and the name you were looking for is Jason Rohrer. 

Yay thanks. My public speaking can only improve but I'm pretty happy with my effort. Next time!

Also a bunch of us were talking about starting a monthly beer thing wear we force people at gun point to show us their games. Seems like Melbourne has quite an indie culture going and we should foster more of it. And drinking beer!

Yay i survived talking! I did the "The Art of Getting Things Done" and there were a surprising (read scary0 amount of people there. I don't think i totally sucked which is a bonus, practice makes perfect though.

Got to chat with Petri in the green room which was cool, though couldn't say much except "so crayon physics!". Totally geeked out about it and had to restrain myself as he was working on his speach (ie playing Spelunky ).

Did he end up doing the five minute game? I had to leave right on 6pm so missed the end! And did anyone here attend my talk?

deadlines seem more appropriate to tasks which can be predicted, like building a hut or digging a well, something where there's a clear correlation between hours worked and finished product. that may to a degree apply to the programming aspect of game development, but not to the design aspect, and it's the design aspect i spend most of the time on (even though i'm also the programmer of the games my team makes)

Our societies view of the creative process is poor in my view (this is not making a judgement of your ideas or processes just in general). For example Michelangelo must have sketched the Sistine Chapel several times over. The artists I work with put in a lot of hard yards sketching, producing wireframes and deleting a lot. The point is that creativity requires a lot of work and false starts and there are processes that allow you to bring about creativity. Just like other disciplines require research, planning and prototyping so does design and art.

As there is a fairly standard processes an experienced artist/designer goes through (standard for the individual, they all do it slightly differently) it allows one to estimate and plan. That said I often find it difficult to pin a artist down to make an estimation. I think it may be due to the conundrum that they know how much time they would like to spend on it (as much as possible) and how much time they *should* spend on it. Though this is probably true of programmers so perhaps it is an education thing; more thought required there.

All of this isn't for everyone though. I'm coming from a business background where you must work to a schedule and deadlines. This needn't be true for indies, the ones not trying to live off their games especially. However as an aid to producing I find it invaluable to set estimations on the attainment goals, even if those goals are just personal ones. Knowing where you are is all about knowing where you have been.

When we do a project at my company (I am head of development at a virtual worlds company) there are always estimations of development time written down and agreed to by the team. Estimations need not take the form of a date deadline, a estimation of the number of hours/days/weeks/months a project will take are equivalent or better (esp in the case of hobbyists). They needn't be written down either, though I've found written estimations are followed better by both myself and by others.

There are a couple of reasons to do estimations, even on short internal projects. Firstly it provides some focus, a desire to meet the commitment even if that commitment is to ourselves. Secondly and perhaps more importantly it improves our team. If we think something is going to take a week and it takes two something went wrong. Without that estimation will the team realise something went wrong? Perhaps but the estimation ensures it is noticed.

A debrief aiming at the root causes of the issues will then help address the problems so they aren't repeated (read http://startuplessonslearned.blogspot.com/2008/11/five-whys.html for an excellent debrief technique). A debrief isn't about assigning blame, rather it is about forcing you to look at how you work and what you can do to improve things. The estimation itself may be found to be at fault, which is fine as estimation itself is something that is improved by this process.

With creative and open ended processes (that indie developers encounter all the time) estimations work just as well. You can estimate how long it will take you to come up with a number of ideas, then estimate how long those ideas will take to test/prototype then estimate how long it will take to fully polish the chosen idea. This is process is reflected in the "The Cult of Done Manifesto" linked to by Alec. A focus on drafting, throwing things away, and getting feedback means you spend less time polishing turds and accept failure.

This touches on a couple of the areas I am covering in the workshop (planning and the creative process). The other part of it is leadership and working in a team which are very important skills that many of us fail at.

btw http://startuplessonslearned.blogspot.com/ Lessons Learned is an excellent blog that has many concepts that have applications in indie development (whether you are in freeware or commercial development).

So I put my hand up to run a workshop at Freeplay an indie games festival here in Melbourne, Australia. The topic is "The art of getting things done" and focuses on leadership and management on small teams. A subject I feel is both overlooked and very important, a major cause of project death.

I was wondering if any of you have thoughts and insights you would like to contribute on this topic. I have my own methods and thoughts but varied perspectives on the problem would assist greatly (I will credit you and link to the thread in the handout).

Thanks!

Is file size ever really a problem? Seriously?

In the web app sphere download response time (time for the web page to appear) is certainly a big consideration. For example social network Friendster were in trouble with their users but once they reduced their response time from 9 seconds to 3 seconds they started regaining ground (they're big in south east asia and latin america in case you haven't heard of them). There is a similar problem with downloads and certainly those things the user is not fully convinced on spending their time on.

Unless you're 2D Boy you've got a very limited time in which to get you game onto someone's hard disk and running before they move on. I had a quick look around for data, I have a feeling MMO guru (he started in the MUD scene) and writer of 'The Theory of Fun' Raph Koster wrote a blog post about this but i can't find it.

I was especially impressed with the quickness in which A New Zero got downloaded. installed and running. I leapt into a network game in a few minutes from clicking on the link.

Alex if you read this, make it an option to autorun the game after it installs and get an icon onto the desktop (i know it is beta so you probably just whipped this installer up quick so i'm telling you things you already know ).

We had a network game of this at lunch today at work. One person downloaded it and suddenly half the office was on board. We couldn't quite get the planes working right but the gunboats are certainly fun. It isn't 432kb but it is under a meg which is pretty impressive considering lots of the libraries you often use are bigger than this.

It is in beta so it has a pretty brutal learning curve and the controls need polish. But it is really neat and I love the graphical styling. The network game *just worked* which is always nice.

Falican: fair enough regarding time considerations, but I think there are still a lot of people who can afford that week - or that weekend - to try to solve these issues

I certainly hope people heed this, I live on Linux most of the time and would love to see more games released for it, especially Indie ones.

Regarding Java for gamedev, I've actually been considering it. I'm really not looking forward to going back to C++ STL iterators, which are ugly as hell, and since I'm planning on using OpenGL and there are bindings, it looks promising. There was an event that made me start considering Java, and that was playing Altitude. I suggest you all try it, but I'm probably going to open a thread just for that. It could use some more players, although if you're alone and wait a few minutes, someone is bound to join.

Anyway, technically speaking, Altitude is an arcadeish 2d multiplayer flying game. Physics, some particle effects, etc. The graphics are wonderful, it runs smooth as peanut butter (eww, what?), and is available (currently for free) for Windows, Max and Linux. It is a proof of concept that Java and OpenGL are a viable alternative for professional quality games

Fair warning, I'm a total Python evangelist Python is an excellent cross platform language for games. It has a massive support base with everything you could want already accessible with pygame for 2d, opengl for 3d and pyode for physics, not to mention twisted for networking and Ogre bindings. The other advantage is it is very easy to add C++ optimizations with Boost.Python (of course this means taking on the managing of cross platform once again).

I tried Altitude unfortunately it wouldn't connect for me I was surprised it such a large download 40mb+ until i installed it and realised that it bundled the JRE (Java Runtime Environment), which probably accounts for 50% of that download (on Linux at least). And in the end it used my already installed JRE. That of course is an issue with using any language like this Python included. Though a smart installer could detect what dependencies are missing and download them for you auto magically so you don't need to bundle them.

Hmm thats a whole new problem, cross platform installer . .

However, wouldn't that be a one-time problem? And that after that you would not sink nearly as much time into it? I mean, sure, I've heard tons of good stuff about Visual Studio, etc, but there ARE other IDE's. People shouldn't be as rigid as they are - I am guilty of this myself.

Also, my suggestion wasn't using different compilers in different platforms, that is bound to attract problems. There are compilers that work both on Windows and Linux, like gcc and its cygwin or MingW ports (not totally sure on this, so correct me if I'm wrong).

I personally use Code::Blocks+Mingw in Windows and C::B+gcc in Linux. I'm know little about compilers, only that MingW is pretty GCC compatible. I'm not happy with recent builds since it runs much too slow. And yes, you can have the exact same project files, if you define different target builds for windows and linux (and debug and release, plus whatever you want). Some things can be defined globally and inherited by targets (like the optimization flags), while others can't (linking libraries with different names in both systems).

Or you can go the Makefile way, I suppose. Dunno.

What do you think? Any agreement?

Yeah these issues are over once a dev has got themselves setup and it depends on how they are originally setup as to how much work it would be for them. MingW is very GCC compatible so if you are already using it on Windows switching to Linux would require very few changes in the build scripts Makefiles or otherwise. But if you started using "Industry Standard" VC++ you're going to need to switch compilers and probably rewrite your build scripts.

Anyway my point is it isn't as easy as flicking a switch so being that time is so precious to a small dev team a few day to a week isn't something to be taken lightly.

hey guys, java.

Gah I was waiting for that, every time I'm in a chat about cross platform someone chimes in with Java. It is a lot faster than it use to be so it is an option now. Still I don't like it for reasons which may or may not be relevant to others. The main one is optimization, it isn't easy to add C/C++ or ASM to speed up sections of one's code. But it does work, especially on many of the mobile platforms, though there is no chance of porting to consoles.

I do not have admittedly a lot of experience, but what exactly do you have to learn regarding developing for another platform? For example, Code::Blocks is available for both platforms. It supports compilers that exist for both Windows and Linux. The interface is the same, compile flags are the same, etc. What might change are libraries' file extensions.

Furthermore, aside from using exactly the same tools on both platforms, you can find the same VERSION of those tools and libraries for both platform.

I haven't used Code::Block (I use Eclipse mainly) so I don't know what compiler support it has i.e can i use the same build config for GNU and Microsoft compilers? But that in itself is a good example. I use Eclipse or Visual Studio and most game coders I know just use Visual Studio. So going cross platform might require them switching to a new IDE, which is probably a new build system and a new set of limitations. Then there is getting all the dependencies installed and learning the eccentricities of the platform. Don't get me started on SELinux for example, the number of times that has tripped me up in the past!

It isn't a massive road block but speaking from experience it is the type of thing one can sink days and days into very easily. My point is as an indie dev, especially one without a regular pay packet to rely on, cross platform development is a risk.

[selling]

Jeff's analysis seems pretty spot on to me. If you're a small fish (Indie Developer) the swimming's best where the big fish aren't.

While I am mainly reiterating what others have said:

Developing cross platform itself can be a nightmare especially for an Indie Dev. The problems are twofold, learning to develop for platform takes a lot more time than just learning to use the platform. And secondly, if you are selling a product cross platform it needs to work consistently on all supported platforms. This means doing testing on each platform, a rather time consuming process.

With Linux (I dual boot Windows+Ubuntu i haven't a clue about OSX) the difficulty is there are lots of flavours and api's do change (the cost of the flexibility) which is harder to support. If you are closed source then you have to maintain the build yourself, which isn't hard if you created the build in the first place. The learning curve is still steep even for a coder.

All that said it sounds like the pay off may be far larger than the investment. Linux and Mac users are use to being patient, most games never support these platforms. If there is a delay getting the Mac and Linux builds out no one will complain (loudly). As long as the game was written with going cross platform in mind the task isn't impossible. Also if it is written to be easily ported one could go onto consoles with some ease.