Recommended Posts

What techniques do you use to help develop the plot alongside gameplay when you finally have an idea for a story down?

Share on other sites

There are many ways to build games.

As a direct answer to your question:  Virtually none.  Basic gameplay mechanics should be fleshed out with only the most vague ideas of a story. Mechanics should be identified which are fun and compelling in their own right, not forced into a story.

In my experience in the professional world, the story tends to be far down the list and relatively late in the process.  Often the people writing the game are told a general theme and told the rest will be fitted to the mechanics.

There are mechanics and gameplay experiments long before stories are ever considered.  Developers experiment with the mechanics, try a wide range of mechanics, try to find ways to make the mechanics work together or break when used in combination. If there is a hint of a story at this point it is only the most vague framework to explain how the mechanics interconnect, more of providing a genre rather than plot points.

I've worked on and worked with others on many projects where the studio builds mechanics to be played with based only on the most vague specifications.  We have an early project like that right now at my job where a small group of people have been assigned to implement a range of mechanics for games that don't even have a genre.  Questions like "Is this going to be more of a tactical game or more of a strategy game?" are answered with "here are some more mechanics that look good on paper mockups, depending on how they feel at computer speed we might be able to answer that."

As a large suite of mechanics is developed the beginnings of a story can be built that can leverage the mechanics. As the mechanics are being pruned down to the essence of the game, the story pieces can start to form built around the mechanics. A full plot should wait until the mechanics are realized and gameplay is fun.  A fun game system can be used to tell many varied stories, but good stories tend to be specific to the game systems they are in.  And many amazing games have no story at all.

In my observations of the hobby world, the many games based around stories will write the story and the plot, they'll have all kinds of numbers for their supposed tuning long before any code is written.

I've seen design notebooks filled with specific game items, specific armors, specific weapons, all with a long list of (meaningless) values. Often there is a teen-focused adventure story full of plot twists and bad writing where the teen overcomes the school bully and vanquishes the world. There are drawings of the characters, their faces, descriptions about how charismatic or crude each party member should be.  There are intricate sketches of weapons and armor, and full descriptions of how Epic Armor of Awesomeness has 1337 defense plus 40% defense against undead monsters and school administrators, but there is no definition of the math those numbers plug into.

These projects tend to fall down long before code is ever written or actual game art is ever created. A few will have some experimental code written around them, or some white-box levels written in Unity or Unreal. But when they realize just how much work is involved, that they've created a project that would require thousands of work-years to implement, it will be abandoned by the wayside.

Share on other sites

I fully agree about hobby games that tackle complex or new gameplay mechanics. These should go on the back burner until the hobbyist has a lot of experience.

Twine/Inklewriter games, visual novels, and RPG Maker games, however, are within the reach of even first-time hobbyists, and they're a good way to hone interactive writing skills as well as general game design skills.

So when you finally have an idea for a story down, you might consider choosing an existing gameplay genre (such as a visual novel) that fits your story and your current level of experience.

Create an account

Register a new account

• 10
• 19
• 14
• 19
• 15
• Similar Content

• By Shtabbbe
I've had a game idea for a while, and I wanted to finally try to create it.
Its a 2D open-world tile-based MMO. The concept is it is one world and multiplayer only, so everyone shares one world no matter region, platform, etc.
I am having problems finding out what to use to start development, I tried Unity but saw some of the negatives and refrained and now im stuck, could anyone recommend some intermediate friendly 2D engines that can support what I am looking for? Preferably in languages that are or are somewhat like Java, C#, Python, JavaScript, Lua.
Thanks for your help, im very new at this if you cant tell

• Do you know any papers that cover custom data structures like lists or binary trees implemented in hlsl without CUDA that work perfectly fine no matter how many threads try to use them at any given time?

