Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


What is your game development process?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Jovince   Members   -  Reputation: 158

Like
0Likes
Like

Posted 19 December 2011 - 01:03 AM

Hi everyone,

My current approach to games design is writing a rough and unstructured high concept document to record my ideas and other considerations I need to define about the game. I then skip the design treatment stage and head straight into the mechanics section of the games design document. This is where I spend most of my time, and while working on this section, i begin to flesh out the game elements and AI design. After completing the mechanics, I move onto finishing up the game elements and AI design to suit the mechanics. I then finish up the other sections and begin to design the first level, though I have never really progressed passed the first level lol.
i know that my approach is quite flawed, since I have suffered much grief during the development stage. My current approach has a very hazy vision of how the game features, such as the mechanics, game elements and AI all come together to create the intended gameplay, and as such, the level design is affected. I don't really have an approach for game balancing either.
So I would very much appreciate it if you would let me know how you approach designing games, and to give me any other advice you think is beneficial. Thanks and God bless :)

Sponsor:

#2 Ashaman73   Crossbones+   -  Reputation: 7797

Like
1Likes
Like

Posted 19 December 2011 - 01:30 AM

Hi everyone,

My current approach to games design is writing a rough and unstructured high concept document to record my ideas and other considerations I need to define about the game. I then skip the design treatment stage and head straight into the mechanics section of the games design document. This is where I spend most of my time, and while working on this section, i begin to flesh out the game elements and AI design. After completing the mechanics, I move onto finishing up the game elements and AI design to suit the mechanics. I then finish up the other sections and begin to design the first level, though I have never really progressed passed the first level lol.
i know that my approach is quite flawed, since I have suffered much grief during the development stage. My current approach has a very hazy vision of how the game features, such as the mechanics, game elements and AI all come together to create the intended gameplay, and as such, the level design is affected. I don't really have an approach for game balancing either.
So I would very much appreciate it if you would let me know how you approach designing games, and to give me any other advice you think is beneficial. Thanks and God bless :)

I prefer a more agile approach opposed to the standard waterfall model. In fact, I gather ideas of the whole game all the time, write them down,group them, erase them etc.

But the next big step is a fast iterative approach to implement these ideas, starting with simple mechanism and going into details in later iterations. For each iteration I have a fix, small, manageable goal (i.e. improve combat, reduce attributes, come up with a simple inventory system, polish the inventory system etc.) which could be archived in 2-4 weeks (it is similar to SCRUM). The topic of each iteration is more or less random, what interested me most at the moment.

Why does it work for me ?
1. In fact, it's only a 1 1/2 man show, no large team to manage.
2. Start with small goals will deliver fast success which keeps the motivation up.
3. Instead of avoiding feature creep, I included it to some degree in my process, this way it could still hurt the process, but only in a limited way (one short iteration to test X).
4. 50% of the design will be discarded over time, once the implementation has started (your super cool, over one and a half year developed, interactive combat system will be disposed, after playing it for 5 minutes).
5. Fast iterations keep your design closer to the reality (Better not to discover that your killer-feature is not realisable on current hardware after a 2 year design phase.)
6. fast feedback-loop: the result of each iteration will influence the whole game developing/design process.
7. Avoiding of the investment-trap: once you have invested too much money/time into feature X you will hesitate to discard it, even if it is crap.

#3 Jovince   Members   -  Reputation: 158

Like
0Likes
Like

Posted 19 December 2011 - 02:22 AM


Hi everyone,

My current approach to games design is writing a rough and unstructured high concept document to record my ideas and other considerations I need to define about the game. I then skip the design treatment stage and head straight into the mechanics section of the games design document. This is where I spend most of my time, and while working on this section, i begin to flesh out the game elements and AI design. After completing the mechanics, I move onto finishing up the game elements and AI design to suit the mechanics. I then finish up the other sections and begin to design the first level, though I have never really progressed passed the first level lol.
i know that my approach is quite flawed, since I have suffered much grief during the development stage. My current approach has a very hazy vision of how the game features, such as the mechanics, game elements and AI all come together to create the intended gameplay, and as such, the level design is affected. I don't really have an approach for game balancing either.
So I would very much appreciate it if you would let me know how you approach designing games, and to give me any other advice you think is beneficial. Thanks and God bless :)

I prefer a more agile approach opposed to the standard waterfall model. In fact, I gather ideas of the whole game all the time, write them down,group them, erase them etc.

But the next big step is a fast iterative approach to implement these ideas, starting with simple mechanism and going into details in later iterations. For each iteration I have a fix, small, manageable goal (i.e. improve combat, reduce attributes, come up with a simple inventory system, polish the inventory system etc.) which could be archived in 2-4 weeks (it is similar to SCRUM). The topic of each iteration is more or less random, what interested me most at the moment.

