Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

879735 Posts in 33001 Topics- by 24376 Members - Latest Member: xnothegame1

May 24, 2013, 07:26:50 PM
TIGSource ForumsDeveloperBusinessIndie game deadline (Question)
Pages: 1 2 [3] 4
Print
Author Topic: Indie game deadline (Question)  (Read 2282 times)
RudyTheDev
Level 0
***



View Profile WWW
« Reply #30 on: June 28, 2012, 05:39:31 AM »

See http://en.wikipedia.org/wiki/Software_versioning Versioning is a house style issue and everyone will tell you differently. For example, 2.1.3.1406 could be generation 2, major 1, minor 3, build 1406. Suffixes like b1 or rc2 (for beta 1 and release candidate 2) are popular. But, unless you care about revisioning, subversion controls, code sharing, build-specific bug reports, etc., it's just a convention.
Logged

Paul Eres
Level 10
*****


Also known as RinkuHero.

RinkuHero
View Profile WWW Email
« Reply #31 on: June 28, 2012, 09:37:42 AM »

How do you decide what is a milestone or a deadline and when it is? I use todo lists and they work well, but like Rinkuhero said one might suffer from not having deadlines & milestones. I think I have at least partially this problem.

For example right now I have big list of things in my todo, but can't really come up good deadline or milestone from them. In sense I don't know how to group myriad of little tasks, even if they have a same theme (like menus, enemy graphics etc.) and assigning unique deadline for each small task seems a bit overkill to me.

To rehash the question, how do you group tasks into meaningful groups which then can be set a deadline? After all many tasks are interconnected.

this depends on the game, but i generally group tasks into big groups of 20-50 tasks. i don't usually set a group of tasks as a milestone however. instead i set several time-consuming individual tasks as the milestone, and the other tasks can be done whenever.

example, my current milestone for SD is "finish all ~40 dream mode levels". but in order to finish those levels, certain other tasks must also be done, such as converting creatures to dream mode (so that they have specific actions / movement patterns / behaviors in that mode), as well as working on the infrastructure related to those levels (such as a game over message, a high score system) and the visuals/audio related to those levels (sound effects, particle effects)

that's a pretty big milestone though (so far it's been 5 months, i started this one in the beginning of february). i've had smaller milestones that have only taken a month or so, such as "write all the remaining dialogue in the game" (as a first draft, just having everything done but not edited). another one was 'add the options menu and get most of the different game options in that menu working', which also took about a month

during those periods i often work on things not related to the milestone or not necessary for it, just as a break. you don't have to work on everything in a specific order, you can do what's fun sometimes. for instance during my current 5 month milestone i took a break for about 2-3 weeks just to work on some of the music (typing up sheet music into midi notation software, then arranging it and working with others to arrange it better)

so what i'd suggest is to leave most of the tasks in one lump, but for the current milestone, arrange the necessary tasks for that milestone. i also feel milestones should be something big, something *noticeable by players*, not something minor. something that you, as a player of your own game, will be happy with to have finished, such as "being able to play the game to the end, with an ending", or "adding joystick controls", or "add a new playable character", something like that, not something under the hood that only you as a developer care about

here's some more milestones i've had for SD, from memory, in rough order of when i did them

- the basic engine: movement controls / title screen / loading screen / new game / continue / saving / loading / etc.

- coding the game objects and creatures (not all of them, just getting some of each of the major entities in the game working). in other words, adding all the basic 'object types'

- adding the player's abilities (the actions the player can do, abilities the player can collect/equip and use)

- adding the level editor and map system, and a test level, and an area transition effect

- adding sound effects, music, and particle effects into the game, as well as other special visual effects like reflections and whatnot (what one indie game video called "juice")

- making more areas of the game, more creatures, more interactive map objects (this took most of the time, probably like two full years, within which i had smaller milestones like the ones below)

- adding an intro, and endings, and "bosses"

- adding various "systems" into the game (memory cell system, terraforming system, teleport tree system, godstatue system, function upgrading system, camp mode system, weather system, soundscape system,  an "ability stealing" system (where the player acquires abilities from the creatures), etc. -- each of these was a small milestone which added a lot to the game)
Logged

James Coote
Level 1
*


Spoon Thumb


View Profile WWW
« Reply #32 on: June 29, 2012, 08:12:17 AM »