• Hi there.
I'm looking for some quick opinions, advice or other comments on my custom engine architecture.
For better or for worse, I have ended up with an ECS engine. I didn't intend to go this way, but countless searched through Google and the forum seem to confirm that this is the case. I have entities (mere Ids), components (pure data) and systems (holding raw resources and functionality) to operate on them. To be honest, I'm fairly happy with it.
However, I have yet to implement any actual logic into my 'game', and have been looking around for details on the various ways of handling interactivity, specifically, interactively between entities and components.
A topic that comes up a lot is events and event queues. I have not liked these. I don't want to add functionality to entities or components, and I don't like the idea of callbacks or event calling firing all over the place. So, I have been puzzling over this for the last two or so days. Eventually, I gave up on the musing and came to accept that some kind of event system is going to be needed. So, I had another look at the bitSquid blog (recommended on this forum), and something occurred to me. Isn't an event really just another form of entity? If it isn't, why isn't it?
I also realised that I already have something pretty similar running in my engine now. Specifically, my (admitted quite naive) implementation works more or less like this. The scene hands a list of physicalComponents and their corresponding placementComponents, and the collisionDetection sub-system iterates through them, looking for collisions. If it finds one, it creates a collision, adds it to the list, and moves on to the next one. Once it is finished, the collisionResolution sub-system goes through the list, and handles the collisions - again, currently very naively, by bouncing the objects off of one another.
So, I am wondering if I can just use this same approach to handle logical interactions. Entities with logical requirements have a collection of components related to interactivity (the range, the effect, and so on), and the various sub-systems iterate through potential candidates. If it notices an interaction, it creates an interactionEntity (with the necessary data) and the interactions are processed by the next sub-system.
I guess I'm looking for some feedback on this idea before I start implementing it. The hope i for more granularity in the components, and the ability to add a logical scripting system which combines various components into potential interactions, and omits the need for any kind of event system. Or am I just repeating the general idea of events and event queues in a slightly more complicated way?
Additionally, any comments or commentary on this approach (ECS, and so on), would be very gratefully received. I've pretty much run out of resources at this point.
Regards,
Simon

• A few questions about some c++ code
So I am starting to get back into c++ after about 12 - 14 years away from it (and even back then, my level of knowledge was maybe a little above beginner) to do some game / SDL programming. I was following a tutorial to get at least a basic starting point for an entity component system and it works however there was some code that I don't quite understand even after looking around little.
First pice of code is:
T* component(new T(std::forward<TArguments>(arguments)...)); This seems to be assigning the component with the results of what is in the parentheses though normally I would expect this:
T* component = new T(std::forward<TArguments>(arguments)...); Is this just syntax preference or does the compiler do something different with the parentheses (it is weird to me as when I see that, I think it is a function call)?
The second piece of code I think I understand the general idea of what it is doing but some of the specific are escaping me:
template <typename T, typename... TArguments> T& Entity::addComponent(TArguments&&... arguments) {   T* component = new T(std::forward<TArguments>(arguments)...); So from my understanding, the first line would basically take this:
entity->addComponent<TransformComponent, int, int, int, int>(x, y, width, height); and take of the first item in the template and assign the to T and then "group" (not sure the correct term) the rest of the items as a collection of some sort and then the ... on the second line would group the arguments (that would need to match the template group) that were passed in. Then the third line is effectively converting the template / passed in arguments to be called like this:
TransformComponent* component = new TransformComponent(x, y, width, height); The parts that are a bit confusing to me is first the &&. From what I have read (from stack overflow), that symbol means rvalue reference or reference to an argument that is about to be destroyed. Not quite sure what it means by it about to be destroyed.
The second part, which I think related to using &&, is the std::forward<TArguments>. The explainations that I have found so far as are bit confusing to me.
I will continue to try to find the answer to these confusions but I though maybe someone here might have an explanation that might make more sense to me. I would also consider it quite possible that there is some prerequisite knowledge that I might not have (I mean I think I have a decent understanding of pointers and references) so if there is other stuff I should looking into, that would be great too.

• Hello I am looking for advice to what I should do next as I just completed the Unreal Developer Course on Udemy and now am at a lost as what to do farther as practice and to expand my knowledge. My background is 2 years studying college in Videogame Design and 3 years working on 4 years studying Software Engineering in college. I am mainly focusing on using my C++ knowledge with Unreal Engine to make indie games but I do also know Java, and C# as well, but I do not know Unity. I am welcoming any advice that can help with my current situation with my current skill set