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

Login with username, password and session length

 
Advanced search

1027728 Posts in 41238 Topics- by 32857 Members - Latest Member: ZanN

July 29, 2014, 12:41:27 AM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)Should I restart? (I think the answer is yes)
Pages: 1 2 [3] 4
Print
Author Topic: Should I restart? (I think the answer is yes)  (Read 2036 times)
racter
Level 0
**


Jake Elliott / Cardboard Computer


View Profile WWW Email
« Reply #30 on: October 11, 2012, 04:17:39 PM »

I really like Fred Brooks' idea of the unavoidable "pilot system," which I think is relevant here:

Quote from: Fred Brooks
In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.

The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.

Engineering something new can be a process of discovery and a kind of research. Software engineering is really complicated, and it's often impossible to deeply understand a problem domain before diving in and building a first-draft solution.
Logged

Jake Elliott / Cardboard Computer. Recent games: We Were You | Ruins
Klaim
Level 10
*****



View Profile WWW
« Reply #31 on: October 12, 2012, 12:28:16 AM »

Also, beware of the "second system" problem.

Quote
People who have designed something only once before, try to do all the things they "did not get to do last time," loading the project up with all the things they put off while making version one, even if most of them should be put off in version two as well.


Source: http://en.wikipedia.org/wiki/Second-system_effect
Logged

http://www.klaimsden.net | Game : NetRush | Digital Story-Telling Technologies : Art Of Sequence
Graham-
Level 10
*****


ftw


View Profile
« Reply #32 on: October 12, 2012, 05:16:06 AM »

I don't really throw away large things. I just iterate pieces.

OP, sounds like your issue is solved, but for the theory.... I "deprecate" bad code. Then the second I want functionality that serves me in a better way than the original code, I duplicate it. I duplicate engine code. Then newer code can call the bad code or the rewritten code. Slowly I migrate over to a rewritten system.

A lot more is preserved this way.
Logged
enthrallstudios
Level 0
***


View Profile Email
« Reply #33 on: October 12, 2012, 06:33:54 AM »

Also, beware of the "second system" problem.

Quote
People who have designed something only once before, try to do all the things they "did not get to do last time," loading the project up with all the things they put off while making version one, even if most of them should be put off in version two as well.


Source: http://en.wikipedia.org/wiki/Second-system_effect

What exactly do you mean by something I "did not get to do last time"? Are you talking about a form of feature creep that is present when creating a second iteration? My features are directly related to my design, and to be completely honest, I have less features than I had in mind at first, simply because I would rather have 3 great features/mechanics than have 50 mediocre features/mechanics. That being said, I'll look out for it. The purpose of this re-write is to simplify everything I am doing, not over-complicate it.
Logged
Klaim
Level 10
*****



View Profile WWW
« Reply #34 on: October 12, 2012, 07:03:22 AM »

