Can you make a big game by starting small?
Members - Reputation: 117
Posted 13 July 2012 - 01:08 PM
Crossbones+ - Reputation: 4696
Posted 13 July 2012 - 01:11 PM
Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts
Members - Reputation: 117
Posted 13 July 2012 - 01:19 PM
Crossbones+ - Reputation: 11162
Posted 13 July 2012 - 02:11 PM
Well, as I said, I wouldn't be releasing it right after the core game is done, just making sure it can work as a game, before going on to a next step.
I'd say that would be describing a vertical slice, which is an inherent part of several game development psychologies...
-=- Full "Retro Mortis" Series Article Index -=-
Retro Mortis - RTS (Part 1) - It was found in a Desert...
Retro Mortis - RTS (Part 2) - Then a Blizzard came...
Members - Reputation: 98
Posted 13 July 2012 - 02:18 PM
Not a programmer myself but it would be pretty difficult to upgrade the engine with DLCs.
You can release it in development stages, where the players would need to redownload the game at certain points as some features cannot be just patched in.
But yeah it would be possible but you need someone who always has the grand scope of the game in mind so none of your DLCs make old content obsolete.
Members - Reputation: 117
Posted 13 July 2012 - 02:47 PM
Moderators - Reputation: 5217
Posted 13 July 2012 - 04:25 PM
Phone game idea available free to someone who will develop it (Alphadoku game - the only existing phone game of this type is both for windows phone only and awful. PM for details.)
I want to help design a "sandpark" MMO. Optional interactive story with quests and deeply characterized NPCs, plus sandbox elements like player-craftable housing and lots of other crafting. If you are starting a design of this type, please PM me. I also love pet-breeding games.
Members - Reputation: 461
Posted 13 July 2012 - 09:30 PM
As a counterpoint though, you could just as easily pick out, say one or two core features, build up a prototype with those features, and then slowly add content that way. So, you don't have to chunk development spatially (in terms of levels), you can break it down in whatever way will be most convenient given your development plan (e.g. if you expect it to take only a few weeks to build the game world, but many months to build the graphics engine, then you might split up rendering components instead).
Members - Reputation: 370
Posted 14 July 2012 - 03:13 PM
If I develop an engine and say the first version will be like the CryEngine but better. In the next 2 years I will not have some feedback and my motivation will sink and the result is the project will fail...
When I develop a game or an engine and release much more versions I can react on feedback and will have more motivation and when they like my game, they will stay longer, because it is unfinished, so the full version would be "better" than the current alpha or beta version. Minecraft is a good example for this...
Some years ago it was a very good way to adverse when you set a website into the beta state, because an unfinished version who is good, is in the full version much better ;)
Edited by omercan, 15 July 2012 - 03:07 AM.
I have a blog: omercan1993.wordpress.com look there for more content
And I also do some art: omercan1993.deviantart.com
And whats about the Pear3DEngine? Never heard of it? Go and look!
Yeah, and currently I do this: SimuWorld
PS: Please look at this poll on my blog about scripting languages: A opinion poll about scripting language
Members - Reputation: 169
Posted 16 July 2012 - 05:56 AM
You start simple, "Hello World", game loop, getting a map on screen, handling inputs etc etc.
Constantly testing, and when satisfied, moving on to the next milestone adding features as you move towards the end goal.
Members - Reputation: 294
Posted 16 July 2012 - 11:45 AM
As for the method for doing it depends on the size of your team (1 person? 5? 10?), the experience of your team (Beginners? Programmers out in the working world?), the commitment of the team (full time? hobbyist?) and where are the team members located (everyone is located at the same place?).
If you have a small team, say 1-5 members with little to no experience doing this as a hobby. I will recommend the traditional waterfall method. It is simple and straight forward when compared to agile development.
Don't get me wrong I like the idea of agile development and have personally been involved with quite a number of them, but agile development does requires the team to be highly disciplined (simple things like regular sprint meetings may not be possible if everyone is doing this as a hobby), and led by people who have experience in it (e.g. a good scrum master and product owner to write the stories).
At the end of the day, no matter what method you chose, spend time to properly plan this out. For a good plan will let you know what is achievable in what time frame, and most importantly let everyone in the team knows how far to go to achieve the final objectives.
Members - Reputation: 735
Posted 19 July 2012 - 05:04 AM
Often agile approaches focus on adding features as you go, and the design of the game may mean that most technical features need to be complete before you can have a full, playable level. On the other hand if up-front work is less significant and most of the effort will be in creating level content/artwork, or your game design allows mechanics to be implemented piece by piece as you progress through the levels, then this may be a viable approach.