agile programing, games

[Blake Sarno]

I love games specially which make in agile programing. Did you know any site of agile games or any single game ? Share here

[Domochevsky]

...made in what? :smallconfused:

(*sees sig* Are you trying to sneak in a bit of advertising here, bro? :smallwink: )

[Eloel]

Agile programming is a programming technique, with very quick development cycles.
My guess on how that'd be applied to games is, very frequent updates, with new content coming in often, but usually in small batches.

Don't Starve (as far as I'm aware) uses such a technique, with many many updates, quite often.

[CarpeGuitarrem]

More technically speaking, I believe that Agile is a software development method. It's not a programming language or style of coding, but a way to organize a project. (As I recall, it's almost diametrically opposed to waterfall development.)

[Cogwheel]

More technically speaking, I believe that Agile is a software development method. It's not a programming language or style of coding, but a way to organize a project. (As I recall, it's almost diametrically opposed to waterfall development.)

So you're saying there are games that use anti-gravity water, then. Duly noted.

[GungHo]

More technically speaking, I believe that Agile is a software development method. It's not a programming language or style of coding, but a way to organize a project. (As I recall, it's almost diametrically opposed to waterfall development.)

Yeah, this is one of those things where I know too much about something to understand the curiosity around it. Whether they use Agile, Spiral, Waterfall, or whatever else... why would you care unless you're actually doing the development? Hell, even if every single component is the result of sprinting, that doesn't mean that you're going to ever know that if the publisher is still compiling into discrete releases.

[CarpeGuitarrem]

So you're saying there are games that use anti-gravity water, then. Duly noted.
Yesssssssssssss.

GungHo: Right-o. It's akin to talking about books as written using Microsoft Word or Scrivener or a notebook--those are all methods of organizing the information and putting it together, but they have no bearing on the style of the novel, or its influences, or genre, or any similar feature.

[Jimorian]

Yesssssssssssss.

GungHo: Right-o. It's akin to talking about books as written using Microsoft Word or Scrivener or a notebook--those are all methods of organizing the information and putting it together, but they have no bearing on the style of the novel, or its influences, or genre, or any similar feature.

Or whether it's any good or not. :smalltongue:

[Reinboom]

For the most part, we use have an agile development cycle on League of Legends.
Parts of the content pipeline are waterfall though, and some of the service-like engineering teams use their own adaptations of kanban that developed in to being highly responsive.

[Bucky]

Context: Kanban is a program that agile teams use to organize themselves.

[The_Jackal]

In my experience, Agile is merely a method for changing bugs in your code base more quickly. It shouldn't have any bearing on a developer's public release schedule. If you're posting patches to your game every time a developer checks in code into TRUNK, you're going to have a lot of problems.

[Grinner]

I believe Dwarf Fortress fits the bill.

[Lighturtle]

Whether they use Agile, Spiral, Waterfall, or whatever else... why would you care unless you're actually doing the development?

The client likes to see where his money is going and to be able to give feedback very fast.

[Mattarias, King.]

I like this thread, I'm learning things! Thank you everyone. :smallsmile:



Yeah, this is one of those things where I know too much about something to understand the curiosity around it. Whether they use Agile, Spiral, Waterfall, or whatever else... why would you care unless you're actually doing the development? Hell, even if every single component is the result of sprinting, that doesn't mean that you're going to ever know that if the publisher is still compiling into discrete releases.

As both someone very curious/interested about these things, as well as a fan of a certain anime, what's Spiral programming, them?

Also "sprinting"?

(Disclaimer: Yes, I know I can google this, but discussion is so much better. Like talking to a teacher instead of reading a textbook.)

[Lighturtle]

Also "sprinting"?

A sprint is more or less "okay, we have 3 weeks, we do this and this and that and we show that thing as a result!".

Often "and this and that" are moved to the next sprint though :smallwink:.

The intent is to have chunks of measurable progress. Agile software gives you pretty charts and ****.