I can't remember the different books that talk about it but basically the problem is like this:

 1. you do something for the first time: it's very unperfect but it mostly works;
 2. then you start working on a big new version of this thing, from almost from scratch, by relying on the tons of problems your previous version made you discover: you have high chances of "doing too much", by adding too much (whatever you add), and over-think some parts (that's where YAGNI helps a lot).
 3. either the last version was finished or you couldn't finish it because it was too big/over-engineered/hard-to-understand/buggy. Whatever, now you have explored both the simplist and the complicated way of doing it. You have far more chances to get it right, by doing what is necessary, by forgetting what might be useful but isn't proven to be yet, and by making things as simple as possible but not simplist.

Which suggests that all new things you builts are starting to be good only after the 3rd try. Which is one reason to make as much prototypes as you can to check new things. Which is also the reasons why it's important to go in an iterative way, where each iteration refactor/rewrite only one part of the whole. Which suggest that good encapsulation is key. Which also suggest that you'll get back to old code regularly, which imply that you should make the code simple to read, even when what you are doing might be complex on a large scale, it should be simple if you focus on different parts of it.


Feature creep is just one specific kind of stuffs that can happen in the second system (and with others too). The point to get is that the second time you do it, you might over-do it, putting too much effort for something that isnt' worth so much.

That's also why graphic people tends to put too much energy in details when they get to draw better than average people, and why very experienced drawers will draw simple line that are just straight to the point.

That's also why music composition by people not experimented enough will be made of tons of musical sounds not exploiting enough the relationship between sound and silence.


BRAIN ERROR : Pattern Stack Overflow...




When you know about this "problem" (most of the time because it happened to you in different domains where you were new or trying to do something new), then you make everything you can to quickly pass the first times of learning that thing.
Logged

http://www.klaimsden.net | Game : NetRush | Digital Story-Telling Technologies : Art Of Sequence
Graham-
Level 10
*****


ftw


View Profile
« Reply #35 on: October 12, 2012, 07:08:49 AM »

Fail fast and hard, then iterate.
Logged
enthrallstudios
Level 0
***


View Profile Email
« Reply #36 on: October 12, 2012, 07:12:03 AM »

I see what you are saying. Oddly enough, my first try was my over-complicated approach.I would write a small test application for each new feature, and once I had it working, I would add it to my large code-base. So technically, this is my third time re-writing all of this. I just got a point where I realized that 2 goals were conflicting and causing my code to get worse, and me to get stressed. I decided that making my game was more important than worrying about a component-based game engine.
Logged
Graham-
Level 10
*****


ftw


View Profile
« Reply #37 on: October 12, 2012, 07:19:53 AM »

Well it's generally better to build your engine as your game demands it, unless you're building an engine for a feature set you know you will need - you obviously weren't doing that.
Logged
enthrallstudios
Level 0
***


View Profile Email
« Reply #38 on: October 12, 2012, 07:37:03 AM »

@Graham
That's precisely what happened. I was trying to write an engine that could be reused for multiple projects, and I just decided to go all out and do things I have never done before. I can definitely say I learned a ridiculous amount from the project. In the end, I just found the time-sink to be too much, and I just wanted to get my game finished. That is where the project fell short. I don't think I wasted my time simply because of how much I learned, but it definitely wasn't the correct path in regards to finishing a game in a reasonable amount of time.
Logged
Graham-
Level 10
*****


ftw


View Profile
« Reply #39 on: October 12, 2012, 07:41:21 AM »

Yeah these kind of things are learning opportunities. I'm not saying they aren't valuable in that way. (done it many times... too many...)
« Last Edit: October 12, 2012, 02:08:56 PM by Graham. » Logged
Cheezmeister
Level 1
*



View Profile
« Reply #40 on: October 12, 2012, 07:43:45 PM »

I think it works like this:

1. Write game
 a. Finish game <- this is important!
2. Start writing new game
3. Look at previous game
 a. Recognize that 90% of your old code is crap.
 b. Recognize that of the remaining 10%, 9% is not useful or too hard to adapt
 c. Factor out the 1% to use in new game. Feel like badass Cool
4. Goto [1]
5. http://www.xkcd.com/292/

After a dozen or so iterations, voila, you have an engine. At least, that's how Flixel was born.
Logged

Procrastinating on: Nextris, Chromathud, Spheres of Influence | More at http://luchenlabs.com/projects
My heart goes out to you for asking a simple question and getting a million complicated answers; it's sort of how this forum works... -Evan Balster
Salsario
Level 0
***



View Profile
« Reply #41 on: October 14, 2012, 07:54:35 AM »

I like the 3-versions approach.
Make working but ugly prototype, discover things that need to be solved along the way, solve them like a French girl uses a razorblade under her arms. (badddd!)

Version 2, think about a better structure/flow. Make it, throw it away when you have a zillion options but left the main-feature out Tongue

Version 3, make it minimal, but beautiful and working! Concentrate on the real goal you are trying to achieve.
Logged
Klaim
Level 10
*****



View Profile WWW
« Reply #42 on: October 14, 2012, 08:03:42 AM »

Make working but ugly prototype, discover things that need to be solved along the way, solve them like a French girl uses a razorblade under her arms. (badddd!)

This, is offensive.
Logged

http://www.klaimsden.net | Game : NetRush | Digital Story-Telling Technologies : Art Of Sequence
Salsario
Level 0
***



View Profile
« Reply #43 on: October 14, 2012, 08:19:55 AM »

Sorry you took offence, personally I don't find that over the top, so unless someone with moddingrights/admin agrees with you, I'm not going to edit that out. If someone from TIG does think it is over the top, I will remove it. Nonetheless, I'm sorry you find this offensive as it in no way is meant offensive. I like French girls and their beautiful language  Tongue (it's the same when someone says all Dutch are cheap or all Dutch are pot-heads... It's just a little stereotyping, nothing personal and in good spirit.)
Logged
_Tommo_
Level 8
***


frn frn frn


View Profile WWW
« Reply #44 on: October 14, 2012, 08:31:59 AM »

Hey Guys,
So, about a year ago I began working on my current project, which is also my most-complex project in relation to gaming. It started out as a component-based 2D game engine, simply because I wanted to learn about component-based systems worked, and I really wanted to try my hand at it.

Now, I look at my code, and I realize that I have started to add very game-specific code this last month, because I have been developing a game idea in the background for about 2 years and I'm finally ready to focus on that. In all honesty, I see the component-based system as an obstacle because those systems work awesomely with a complex interface, and using said interface to develop a game from the ground up without too much access to the back end. At the same time, I have a test-bed that I have been using to test new things.

In this test bed it took me 24 hours to get a working physics system going, and it took be about 2 weeks to get that same system integrated into my component-based system for multiple reasons.

I am thinking about restarting and focusing on getting a single game done, and not worrying about scaling the engine to larger projects since I want to get the game done in a timely manner. What do you guys think? In all honesty, this past year has taught me a TREMENDOUS amount, but I think I could finish this game much faster with a simpler architecture, and my component-based engine should definitely be re-written at a later date, using what I have learned.

I'd say restart, stop designing the engine and start designing focusing on what the game needs.
When you work on a game the engine comes together by itself by separating real features you really needed; when you try to design an engine ground-up, you end up adding a bunch of features you like that might be useless and for sure aren't tied together well enough to really shorten your development times.
Logged

Pages: 1 2 [3] 4
Print
Jump to:  

Theme orange-lt created by panic