Elysian Shadows

Well, I want to know how are your aproaches on how to deal with organic growth of software, I mean, how to avoid that your code becomes written on the fly and not thought very well (which happens when you are on a project and running out of time), because this leads to code entanglement...

When I was working one of my previous jobs, I had a project we jokingly called "The project that would not end." It had all kinds of feature creep. We forced the users to sign off on requirements and stuck to that list of requirements. Any additional requests were pushed to Version 2.

Depending upon what languages and paradigms you're adhering to:
Typically, I found the best way to squeeze things out quick for school projects or in a production environment while retaining reasonable maintainability for later was to use lots of comments while trying hard to break code into logical chunks (even if it's only separated by whitespace and comments all in the same file). I'd end up with big sections of code that were easy to cut+paste out and place in a new class or function as a result.

Also, as you recognize common functionality among objects you can: 1) start sticking common blocks of code into functions, 2) use polymorphism, or 3) build lists of common components/pieces you're using and building your objects out of those. Which approach you take really depends upon the needs of your project. In my experience, the bigger your project gets the closer to the right of side of that list you want to be since it scales better - but don't over-engineer it if you don't need (or want) to.

Working in a language with more minimal OOP features (like PHP), I found it to be useful to build little function libraries for a particular set of tasks. An example of a library I built was for importing data to a mysql database from .csv files. There were then a bunch of different scripts for importing different types of data. Each would perform a whole bunch of validation to make sure the data was good and wasn't duplicated in our database - then it would decide what to do with it based upon what it found (eg. we would usually reject a sheet if more than 10% of the data sucked because it saved us time maintaining the database in the long run). There was a lot of common functionality used though, and as I found this I would isolate those functions/chunks of code and stick them in this common file for that subsystem.

For me it depends on what the software is, and what language I'm writing it in, and also how much experience I have in that language.

If it's a windows application, I would probably use PureBasic, as I really like that language, but also even though it's Basic, it's more like a cross between basic and pascal. That language has to use some level of organisation, otherwise it just falls over, but it's productive that way, and it's quick to get results with and also maintain organisation. I can see how people using 'visual' languages like VB or VC++ might just forgoe organisation in favor of development speed though.

If it's a game, on the PC I would tend to work very organically, but that's something experience affords me. If I'm adding a particle system for example, then I just bash it out without too much thought, because I've written a dozen in the past, I can literally write the whole particle system without a single test compile. If I am writing an iOS game, then I would spend a lot of time on organising it, splitting it up into libraries, and trying to maintain that control throughout development.

I'd say that you can skimp on organisation, but you have to put in the work to be confident at doing that, otherwise your just asking for trouble.

I'd ask then, what strategy would you also recommend for writing games also within a team. Should we in first instance get togheter and define all classes and then implement them? Though I have written some simple games in the past I'm looking forward my next game, which being more complex, needs more thought. I love how in Adventures in GD they seem to be a very tight team even working at their spare time, as nothing can be more frustrating that not getting with your team... Is there some recipe or gold nugget for designing the software based on your game design? And in how to divide the work throughout your team?(Mainly in C++)

Lisergishnu wrote:I'd ask then, what strategy would you also recommend for writing games also within a team. Should we in first instance get togheter and define all classes and then implement them?

I think that approach is called the waterfall model, and is generally not considered a good approach. Agile development seem to be modern at the moment: http://en.wikipedia.org/wiki/Agile_software_development. The basic is to have a more iterative process than the waterfall model.

But remember to actually do some programming, motherfucker. http://programming-motherfucker.com/

Agile software development does seem to be better for small teams, especially if they are still learning for the most part. I see it kinda as if your game idea is a cookie - you can eat the whole thing yourself but it might take a while, or you can break it into pieces and share it, or you can pass it around your team, taking nibbles around the edges until it's all gone. Agile is a bit like nibbling so far as I can tell. For instance, some people on your team might not have a lot of experience, so small goals that can be completed relatively quickly make sense. For one thing, it makes it easier to learn from examples and small scale experiments. The project has to feed the teams hunger for results while avoiding pitfalls like procrastination. If goals are too big, procrastination sets in, and it might just take 1 member of your team to cast doubt, then it's game over.

