Jump to content

  • Log In with Google      Sign In   
  • Create Account

facehead1992

Member Since 29 Mar 2014
Offline Last Active Aug 19 2016 02:09 PM

#5302275 How Do You Go About Your Game Design?

Posted by on 24 July 2016 - 02:22 AM

For me, most of my "game design" goes on in my head, typically while I'm just going about my day (I tend to be relatively busy). If I think of something particularly useful, I jot it down in the Notes app on my iPhone. When I do get a chance to just work on it, I whip out my laptop, throw up Vim (my preferred note-taking software), and start fleshing out my ideas. I'll generally listen to music as I go (either electric/instrumental or in a foreign language, anything so long as I can't understand any lyrics that would distract me). Frequently, as I type things out, I'll reach a brief stopping point where I need to actually flesh out an idea rather than jot it down. At this point, I'll get up out of my seat and start pacing. And I'll pace and pace until I've fully and completely fleshed out the idea. Or until I'm interrupted. And this can potentially go on for hours. Sometimes I run out of time and have to postpone my thinking until later, so I'll jot down a quick summary of how far I got and write down the things left that I still needed to consider.

 

Generally this all goes on for several weeks / months before I feel that I've got enough material to start working on a project "for real".Then I go to town in Unreal 4, programming something. Granted, I myself am only 23 and graduated college back in May, so I only have 1 "real" game that I worked on for 4 months consecutively with a team (everything else was school projects or game jams of 2 weeks or less, pure prototypes). But I've had about 5 games that I've come up with over the years that I feel are of sufficient enough quality to devote any actual time to and the first of those constitutes my current project, codenamed Spectral. You can look it up on cartrdge.

 

Part of my "process" is considering not just the gameplay potential of the game idea, but also the marketability of it. If I can't think of way that a game of "this sort" would have a concrete place in the marketplace, both in terms of an existing player base and the current trends in the industry, then I don't really see a reason to continue devoting time to working on its design, let alone programming anything with it.

 

Not sure what you mean about your "solid concept improvement" question. When I feel that an idea is lacking, I'll usually notice either during my original thought process or during the prototyping stage. In those cases, I can usually see what it is the player is wanting to be able to do (occasionally by getting random friends/relatives/associates to do a quick playtest), see HOW the current design is failing to properly achieve that, and then understand what things need to be fixed to achieve that. Then it's just a matter of brainstorming / prototyping different features to see if they are a good fit for creating the feeling in the player that I am seeking. A nice combination of intuitiveness, autonomy, and functionality.

 

I don't "go back to the drawing board" as often as some of the other students I've worked with before since I tend to spend a lot more time developing designs and code that emphasize robustness, so my stuff will generally "work" longer than my cohorts' before my team and I come to see the weaknesses in it. I'm actually currently on my 3rd iteration of a robust skill system (first on a project as a Junior, then again on a project as a Senior, and then now). Each time, I've come to recognize key problems in the previous versions and have begun making alterations to the design. It also helps that I've grown in general as a programmer with each year.




#5296051 What to do with extra ideas?

Posted by on 11 June 2016 - 12:25 AM

Ditto on the Google Docs note-taking backup of the ideas.

 

In my case, I've had a number of ideas that I have been developing for several years, but they are always sparsely re-visited. I would have an idea for a game or a story that I knew I couldn't produce yet, so I would sit on it, but every couple of months, I would spend a night ruminating about the idea, transform it, refine it, and then take more notes over the ideas. Over the years, many of my ideas have not only changed radically and improved, but have also become more and more within reach as my skill improves and I can start to envision how it might actually be developed, etc.




#5293901 RPG-style character development mechanics

Posted by on 28 May 2016 - 02:22 AM

Not sure if this is like the materia (haven't played FF7/FFCC), but there are many games that make it so that equipping collectible items lead to you getting certain abilities and combining them strategically in available slots can lead to unlocking new abilities, so there is experimental/discovery stuff going on that adds to the enjoyment of the game. Could also make it so that those items themselves can level up and "evolve" into new abilities.

Then you have things like Transistor where you have a single "skill" that can be equipped in 3 different slots as either an active ability, a modifier to an active ability, or a static ability. (excellent game)

 

Also, as for the web and tree systems you mentioned, the web isn't necessarily "arbitrary choice and luck" since, if you want the player to feel more directed, you as a designer are completely free to sub-develop these webs into smaller webs, highlight paths, or create 'organic' combos that the player will immediately see and think, "oh I should go this way for this kind of character!" that in turn leads them towards the abilities they need for that sort of character.

 

As for just leveling up the player linearly, the degree to which it feels like a "grind" is entirely the system designer's fault (as you described). If the gameplay experience-gain rate is slated low, then the player will have to grind. On the other hand, if you give the player the opportunity to get lots of experience more easily or if you balance the game by default so that the player has the right amount of experience by the time a skill is unlockable or needed, then the player won't feel the "grind" because they won't be battling JUST to get experience, but rather they'll be battling as they progress and happening to develop at a reasonable rate along the way.

 

Notice, however, that the balancing needed for the experience gathering rate will be the same all around so long as you have a leveling system. Levels and experience automatically result in a need for number-crunching, regardless of whether you want to do that or not. Easiest route in that case is to have a fixed number of battles, but if you REALLY wanna have random encounters, then yeah, you need to figure out exactly how many of those random encounters you will expect a player to go through before they are prepared for the next challenge area. Other alternatives are games that do NOT have a leveling system and instead rely solely on players developing skills naturally and unlocking new abilities by completing game objectives directly and/or finding items ala Legend of Zelda / Dark Souls.




#5289624 UML for UE4 Robust Skill System

Posted by on 01 May 2016 - 03:38 PM

Thanks a lot for your feedback Mekamani! I appreciate it.

 

TL;DR Start

I've done this once before on a student project, but it was limited. Trying to add robustness for usability in as many different types of games as possible.

 

Interfaces let you disregard what objects/algorithms one uses and define relationships based solely on the type of interactions they have. This would let me define my own framework, supply my own sample set of classes to actually fit the framework (implement the interfaces), but also leave other developers open to build their own versions should they want to.

 

I want to minimize code duplication and have the capacity to fully dynamically define the behavior of events in a game.

Ex. pressing "A" does (1). Pressing "B" does (2). (2) changes how (1) works without explicitly requiring me to create a new function/object for (1)'s functionality.

Ex. I press "space" to trigger a skill. I have 3 skills (A), (B), ( C ). I have 1 effect (1). I have 3 ways in which (1) is delivered. (A) uses delivery method (a), (B) uses (b), ( C ) uses ( c ). (A), (B), and ( C ) should each rely on the same function for (1), but should have 3 different objects responsible for the delivery based on (a), (b), and ( c ), minimizing code duplication. I should also be able to easily switch out (1) for some other effect (2) and suddenly get 3 new skills that each cause effect (2) in 3 different ways (a), (b), ( c ). I should also be able to make it so that if a skill ( C ) has multiple stages to it or if a skill (A)/(B) is used, I have the capacity to influence the functionality of the (1) or (2) that is in ( C ), all without changing the underlying implementation of (1) or (2).

TL;DR End

 

Now the second point and I have to admit that I haven't used unreal engine much, so it might have some underlying classes that one must use in order to accomplish something, but.... Lets say that this is the first time you are building the system, I honestly think that you should try keep things as simple as possible. If on the otherhand you have already made one version and you are trying to improve your previous design, then you can just skip the rest.

 

I actually already worked on a much simpler version of this skill system for a UE4 project at Baylor (it is used in the Steam Greenlight tactical turn-based game SYNCH). While I was able to do some nice things with it in that project, I often found myself in situations where features that we wanted to have in the game turned out to be very difficult to do with the given framework. As such, this is my current attempt to redo the framework's construction to be more viable for a variety of scenarios.

 

Anyways the last chapter thoughts came from seeing so many interfaces, that I cannot comprehend how complex of a system the pdf looked like from first glance. Or highly possibly I just do not understand what an interface is.

 

In the simplest terms, an interface just lets you define the behavior you want without concern for the underlying implementation. That is, I can build a framework for the system that I want without making requirements about how anyone actually implements it, i.e. what objects/algorithms they decide to use to fit into the framework. The ubiquitous interfaces were my attempt to decouple a sample implementation I was planning to make from the design that would be publicly visible to the UE4 system. I wanted to build something that anyone would be able to use and, if desired, make their own by creating their own implementations.

 

Anyways what I was thinking when I read your post and quickly glanced your classdiagram was, that you haven't given us any information what you are actually trying to do. Basically there is no information of what it is that you are actually trying to do. And at least I do not know what you mean by skill system, the definition could be pretty much anything, but judging from the class diagram it has something to do with spells/player attacks or something?

 

Ah, I see what you mean. I initially thought that people would understand what I meant by a "skill system," but I see that was a poor assumption on my part.

 

I tried to have a short summation of the thought process for the skill system in the diagram itself (big Note object in the bottom-right), but I you have to look in the diagram to see it, you may not notice it, and it may not even be good enough at explaining things...

 

The core usage I had envisioned was for RPGs or tactical turn-based games (like the one I helped produce), but I was also intentionally abstracting the concepts to hopefully make it viable for a large variety of game genres like shooter, action/adventure, RTS, MOBA, etc. Fundamentally, I want a system that allows me to modularly put together "abilities", that is, the culmination of a discrete set of manipulations from one game object upon 1 or more other game objects, and which provides a powerful and robust method of delivering these abilities' manipulations ("effects"). In addition, the system must make it possible for the specifications of "effects" to be variable and influenced by other effects.

 

For example...

My character has the ability to press A and shoot a bullet in a forward-facing direction. They can also press B to "charge", an action which leaves them unable to move/attack for 2 seconds and then it modifies the effect(s) of the "A" skill. It 1) increases range and 2) adds an area-of-effect element to the bullet. So, if the person presses B, charges, and then presses A, they will have a projectile that hits at farther range and hits several enemies in a given radius rather than just a single enemy at shorter range. This would be an example of where one skill's "effect" is variable and can be influenced by another "effect."

 

