what is the different between prototype and actual implementation in game development?
If i prototype a game,isn't it the same same as implementing a game?
Both actually means creating to me.
wiki defines a prototype as an early sample built to test the concept.
Full implementation might be as you are coding you are taking in consideration of things like screen size, if the user wants full screen, this resolution;that resolution, will it work on this monitor size correctly, etc. Can the user resize manually? Is it keeping aspect ratio during this process? You might decide you want to buy artwork that is professionally done, while you are the programmer to put it all together.
Where a prototype might just have it hardcoded as (800,600) with no full screen, no screen size changes. Because all you want to do is just get to the game/concept. Maybe you are not sure if you want to make this game type or not? There is no point in wasting time on boilerplate code such as screen changes, and screen sizes, if there is a chance you might not make that game in the first place. If you have a history of games and a fan base, maybe you want to check with them to get their feedback before you invest fully into it. Maybe you plan on buying artwork, and the prototype has home-made artwork. There is no point in buying the artwork if you are not making the game. A lot of times you can just use plain old rectangles to replace your artwork to just test concepts. An example would be
here
And yes most likely you would just change the prototype to implement the screen aspects, so when you are creating a prototype its not like its being thrown away when you decided to invest fully into it.
A prototype is just something you do very quickly to test an idea out. So the graphics, at the very least, are nowhere near what you'd want other people to see (like a person is actually just a block, or a stick figure).
They are very useful. If you spend a lot of time building out a game (with menus, saving/loading, multiplayer support), and THEN work on the actual gameplay idea, you might find it isn't fun at all, and that you just wasted months of work.
Prototypes are often crap-code. Implementation need to be built to last. To be extended, improved, and bug-free. Prototypes are often built, not with robustness in mind, but getting something minimally working quickly. They're often designed poorly (if designed at all), bugs are ok and often not tracked.
Sometimes, a prototype is just an early revision. It might be designed well, any bugs are tracked, but it lacks features and may have bugs, but could be shown in a demo. This second kind is less common. For the first kind, the code should probably be wiped and programming start fresh.
(Feb-07-2017, 10:47 PM)micseydel Wrote: [ -> ]Sometimes, a prototype is just an early revision. It might be designed well, any bugs are tracked, but it lacks features and may have bugs, but could be shown in a demo. This second kind is less common. For the first kind, the code should probably be wiped and programming start fresh.
In order to try to force that at work, I've heard of people using odd languages that don't fit in with anything else. So when The Boss asks to see a mockup of something, and then after seeing it says "well, that's good enough, just push it to production and work on something else", they can say "I can't. Even if I wanted to, our tools don't support that language." That way, once it's the way people like, you HAVE to rewrite it.
Or, what I do with sql queries, is I just don't ever save them. I'll run it, pass the data over in an excel file, and delete all trace of the query ever existing.
thanks everyone for your replies.