I know your teams query wasn't directed at me, but I'm gonna expunge my thoughts anyway...

Game design:
When your working in a team, constantly remind yourself of the reality that your facing - the project is not yours any more. If you spent all summer meticulously writing a game design document, then put that to the side and save it for a solo project. People join game dev teams to develop a game, not work for no pay on someone elses ideal. Have a strong idea for your project, but be prepared to change it, and most importantly accept and consider ideas from everyone in your team. Everyone needs to feel some ownership of the project, share it, and don't dismiss any ideas that you initially think are dumb... even something minor, like say a particle effect that someone thinks would be cool - imagine what that means to that person, and the affect that will have on that persons morale. As well as listening to everyones ideas, ensure that people can afford the ideas they are having - if someone suggests an outlandish idea that might be out of your league, take too long, or detract from the game, then make sure that person is in touch with the capabilities of the team and project. Daft ideas tend to stem from a poor grasp of the teams capabilities, but you never know how far someones skills will stretch. Be tactful, and highlight the current goals, and there's no harm in having lofty ideas and discussing them, then get back to reality and review the current goals. I think that with a small team, you should define realistic goals each week for everyone, then review that before defining new goals - that encourages members to do their work, rather than looking bad in front of the team... sometimes peer pressure is the best incentive with this stuff, I've gotten a lot done just by not wanting to let anyone down, or waste anyones time.

Splitting work:
C++ is a language that can lend itself to effective workload management. Things like graphics, logic, and sound are seperate entities. I would say that if you have 2 programmers, then split the work into game logic, and the graphics engine first. With small goals, you might want quite humble results, like positioning a sprite on the screen. Ideally, whoever is looking after game logic will have a straightforward function call to render a sprite, and whoever is looking after the graphics engine is tasked with providing that function. Then as the game code evolves and demands more functionality, like alpha fading, colouring, etc, the graphics coder can expand on what they have, and learn a great deal in quite a short amount of time. I think it helps if the graphics coder can draw to a basic degree as well, because artists really like to work from templates and guidelines - it makes for a good workflow, because the coder can get to work right away, and the artist can see the results right away, everyone is happy. A project can suffer when there's only 1 coder, because there is so much to deal with, it can be bloody miserable for them. If there is only 1 coder, then there has to be good QA communication - the whole team have to be testing and providing concise bug reports, otherwise said coder would be better off just using freelance people for media. Ideally, I'd say a small team should consist of a sound guy, an artist, a game coder, and an engine coder - at the very least. Additional resources can be used to provide well written tools, level editors with undo functions for example, stuff that makes game development more manageable. If you have more than one artist, or more than one anything really - someone still has to be in charge of that, otherwise consistancy goes out the window. This might be most noticable with art, artists should decide on a visual style, and split the work into defined areas. You wouldn't want 2 artists making sprites for instance, better to have 1 artist do sprites, and 1 artist do backdrops and map tile sets. Continuity is important, and it can make all the difference in the games final look and quality.

Finally, I'd say that you should never pay 1 team member - if nobody is being paid, then nobody should be paid!. Don't get into debt funding a game that might well loose money in the long run. If you really need someone to do work, and they wont work as a team on the same team terms, then replace them. Everyone on your team should have an investment in the project - they pay into that investment with time, and hope to cash out some day - that has to be unilateral. Development will probably take longer than you imagined, your team will all have to wait longer for payday, if you already paid someone, then that breeds discontent - the equivalent of dragging your project through a minefield for the sake of standing up to some impatient pixel-pusher :D. You don't want people on your team who are only interested in making money, making a kick-ass game should be the core reason for working together.

Hey Van-B, thanks for the feedback . Thankfully I haven't paid anyone for coding since the last project I was involved was a college contest, still we've got some work dynamics problems along the way. We have this group of people who are passionate about making games, but I see that the deal is that everybody has great ideas, yet a few make them real. I will consider your thoughts next time we embark on a game
Also, I LOL'ed at programming, motherfucker