Presumably, ANYTHING would be able to layer on these "modifications" to skill effects though, so power-ups, equipped armor, skill tree bonuses, etc. You could even create a different skill entirely by just having permanent skill modifications to the existing skill. Indeed, if I wanted the second effect to be its own permanent skill, I wouldn't need to actually create a whole different skill that has the exact same effect with a few different stats. I could simply never remove the modifications to the skill (they are essentially added components of the skill that acts as an entity). In this way, I need only have the code that "deals damage to another game object" be in one location: the DealDamage SkillEffect. If I edit the DealDamage object, I can change the way ALL skills deal damage. It is also fully dynamic, so I can add or remove damage dealing from any given skill should I desire to.

 

Another example...

I have a bullet (deals fixed damage on impact), a fireball (deals fixed damage at regular intervals for a fixed period, i.e. a Damage-Over-Time effect), a lightning bolt (deals damage to one target, then finds another nearby target and deals the same damage to them, triggering up to 3 times, i.e. jumping twice).

 

The things these each have in common is the singular effect, DealDamage. They each differ in the delivery of that effect. I should be able to make it so that the underlying implementation only differs in the object that is responsible for distributing the effect (as would be possible - ideally - using the SkillDistributor object in the diagram).

 

In addition, I should be able to fully manipulate the effects and modifications for these skills. For example, I could take the lightning bolt skill and change its effect to be something that slows down enemies (so each hit object has a 50% "Slow" status condition applied to them - 'status conditions' aren't currently a part of the diagram, but it's a viable thing to be added). You could then also make it so that each successive "hit" resulted in an added 10% effectiveness, achieved by having the skill's own effect apply a mod to itself after each hit causing a change to its variable attributes.

 

I should also be able to switch up the way in which the skill is distributed (a volumetric area, a projectile, just targeting the self, etc.) simply by altering which targeting method is supplied to the delivery object for a skill. 

 

I hope that made it slightly more clear.




#5246632 Types of Moral Dilemmas

Posted by on 14 August 2015 - 10:20 PM

I tried looking online for some resources that might help break down variations on types of moral dilemmas so that it would be easier to come up with plot scenarios that are interesting. The most valuable piece of information I found was "A moral dilemma occurs when an agent has the motive and opportunity to fulfill two or more mutually exclusive promises and/or responsibilities and must evaluate which course of action to take." I've been trying to find something else that can start breaking things down into concrete categories / types, but I haven't really had any luck.

 

What do you guys use for inspiration of this sort? Have you found any sort of organizational structure online for moral choices?




#5242073 Is Extra Credits reliable to learn Game Design?

Posted by on 22 July 2015 - 07:24 PM

If your question is whether or not the things they advocate doing are practically useful or not, then why don't you just imagine trying to make a game that explicitly does NOT do what they are advocating? Depending on what you can imagine, you may be able to identify whether or not what they have to say really has any merit. Ultimately, it is whether what they say proves useful to you as a designer. The design process itself is highly collaborative / iterative / interdisciplinary. Personally, I find many of their videos to be highly thought-provoking and useful, but it's not as if everything stated by every designer is "the ultimate truth". People simply design according to what they believe will make a great game. How much of their advice you intend to use is up to you.