This is a really noobie question, but how often do you commit and push changes (assuming you're using github or something similar). Every time you tick off one of those features or items on your list or every day at the end of the day?
Logged

Crystalline Green - Android Games Developers
Paul Eres
Level 10
*****


Also known as RinkuHero.

RinkuHero
View Profile WWW Email
« Reply #33 on: June 29, 2012, 08:27:39 AM »

i never heard of githup; i just use paper and pencil to keep track of the tasks. and i record competed tasks at the end of the day in livejournal:

http://rinku.livejournal.com

i'm not sure this matters though. whatever you use and however often you want to check tasks off depends on an individual's style. i prefer oldschool / low-tech stuff, others might want to record their tasks on their nearby ipad
Logged

Christian Knudsen
Level 10
*****



View Profile WWW Email
« Reply #34 on: June 29, 2012, 09:20:01 AM »

Github is for version control, Paul. I think most people commit after they've completed a specific task or at the end of the day. I personally just use Dropbox, though, so I guess I commit all the time. Smiley
Logged

Laserbrain Studios
Currently working on Hostile Takeover (TIGSource DevLog)
Paul Eres
Level 10
*****


Also known as RinkuHero.

RinkuHero
View Profile WWW Email
« Reply #35 on: June 29, 2012, 09:23:31 AM »

yeah i imagined it was some version control thing; i don't know if that is necessary unless you have multiple programmers. if you have just one individual programmer, is there any advantage of using version control over just regular backups using stuff like dropbox / mozy / google drive?
Logged

Christian Knudsen
Level 10
*****



View Profile WWW Email
« Reply #36 on: June 29, 2012, 09:26:53 AM »

I've been wondering about that as well. To me, Dropbox seems perfectly fine if you're just one programmer.
Logged

Laserbrain Studios
Currently working on Hostile Takeover (TIGSource DevLog)
TeeGee
Level 10
*****


Huh?

tomek_grochowiak@op.pl
View Profile WWW Email
« Reply #37 on: June 29, 2012, 09:29:32 AM »

I think version control is more convenient than just dropbox, especially if you have several working computer and/or team members. I use SVN, and I just commit at the end of each day of work.
Logged

Tom Grochowiak
MoaCubeBlog | Twitter | Facebook
Christian Knudsen
Level 10
*****



View Profile WWW Email
« Reply #38 on: June 29, 2012, 09:34:11 AM »

I originally installed Dropbox precisely because I have several computers I work on and wanted automatic syncing. But maybe you mean several computers working at the same time on the code?
Logged

Laserbrain Studios
Currently working on Hostile Takeover (TIGSource DevLog)
Moczan
Level 5
*****



View Profile
« Reply #39 on: June 29, 2012, 09:55:17 AM »

Source control is better than Dropbox (or more precisely, it adds to Dropbox, cause you can use both at the same time) in that you can easily see the changes you have made sorted in logical commits with comments and diffs. Rolling back with Dropbox is pain in ass, rolling back with version control is easy and fast. Seriously, every programmer, even working alone, should use one.
Logged
Christian Knudsen
Level 10
*****



View Profile WWW Email
« Reply #40 on: June 29, 2012, 10:00:55 AM »

Hmmm, I've never had much trouble rolling back to an earlier version with Dropbox. Being able to add comments and see differences definitely sounds nice, though.
Logged

Laserbrain Studios
Currently working on Hostile Takeover (TIGSource DevLog)
Moczan
Level 5
*****



View Profile
« Reply #41 on: June 29, 2012, 11:04:05 AM »

Hmmm, I've never had much trouble rolling back to an earlier version with Dropbox. Being able to add comments and see differences definitely sounds nice, though.

My main problem with it is actually finding the right version to roll back. It's easy when you want to roll back to version of one file from 5 minutes, but if you ctrl+s all the time like me, getting few files to version from few days will be pain in ass, cause (unless it was changed) Dropbox lacks a good interface for checking out versions.
Also with DVCS you can easily clone, merge and branch your code, which is not something you do often as a solo developer, but if the time comes, it makes everything easy. AND it let's you integrate with bug tracker/to-do lists and all that stuff, which was the main feature discussed here.
Logged
RudyTheDev
Level 0
***



View Profile WWW
« Reply #42 on: June 29, 2012, 11:39:43 PM »

... how often do you commit and push changes ...

Every day (that changed anything) with a brief summary of what was done. The repository itself is also in the Dropbox folder.
Logged

nikwing
Level 0
**


View Profile
« Reply #43 on: July 09, 2012, 05:47:22 PM »

I don't know if this question is OOT but i forgot to add in in the original post.

How you guys decide when to ship the game? and avoiding feature creep?

thank you
Logged
VDZ
Level 3
***


My post is there read that instead ->

supervdz@dolfijn.nl
View Profile WWW
« Reply #44 on: July 09, 2012, 06:53:34 PM »

As for versioning, I just number the builds released to anybody not directly involved in creating the code sequentially - version 1, version 2, version 3, etc. At least that way the order of releases is perfectly clear.

Version control: I commit whenever I make a major change and everything works again (code compiles, feature that was just added works properly), and at the end of the day if I have any uncommitted changes.

I like to use version control (SVN is my version control system of choice) even when working solo because it allows me to charge right ahead and implement something hard to undo that might mess up the entire thing, because I can just right-click and select 'revert' if it ends up not working. It also allows me to read deleted and replaced code, which can be useful for finding bugs (bug X appears after you changed Y, what was it like before?) among other things.
Logged
Pages: 1 2 [3] 4
Print
Jump to:  

Theme orange-lt created by panic