Personally, I think it is pretty bollocks unless you are in larger groups or interact with the client a lot (then it's a good tracking tool). It is also very reliant on estimating correctly.

[GungHo]

As both someone very curious/interested about these things, as well as a fan of a certain anime, what's Spiral programming, them?
The Sprial Model (http://en.wikipedia.org/wiki/Spiral_model) is built around risk patterns and basically means you're going to run the gamut of waterfalling, rapid prototyping, incrementalising, or other methodologies in combination based on the needs each individual product and the customer.

Posting picture from Wikipedia, but, understand that this diagram has confused people for almost 30 years. It's also big, but anything smaller and you can't really read the text, so wrapping it in a spoiler.

http://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Spiral_model_%28Boehm%2C_1988%29.svg/1000px-Spiral_model_%28Boehm%2C_1988%29.svg.png

It is an iterative model, but it's not linear, so "jumping arms" in the spiral is quite valid, as long as it's appropriate with what you're doing. You do not have to pass through all phases listed. You do not have to do three prototypes, etc. A lot of computer scientists/engineers are very literal people, and a diagram is often interpreted as a prescription... that's why I'm probably overly-belaboring this.

The biggest issues with the model is that it assumes that the software developers are able to understand the need they're serving, as they need to know when it's time to progress... there is no time-table assumed; and the customer needs to trust the developer with some degree of independence when they "ask for a rock" and the developer goes to "find the rock" and trust that everyone's definition of "a rock" is going to be aligned. Because this never happens the first time out of the gate short of a miracle, the customer needs to expect that they're going to need to spend for re-alignment. The operational prototyping and integration testing isn't until the tail end of the spiral, so the customer often isn't really going to see anything beyond mockups until it's all done except for beautification. As long as the customer understands this, things are usually good. But, when people's expectations are misaligned, this can really piss people off because the conversation will be "what the hell have you been spending my money on?"

[Seerow]

Just wanted to mention I'm in a class right now about Management of IT projects, covering all of the same things being discussed here... yet I feel like I've learned more from reading this thread than from sitting through a month of lectures on the same topic.


tl;dr: College is overrated. Lurk on message boards until a thread comes up to teach you what you want to know.

[tensai_oni]

I believe Dwarf Fortress fits the bill.

It's made by one person. That makes it agile by default!

[Mobius Twist]

A sprint is more or less "okay, we have 3 weeks, we do this and this and that and we show that thing as a result!".

Often "and this and that" are moved to the next sprint though :smallwink:.

The intent is to have chunks of measurable progress. Agile software gives you pretty charts and ****.

Personally, I think it is pretty bollocks unless you are in larger groups or interact with the client a lot (then it's a good tracking tool). It is also very reliant on estimating correctly.

Well, the goal in a sprint is to go from planning, to implementation, to a working product (often very tiny in scope, but functional) within a single sprint. All the teams I've been involved in have had to make a presentation of their working pieces without any hacks in place at the end of each sprint.

In a game design this could translate to getting a character's motion, art assets, and physical world behavior to sync correctly at the end of a sprint, then demoing said character's interactions through a bare-bones mockup of a world.

And yes, initial estimates are frequently off, but the sprint/scrum master is responsible for pushing everyone else to adjust estimates closer to reality based on earlier performance.

[Reinboom]

Most teams here operate on two week sprints.
You also don't necessarily need all the artifacts of the process. (Burn down graphs and the sort)

The basic idea is that at the end of the time you have something workable. Even if that something isn't "shippable" so to say, there is valid functionality there that can be responded to and the rest of the project adjusted for.

The intent is that software development can be a discovery process and that failure to handle a problem should be handled quickly after discovering its difficulty.

[Mobius Twist]

Addendum: I just spoke to a fellow developer and confirmed that stress levels and feeling of pressure are higher in an agile development environment compared to a waterfall one, even if the workload is comparable.

Management loves being able to show tangible process to clients week-after-week, though, even if the clients are entirely internal and put no pressure whatsoever on the team.

[Poison_Fish]

My work (An art studio that does much art design for video games along with our own game development, mostly mobile) uses aspects of agile. Iterative and evolving character art/animation also allows for decent exploration with rapid responses. It's not quite the same due to mostly being art here, but the principles work well enough.

[Telok]

So 'sprinting' is the 7 day rogue-like challenge. Simple enough but I'd hate to do it every week as my job except for little, single action, applications or objects.

And I don't know what sort of buzzword jingo logic-twist you have to go through to call what Toady is doing 'agile.' I've been with DF since 2D (I can recall when Boatmurdered happened) and the only thing I can recall Toady being agile about is the mermaid farming issue. Seriously, it's been something like two years since the last update and we're still sending him money. I don't send bucks for 'agile' I send for quality.

[Poison_Fish]

So 'sprinting' is the 7 day rogue-like challenge. Simple enough but I'd hate to do it every week as my job except for little, single action, applications or objects.

And I don't know what sort of buzzword jingo logic-twist you have to go through to call what Toady is doing 'agile.' I've been with DF since 2D (I can recall when Boatmurdered happened) and the only thing I can recall Toady being agile about is the mermaid farming issue. Seriously, it's been something like two years since the last update and we're still sending him money. I don't send bucks for 'agile' I send for quality.

But don't you know? The latest sprint is for 4 years. All this billing is for phase 24000, which comes.. uh.. somewhere in the project phases.

Seriously, I love DF.

[Grinner]

And I don't know what sort of buzzword jingo logic-twist you have to go through to call what Toady is doing 'agile.' I've been with DF since 2D (I can recall when Boatmurdered happened) and the only thing I can recall Toady being agile about is the mermaid farming issue. Seriously, it's been something like two years since the last update and we're still sending him money. I don't send bucks for 'agile' I send for quality.

Errr...? I simply meant that he plans, writes, and releases in small increments.

Truly, I'm unfamiliar with the management jargon associated with software development. It just seems logical to me.

[spectralphoenix]

Steam Early Access games use at least some of the principles of agile development - they release a prototype to the customers, get feedback, and create the next phase of the project.

That said, "agile" is one of those words that means just about whatever the speaker wants it to mean. Lots of developers talk about being agile without actually implementing an agile paradigm. And honestly, it's not like there would be any way to tell if the developer had used XP or Scrum or what not when you receive the end product anyway.

[SiuiS]

Blake Sarno, you are a spambot! I trusted you! :smalleek:

[Eloel]

Does this go into history as the first informative thread that spawned from a spambot?

[Rosstin]

Weird spambot.

Agile programming is almost always a good idea. Sometimes you can't be 100% agile if your game has a lot of linear progression to it... Queen At Arms (and visual novels in general) are hard to make in an "agile" way, for example, because they are more like writing a book. It takes a long time to get the end so you can loop.

Action games or arcade style games are best for Agile development: roguelikes and games without a huge long linear progression. Making a game like that means you can objectively judge how successful your design is early in the process.

[Grinner]

Does this go into history as the first informative thread that spawned from a spambot?

No.

The first I remember was in the Roleplaying subforum, and there have probably been others.

Edit: Also, I should point out that there's no concrete reason to assume he's a spambot.

[endoperez]

So 'sprinting' is the 7 day rogue-like challenge. Simple enough but I'd hate to do it every week as my job except for little, single action, applications or objects.

No, sprinting is about doing big things part by part, and checking progress every X weeks.

7DRL (i.e. "making a prototype") would be the first sprint of 1-2 weeks, followed by another for making custom tiles, then something else for the next sprint.

[Kerrin]

Addendum: I just spoke to a fellow developer and confirmed that stress levels and feeling of pressure are higher in an agile development environment compared to a waterfall one, even if the workload is comparable.

Management loves being able to show tangible process to clients week-after-week, though, even if the clients are entirely internal and put no pressure whatsoever on the team.


So 'sprinting' is the 7 day rogue-like challenge. Simple enough but I'd hate to do it every week as my job except for little, single action, applications or objects.
Management shouldn't be using the Agile software development lifecycle process as a way to crank up the pressure.

Personally I dislike a lot of the terminology in Agile, but to note, a "sprint" or iteration doesn't mean everyone is working overtime every week. In fact, organizations who do Agile (or any other SDLC) really well don't need to work overtime.

Also, Agile isn't just for software developers. The entire organization and the customer needs to operate using the same model ... An Agile team should include everyone working on the project, including the Product Owner and Scrum Master. There's no reason a manager can't have a prioritized release backlog of their own work and parse it out into two week iterations. Any organization that can't plan at least two weeks ahead is in serious trouble.

Our organization uses an Agile process and I struggle all the time to educate people in our company as to what that means. Too many think "it's something the engineers do" or that they can ask for whatever they want whenever they want. Agile is a lot about planning, locking things into short term committed iterations, and frequently evaluating the prioritized release plan and making adjustments for upcoming iterations. Our Product Owners spend a great deal of time managing our business folks' expectations.

The proper response to someone asking to have something done is to say, "We'll be glad to do that. Let's look at the release plan and prioritize it against what's already there." It's amazing how difficult it can be to get folks to prioritize their asks!

[SiuiS]

No.

The first I remember was in the Roleplaying subforum, and there have probably been others.

Yeah. Heh.


Edit: Also, I should point out that there's no concrete reason to assume he's a spambot.

Said poster has three posts, all made on the same day as the account, and two of them are generic thread starts. One is the hello thread in friendly banter, one is this one, and I haven't found the third post yet.

Blake sarno might not be a spambot, but if so I would have expected a response to "Hi! Are you a spambot?" by now. :smalltongue:

[Jimorian]

Said poster has three posts, all made on the same day as the account, and two of them are generic thread starts. One is the hello thread in friendly banter, one is this one, and I haven't found the third post yet.

Blake sarno might not be a spambot, but if so I would have expected a response to "Hi! Are you a spambot?" by now. :smalltongue:

Third is in the actual introduction thread of Friendly Banter. If this is a spambot, the next step would be to edit in links at a later date, either directly in the posts, or in the sig. The slightly off English of the first posts is also a spambot marker (but not definitive as we definitely have a lot of non-native English users in the forum).

It is an interesting thread, though, and I'm learning a lot, even if my field isn't programming or even project management in general.

My only contribution is that in my experience, there are 2 kinds of managers: those who understand that something like Agile Development is a tool they can use to accomplish the task at hand, and those who start believing that the tool IS the task and try to warp everything and everybody in the office into it.

I was around during the last days of Borders Books, and one of the things they had implemented was a customer service survey via an 800 number on the receipts. Instead of looking at the raw data and trying to figure out actual ways we could improve the customer's experience, the goal became strictly about the score.

We were told to literally manipulate it by outright suggesting customers give us a 5/5 rating, because they only thing that mattered was for each store to beat the company average. We'd get calls from the district manager furious that we'd scored a 4/5 on the question about restroom cleanliness, resulting in a panicked scrubdown of the bathroom that day even if it disrupted the flow of the rest of the business.

That's the kind of micromanaged B.S. that any business theory can devolve to without somebody constantly making that saving throw for common sense implementation.

I bet if you asked programmers about Agile Dev, and then divided them between those who hated it and those who loved it, you'd find how they feel is directly correlated with their experience of the manager behind it.

[GungHo]

Management shouldn't be using the Agile software development lifecycle process as a way to crank up the pressure.

Personally I dislike a lot of the terminology in Agile, but to note, a "sprint" or iteration doesn't mean everyone is working overtime every week. In fact, organizations who do Agile (or any other SDLC) really well don't need to work overtime.
Agreed. Agile isn't code for "ye shall be working overtime". The term "sprint" is simply a marketing differentiation. It doesn't mean you'll be running around all the time, even if it feels that way in the moment. There are managers who abuse the concept, but they'd have been abusing something else anyway. The methodology is neither the cause of nor the salvation of poor supervisors, and if anything, it exposes them really quickly as their people will riot within a month.


Also, Agile isn't just for software developers. The entire organization and the customer needs to operate using the same model ... An Agile team should include everyone working on the project, including the Product Owner and Scrum Master. There's no reason a manager can't have a prioritized release backlog of their own work and parse it out into two week iterations. Any organization that can't plan at least two weeks ahead is in serious trouble.
Not at all. I could easily see it being applied to many sorts of content creation... from writing an RPG to manufacturing and construction. If it can be broken into discrete blocks and worked in those blocks somewhat independently within a set timeframe, then you can apply the concepts. (They likely already exist under different names.)