#5216781 why some turn based games are so popular?

Posted by on 16 March 2015 - 12:05 AM

Okay, there have been a lot of "swipes" at both action and turn-based games, so we should probably establish some things.

 

1. Both types of games may or may not have story as a powerful agent towards creating enjoyment in a player.

- action and turn-based has a relation to the engagement with combat and gameplay mechanics, neither of which are necessarily related to the portrayal of a story. Story is generally presented in cutscenes in between these combat scenarios, so it is irrelevant to an evaluation of whether one is "better" than the other.

 

2. Both types of games appeal to different audiences.

- action isn't "better" than turn-based just like how baseball isn't "better" than chess. One is action and re-action based, the other is purely intellectual, much like how Scouting Ninja described previously.

 

 

 


The basic and most important difference between a turn-based game and an action game is, that turn-based games are all about decision making (tactically or strategically) and action games are more about re-action and less decision making (during the action part of the game).

3. The same decision-making -does- occur, it's just that the amount of time you have to deal with that problem is drastically reduced.

- The player must rely on a split-second decision derived from their experience and knowledge of the level/mechanics, and then they must execute it, relying on their dexterity, i.e. "how fast can I make my thumbs/trigger fingers move?". In a turn-based game, the time is expanded into "infinity" (what Scouting Ninja said), so that you may choose to make this decision in any given amount of time. The more you reduce the length of a "turn", the more the game begins to approach the state of an action game.

 

 

 


well. you said very well my friends but there are something that i disagree. first you said a shooter and a turn based game are mostly the same but the time factor is deleted in turn based. i think most of turn based game give you time limitations just to prevent the game to be very slow. and you said in a shooter still you have to choice factor and im agree with it but a very important thing that makes it a shooter much better is skill factor. you should be able to aim faster, move faster and...

4. While it may be true that time mechanics can be added to preserve the flow of the game (such as in XCOM multiplayer with a limit of 1.5 minutes per turn, or something to that effect), the statement that a "skill" factor is only present in shooters is not actually the case. A "dexterity" factor is not present in turn-based games, true, but a proportionally larger amount of "intellectual" factor is. This is generally because the player must control more characters than in an action game. In action games, you control yourself and your own movements. Turn-based games usually have you controlling a group of characters and coordinating their efforts. This means that the influence of your strategy and tactics skills becomes multiplied compared to the same type of skill evaluated in action games. Both game-types require large amounts of skill. Action = intellect + dexterity. Turn-based = intellect + more intellect. Essentially.

 

Again, it's not as if one type is better than the other. They simply rely on different types of skill sets more or less and have a corresponding difference in pacing. Action generally encourages an adrenaline rush with a quick suspense-release cycle whereas turn-based has this kind of slow rise of suspense or tension resulting from the gradual development of problems and then a big feeling of success if the troubles can be averted in the end, regardless of how long it takes to do so. They can both have strong or weak stories. They both can have relatively large levels of strategy or tactical thinking. The question is simply how many times must that task be done per "turn" (controlling how many characters) and how quickly do those turns progress (milliseconds or minutes?).




#5184890 Character Ideas For My New Game

Posted by on 03 October 2014 - 10:53 PM

When you say "influences from Timberman" how do you mean it? Gameplay? Style? Themes? Whatever the case, you should carefully design a character that is going to be clearly identifiable and wholly consistent with the theme for the video game. If you tell people more about what your game is about and what the setting / thematic design is, people will better be able to suggest character ideas.




#5183838 Making a shot harder to pull off.

Posted by on 29 September 2014 - 12:46 PM

I have to seriously agree with Paragon123 here. With the level of realism you are attributing to hitting an enemy AT ALL, you can't expect it to be "difficult" to kill a person on the battlefield (because modern guns are quite simply highly effective killing tools). One limitation you can put on players spamming shots to the abdomen (which is the origin of your balancing issue) is to drastically limit the ammo available to them in comparison to the quantity of enemy troops. If they run out of ammo, they would have to acquire new ammo from a corpse, possibly even an enemy corpse, which means approaching the enemy directly without ammo / an effective defense. This is a risk that players will want to avoid, therefore they will be careful with their aiming in order to conserve ammo.




#5183253 Idea for 2-D RPG

Posted by on 27 September 2014 - 01:49 AM


Well it would do well with either, but if I made it a game it would have to be very cinematic.


While I know you said you are making a comic for now, I would advise you in the future to be extremely wary of this statement. Games are built to be an interactive medium, and while there ~can~ be value in large cinematic sequences (so long as they occur relatively infrequently, or support a massively engaging story/characters), such things are typically reserved for huge AAA productions that have the budgets to make such sequences well. Furthermore, a game that focuses on cinematics wastes the player's time when they are expecting an engaging -interactive- experience from the product.

 

Given what you are describing a novel or comic book certainly sound like a better medium if you are disregarding the use of video/film altogether from the start.

Also, for future reference, if you ever do decide to produce a game, make sure you don't simply make a game that has gameplay elements and then has a story that merely "supports" those elements. That will make a game of course, but the best games are the ones in which the gameplay elements themselves imbue the story with cohesive magic in some way. By this I mean that the gameplay and story complement each other respectively and not just one of them supporting the other alone.




#5171704 Theoritical Sandbox MMO Idea

Posted by on 05 August 2014 - 03:07 PM

1) "Market" and "Leveling" sections are incomplete sentences (as in, they just suddenly stop). Might wanna finish those.
2) The concept of your crafting process is similar, somewhat, to Divinity: Original Sin. You should check out some videos about it and get a sense of how exactly you want to design the process. That game has an excellent system, so it is productive inspiration.
3) The entire concept of "sin" that you've mentioned seems like a detrimental game design concept. Many of the activities people enjoy in MMOs is the PvP and if there is a higher penalty for killing other players, the game won't be enjoyable. The way you describe it makes it seem like any and all PvP activities will be something that only pulls players down rather than rewarding them, regardless of the context. Since most of the people are LOOKING for that kind of content, you would be losing most of your intended audience right there. I suggest having such a system only outside of duels/multiplayer matches, etc.




#5164403 New here with an idea

Posted by on 02 July 2014 - 03:23 PM

There are many people who show up with a deep game idea, but with little to no game experience. It would be more beneficial for you to begin by making a much simpler game (or multiple games), perhaps ones that have similar activities and/or objects so that, as you complete those games, you become more proficient with the tasks necessary for the other game you want to make.

Also, if you have no game development experience, it is highly unlikely that anyone here will jump on board your project as it stands. More than likely, you will need to develop your own skills independently first. You are therefore unlikely to get many people using private messages to contact you about your game. If you have specific questions about the game, how to develop it, and/or what techniques are necessary / how to go about the process of making a game, plenty of people will probably offer their assistance (myself included). I just want to make sure you have some realistic expectations of what to expect from the people here.




#5162542 Idea for samurai/ninja game

Posted by on 24 June 2014 - 08:39 AM

From the sound of it, it seems like a game that focuses on a single player story would be more akin to what you are looking for. Managing a complex story structure as you desire wouldn't be manageable with multiplayer components added on top of it. Additionally, incorporating online multiplayer as part of a solo beginner project is really not viable at all. To minimize the amount of content you have to make, I would suggest making a general campaign that every character participates in to some degree, completing the same missions (possibly with very minor differences), and then, since you really want there to be a unique plot integration for each "class", also having a separate line of missions that are exclusive to the specific class being played. For example, there may be a quest in which multiple shoguns are all fighting against a particular threat (the group storyline), and then there could be a few quests that focus on the individual activities of the class. This way, you can produce content that will be used by all of the classes and just devote a relatively small portion of your resources to developing content for the "unique" class stuff. Otherwise, you'll be producing 3 times the work of an actual game in order to essentially create 3 different games, one for each class.

I would suggest you use a simple game engine, particularly one that uses a 2D system, for game development since you are a beginner. Game Maker: Studio is pretty good (been messing around with it lately). The free version limits the number of items you can have, but it's still a good program. Another option is Construct 2 which is HTML/CSS/JS based. It's pretty good as well. Not sure about other options though. I would NOT recommend Unity for this type of project. A beginner jumping into 3D game development wouldn't really be a good idea imo. Not unless you are willing to devote several hours just to learning about texturing, lighting, modeling, and animation techniques, aside from the other aspects of learning how to program a game.




#5162338 Idea for samurai/ninja game

Posted by on 23 June 2014 - 08:59 AM

I agree with Lorenzo. You've got a lot of stuff you are trying to integrate into a single game and especially as this is your first game, you should start with something exceptionally small. Blurring styles is something that lends itself to people with more experience with the individual styles involved, as well as general game development/design experience already. Each person here likely has several "dream games" that they would like to make one day, but you should be patient. Wait until you have the right team/skillset/experience so that when such a game IS made, it can be exceptional.

In the mean time, you could attempt to make games that are representations of each of the separate elements of the game you want to make. Every game is, in and of itself, a combination of simpler games after all. Even Tetris is composed of the games of "identifying the blocks", "positioning the blocks", "rotating the block for the right integration", and then executing those steps as quickly/precisely as possible. It is worthwhile training to make sure you can complete the smaller tasks for your game efficiently before running head-on into the foray. What's more, the results of your efforts can effectively act as prototypes of the game you eventually wish to make anyway. You will have things to work off of and will become more aware of the pitfalls associated with developing that particular type of game system.




#5160773 Questions about making a game and a general idea

Posted by on 16 June 2014 - 12:27 AM

Yeah, everything Tom said is pretty much the gist of it. If you have little to no experience making games (which is similar to my own department), it would be very wise for you to either start with things as simple as possible (if you want to make something yourself and develop your own skills) or work on a game that someone else plans to program. You essentially need to decide whether you want to learn programming and really become proficient with it. Since you said you were more of a writer/designer, that may not be something you want to devote yourself to - in which case, you'll wanna find someone else already making a game and help them as a writer/designer. I think of myself as a programmer, game designer, and narrative designer, but I'm not talented at actual narrative writing, so I understand the predicament a bit, especially since I am not yet in contact with any writers willing to do free work on a project that likely will not yield any funds.






PARTNERS