Why does it work for me ?
1. In fact, it's only a 1 1/2 man show, no large team to manage.
2. Start with small goals will deliver fast success which keeps the motivation up.
3. Instead of avoiding feature creep, I included it to some degree in my process, this way it could still hurt the process, but only in a limited way (one short iteration to test X).
4. 50% of the design will be discarded over time, once the implementation has started (your super cool, over one and a half year developed, interactive combat system will be disposed, after playing it for 5 minutes).
5. Fast iterations keep your design closer to the reality (Better not to discover that your killer-feature is not realisable on current hardware after a 2 year design phase.)
6. fast feedback-loop: the result of each iteration will influence the whole game developing/design process.
7. Avoiding of the investment-trap: once you have invested too much money/time into feature X you will hesitate to discard it, even if it is crap.





Regarding the iterative approach, do you have a particular way of identifying issues that need fixing and refining? And do you have a particular way of balancing the mechanics and refining the levels, or is it all through play testing? And how and what would you prepare for play testing and how do you ask to play test? Sorry I have a lot of questions lol

#4 Ashaman73   Crossbones+   -  Reputation: 7797

Like
0Likes
Like

Posted 19 December 2011 - 03:43 AM

As already said, these are my personal feelings for a very small team. Thought similar agile processes like SCRUM are quite common in the software industry.

Regarding the iterative approach, do you have a particular way of identifying issues that need fixing and refining?

Simple priority list of things which need to be done, which could change from iteration to iteration. Sometimes you got a bad feeling about a certain feature you need to pull off to get other features to work correctly. I.e. a night-vision in a shooter, if you are uncertain you could implement the effect you imagine, just concentrate on the next iteration on the visualisation of a night-vision effect.

And do you have a particular way of balancing the mechanics and refining the levels, or is it all through play testing?

First off, I subdivide larger goals into smaller chunks. I.e. an equipment/inventory system. I started it this way:
Iter1: simple gui
Iter2: simple inventory system with fix slots
Iter3: simple equipment system

The next iterations I wanted to improve inventory management
Iter4: fancy item management idea implemented
Iter5: bag support (increase number of slots by adding bags)
Iter6: polish gui

In Iter5 I came to the conclusion, that all the fancy item management ideas are great... but were just too complex so I added an other iteration
Iter5b: reduction of item management actions

After that I concentrated on gui handling:
Iter7: add drag'n'drop support
Iter8: polish gui

In a waterfall process you would design all at the beginning, including my fancy item management idea, which would be integrated in gui design, loot generation, crafting system, trading system etc. In a waterfall process it would really hurt when discarding the fancy item management idea, now I just had to adjust my inventory system.

And how and what would you prepare for play testing and how do you ask to play test? Sorry I have a lot of questions lol

Currently I do most of the testing by myself. On and off a friend will test the game and I watch him playing. This is really a great experience, because he often sees the game in a such an other way (ignore things I worked on for weeks, other things which has been done just for fun, were really great in his opinion, things I found quite easy, were hard etc.).

In the long run, I want to get a free to play, pre-alpha version out as soon as possible, but I've always this inner conflict about that it is not ready now... but I'm working on myself. :wink:

My hope is, that one or two people find it interesting enough to give some feedback, but this is an agile process itself and it could change once I got a playable version out.

#5 Dir3kt   Members   -  Reputation: 166

Like
0Likes
Like

Posted 19 December 2011 - 04:28 AM

First of all I'm a rookie working as a one man team with no published games yet. So take this with salt ;)

1) Like Ashaman73 said: Divide to conquer to make each problem easier to solve. Do not attack all your design at once, take it step by step. If you are blocked on one part, try to work on another part. Just by not thinking about your original problem, you might get a fresh look at it and find the solution when you come back to it.

2) Early prototyping. Can't stress this enough. Playable prototype are even better. Show them to your friends and see how they react, do they like it? do they have fun? You will get lot of feedback, find out what is fun/what is not fun in your game and get lot of new ideas (but take care of point 3).

3) Beware of feature creep. I think this is what kill most of the indie projects we see here.

Good luck!



#6 Acharis   Crossbones+   -  Reputation: 3878

Like
0Likes
Like

Posted 19 December 2011 - 05:08 AM

4. 50% of the design will be discarded over time, once the implementation has started (your super cool, over one and a half year developed, interactive combat system will be disposed, after playing it for 5 minutes).

LOL, I'm glad I'm not the only that discards a huge part of the code before the game is finished :)

I use quite similar appoarch to Ashaman73. First, I go for a very short waterfall to implement the core features (whenerver I fail in this stage the game suffers and is usually cancelled). Then I switch to agile and act according to tests and feedback.

I'm not sure if this is the best method, would love to have more defined specifications before I start... Sometimes it work, sometimes not. At least it allows me to cancel poor projects faster than in case of waterfall projects, so, while it is more troublesome to develop than waterfall it let me waste less time in the long run.

Europe1300.eu - Historical Realistic Medieval Sim (RELEASED!)





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS