Jump to content
  • Advertisement

Syracus

Member
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

196 Neutral

About Syracus

  • Rank
    Member

Personal Information

  • Interests
    Art

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Syracus

    Dynamic world framework

    The reason it's not a standard is that it's much more costly. Having a game that plays itself, in addition to the player playing it, is extremely resource intensive. Not only that but it requires much more development work, on AI, on optimization, on assets, on design, etc. Now, if it is better (and it definitely is), that could be worth it, but at equal cost it means the game will have to compete with similar games offering a much more refined experience. The simulation completely changes the game, but from an outside perspective it will just look like a lesser game. Only people that really get into it will see the difference. There are also new challenges, like chaos and complexity. Because the player has much more freedom, you have much less control over his experience. That lack of control over the player experience is why players end up reducing a potentially rich and dynamic open world to a boring fishing/walking sim. That's why they have trouble dealing with the complexity of the game, or its difficulty. However, while it's not a standard, it's slowly becoming one. Open world games are becoming the norm, non linear games are becoming the norm, immersion and freedom are considered more and more attractive. Eventually, most rpgs will adopt that model, we just have to wait until technology makes it more cost-efficient. And learn from games that are already doing it. Either because they have huge amounts of resources and can support such systems (mmo), or because their nature makes such dynamic systems very cheap to simulate (turn-based, 2D). Mmorpgs are a good example, because they have the resources to do that kind of thing. GW2 for example has dynamic events, and while those events are limited by the multiplayer nature of the game, they achieve what you describe pretty well. On the other end of the spectrum, Rain World has a completely dynamic ecosystem. It's a truly unique indie platformer and it's both excellent and terrible at times. A great example of how even a very simple dynamic world can generate huge design problems. For every beautiful and unique outcome of the dynamic system, you have a completely chaotic and frustrating one. It's both the reason to love and the reason to hate the game. And the game could be absolutely great if only it supported its dynamic design. A dynamic world means that you need a dynamically controlled player experience, otherwise it's just chaos. Dynamic difficulty and storytelling will become the norm as well, because without them those kind of games simply cannot work. Designers will have to find new tricks to control what players do in games where they can do virtually anything they want.
  2. Usually procedural generation helps with the replayability, which is important for rogue-likes and survival sandbox game, but there are advantages to static maps. In the end there is no absolute best answer, it depends on your game and the type of gameplay it involves and how you expect people to play it.   If you are designing for short sessions (20-40 mins), it might be necessary to have some level of procedural generation and randomness to your game or it will feel repetitive. If you expect longer playthroughs, then you can use a static map. It also depends on the size of your map, the smaller it is, the faster the player will fully memorize it and start to feel like it's repetitive. If your gameplay loop includes exploration or searching, then you need to have at least the resources be randomized, otherwise people will just learn the position of everything and you will lose a major element of your gameplay. I would advise you to look at other games (3D survival games) and how they do it and how it works well with their gameplay (or how it doesn't). Subnautica is a good example to study for static maps and their advantage. The Forest is another.   Finally it depends on your technical proficiency, you will probably be able to do more interesting and interactive maps if they are static, while procedural generation might force you to simplify things. Static maps also give you more control over what the player does and feel, if your game is narrative-heavy for example, it's important to be able to fine-tune the map to control the player experience. If you don't plan to make use of those possibilities that only a static map can provide, then there is little advantage to using a static map over a procedural one. If your static map would look similar to a procedurally generated one, then go for procedural generation and offer your player an "infinity" of variations. In the end a static map is just like a single output of a procedural generation system, the only good reason to use one is to do things that would be impossible with a procedurally generated map.
  3. It will usually end up with everyone following a meta that changes with your continued balancing of the game. No one would choose customization over competition. That's how it works in every single competitive game that involves rpg elements, look at MOBAs for a perfect example of that. Fighting games rely on reflexes and knowledge, it's all about executing combos correctly, they are speed and dexterity games, very different from rpgs and they attract very different players who are looking for very different types of gameplay. Just because customization is usually a good thing in RPGs doesn't mean it would work well in other genres and with different types of players.
  4. Can't think of any mmo-style fighting games, but you should ask yourself this question whenever you have an idea no one has tried before : Why has no one tried that idea before ? Usually the answer isn't that no one ever had that idea before, but rather that it's simply not a good idea. Or not a feasible one. Typically, what would be the advantage of a mmo-style fighting game over a regular multiplayer fighting game ? I can't find any, you will only dilute the gameplay that people want from a fighting game with tedious less interesting gameplay. Bringing rpg elements to a fighting game means you are creating unbalanced fights, which is game-breaking for a competitive fighting game.
  5. Syracus

    Why watching movies is a necessity for games

    It's important if you work on the creative side of games. Games are increasingly replicating cinematic experiences as the technical limitations disappear. When you say that your friends watch movies, are you implying that you don't ?
  6. Syracus

    Dungeon objectives in randomized RPG?

    The narrative part doesn't have to be randomized or procedurally generated, which would be difficult to do. You can just slap it on top of procedurally generated content like the dungeon's layouts. To a degree, Darkest Dungeon did just that with the "boss dungeons". Although they were similarly randomly generated and used the same assets as regular dungeons, they also had a mini story associated with the unique asset of the dungeon, the end boss. Then again, you are right and this type of games doesn't need a strong narrative as much as other RPG types, as proven by DD's success, but in the end it can only make the game better, so why not do it ? It opens up an infinity of options for dungeon objectives, since they are then story related and not just design related, which solves your problem, and it also makes your game different. If you don't want to do that, the number of possible objectives only depends on your mechanics. With the ones you listed so far you would have : Exploration : explore a minimum number of rooms, all rooms, a specific room, a succession of specific rooms (key-treasure), a maximum number of rooms (you can only explore X rooms and need to find the final room before you do), follow a specific path (no backtracking allowed for example, tunnels collapse), avoid specific rooms/paths. Traps/obstacles : encounter X number of traps/obstacles, overcome X number of traps/obstacles, avoid X number of traps/obstacles, find/overcome/avoid specific traps/obstacles, overcome obstacles in a specific way (a locked door might need a key but you could force it with a lockpick if you can't find the key, and doing so could be an objective or a failure condition). Enemies : finding/killing/avoiding a certain number of enemies or specific enemies, surviving a specific enemy (this enemy cannot be defeated and instead you need to survive the battles with it), killing enemies in a specific way or in a specific room, chasing an enemy that can move from room to room, avoiding an enemy that can move. Party : doing any of the above tasks in a limited time or in a limited number of turns/actions or using a limited amount of resources or specific resources/items, doing so using only certain heroes or X number of heroes or a specific formation/tactic, doing so while satisfying one or many conditions related to your party, like a no-death run, or completing the objective with all your heroes at max hp, or not taking any damage, or having a certain number of heroes die, or having them be extremely low hp, doing so while not using any item or mana, etc...
  7. Syracus

    Dungeon objectives in randomized RPG?

    About the ideas you already have, most are pretty traditional and have proven to be effective. You can see they work well in Darkest Dungeon and similar games. I would suggest you study that game to find out what are the weaker points of it, what is lacking and what could have been done better or just differently. For example, for a rpg, Darkest Dungeon is pretty light on the story/lore. The focus is more on tactics and resource management, but they could just as easily have had a more narrative-heavy game while keeping those. You could look into that to make your dungeons different and more interesting/engaging. If you have a mini storyline for each dungeon, it opens up a lot of possibilities, for example you can have puzzles and enigmas as obstacles which require knowledge of your world and its logic from the player instead of just a specific type of resources (like the shovel in DD), you can have story-related objectives which are infinitely more engaging and fun and potentially diverse than the ones you have now and exist in DD. Those would underline the uniqueness of each dungeon and be very immersive instead of doing the complete opposite of that ("80% exploration" is both very gamey and very bland). The challenge is then to manage to conciliate narrative and random generation. You have multiple options there, depending on the length of your game. If the number of dungeons the average player would visit in a single playthrough is small, you could just handcraft a large enough number of dungeons with unique storylines so that the player doesn't visit the same one twice. If the number is too big, then you will need to have more generic storylines and use modularity to your advantage. It wouldn't require much apart from additional writing, you would still use the same art assets and generate the layout of each dungeon randomly, with maybe some extra rules and exceptions associated with each storyline to make it more interesting and if you are feeling courageous, some unique assets for each dungeon, like a unique boss for example. On a basic level, there aren't that many different design options for objectives unless you are ready to introduce new mechanics, so "coating" them with a layer of narrative to make them appear more varied is a good alternative in my opinion.
  8. Syracus

    Balancing & Scaling heals in an RPG

    Why not simply have heal mitigation ? If you want it to mirror your damage system, it's by far the easiest solution. You set the heal mitigation equal to the damage mitigation and it works perfectly. No matter the scaling of the heal or the type of build, it always heals for the same EHP and it respects your wish. It's perfectly balanced and extremely easy to implement as it's just a copy of your damage system with negative damage values. Then the problem shift from a design one to a creative one : you have to make it work with your lore. Fortunately you can pretty much do whatever you want there, so it's an easy one to solve. For example, an armor that blocks magic would mitigate magic heals just as much as magic damages, it's quite logical. In fact it's more logical than most games, more realistic and immersive.   Now, I just want to ask you something : is it best to have perfectly balanced builds ? If there is no practical difference whatsoever between the two options you are offering, what is the point of even offering those options ? Unless you want those options to be balanced regarding heals and damages and instead offer trade-offs in other areas.
  9. It's only grinding if it's the same content over and over again. Don't want grinding ? Shorten your game or increase the amount of content, and it won't feel grindy because you won't be doing the same content multiple times. There is no reason behind making the player redo the same content over and over apart from artificially increasing the length of your game. And if you do that, the length of your game doesn't matter. It's only good to have a long game if players want to play more of your game. If you end up diluting the experience to increase the length, you are only making your game worse. What you want is density, then length. Density without length is ok, the opposite is not. The inherent balancing problem with player progression in rpgs is easily solved : either you have optional content and you need dynamic difficulty, or you don't. If you don't, which is your case here and precisely what you want to change over Darkest Dungeon, then balancing is straight forward, you just need to balance the dungeon's difficulty with the player's progression and the set difficulty. Design your progression system so that it's impossible to get stuck regardless of your skill. Design it so that skill is more important, so that the increase in difficulty is relevant to the skill of the player and not the stats of the characters. Basically you want player progression to match dungeon difficulty progression (both characters and enemies gain 1 level for example) and on top of that you want to increase the difficulty related to skill slightly, so that it feels harder. You want the player to fail because he/she wasn't good enough, not because he/she encountered an impossible level. If your heroes can "get behind", then it means your game is impossible to win on the first try/tries and that you need to grind multiple playthroughs to finally have a chance at winning the game (if it has an end), which is in my opinion terrible roguelike design and it would essentially reintroduce grinding in your solution to get rid of grinding. I think it's much better to not have anything carry from one playthrough to the other, let skill and not grinding be the decisive element in your success. Whether you want infinite or finite levels is up to you, both have their pros and cons, but both are better without grinding.
  10. Syracus

    medieval resources

    I suggest you look at historical documentaries or history books. There is plenty of material there, that is not only historically accurate, which makes it realistic and coherent, but also original. Most games and works of fiction use and reuse the same basic things over and over, and those have become extremely unoriginal and boring, in addition to being sometimes wildly inaccurate or straight up unrealistic. There are thousands of different ways to extract resources and craft things, from many different civilizations and ages. Games usually oversimplify those mechanics, you don't need to, take an object and do your research to find how that object was crafted from scratch at the time. You will most likely find a long list of jobs and resources you never heard of that were essential parts of that process. That's the easiest way if you don't want to invent everything all over again.
  11. Do you want to frustrate the player ? Because that is what such a mechanic would do. Why do you want to frustrate the player in this specific instance ? People have already pointed out multiple ways you can do that, and also multiple reasons as to why it would generally be bad design and how to mitigate or negate it. If you make the enemy hard enough that an expert player fully prepared would only win by a narrow margin, you really don't need any special mechanics to prevent a successful first try. All you need is to include at least some aspect of knowledge into the difficulty of the enemy, so that it's not just based on dexterity/reflexes. That can range from impossible-to-guess weaknesses to just a bunch of unforgiving combos that you need to see once to be able to dodge them. Keep in mind that the game is usually gonna feel harder for other people than it does for you. Set the difficulty you want and then tone it down a bit, it's usually a good way to go about balance.
  12. Syracus

    Relaxed explorer

    I think that's not a bad idea, obviously adding narrative is never a bad decision, but I don't think you need it, I think you could do something simpler that would still work. A roguelite is a game that shares characteristics with roguelikes without really being a roguelike. Roguelikes are games like Rogue, games that feature perma death, procedurally generated levels and turn based combat. Basically you start the game and you try to make it as far as possible before dying, then you have to start over completely, similar to an arcade game.   Roguelites are games that share the same philosophy but with slightly different mechanics, usually they have perma death and procedurally generated levels, but they abandon the turn based combat and they also might try to mitigate the perma death with progression options where you unlock stuff with each new playthrough that is persistent when you die. That way you don't lose all progress everytime you die.   I think you really should check out some games in that genre, that might help you figure out exactly what you want to do. Kingdom is the best example I think, it's a sidescroller survival roguelite focused on base building and management. Its gameplay revolves around a super simple mechanic, so that is different from what you want to do, but everything else is pretty much what you described. Don't Starve is another good example, it's not a sidescroller, but it's an excellent survival roguelite.   The first thing you should figure out is if you want perma death, personally I think it would fit your game perfectly. Then each playthrough would be about surviving for the longest time (or you could have an endgoal like in FTL, another roguelite). Then figure out the survival mechanic, how you die and lose the game. Then build around that. You should focus on those things first because they are the core of your game and they will shape the rest of it, so if you try to think of specific mechanics first, it's most likely you will have to redo everything because it won't fit.   Regarding the art, I think it's ok for a first try at pixel art, no one is born gifted, art is something that you learn like everything else, I think you could easily improve enough to make the art yourself. Pixel art is fairly simple. I've seen people become really good at it even though they were way worse than you when they started.
  13. Syracus

    Relaxed explorer

    Sounds like a very interesting idea, though I'm not clear on certain details. It's a sidescroller survival game from what I understand. Is the goal of the game solely to survive as the gobelin ? Or is it to have a base strong enough to survive the next winter ? Is there permadeath ? Do you want to make it a roguelite ? Do you lose if you die or if your base is not strong enough when winter hits or both ?   I think you could make a pretty original roguelite, it's a cool idea to have the base be an end in itself and not just a mean to an end like in most other survival/roguelite games. I think it would be a really good angle to explore, making a survival game that is as much about your own survival than it is about your base's survival. You could explain it by saying that you can't survive the winter without a base in decent condition or that the gobelin is a creature that withers and die without a home.   Pacing shouldn't be a problem, it's mostly about fine tuning and balancing the game. You could have increasingly harsh winters requiring the player to constantly upgrade his base, or non/slowly renewable resources forcing the player to always explore further away to keep surviving. And as you explore further, zones are more challenging.   Backtracking is the real problem. It's especially a huge problem with non linear sidescrollers. Look at a game like Kingdom, you end up going back and forth over and over and it's really tiring. They introduce fast travel options to try and fix that issue, but it's still there to some degree. There is no magic solution to backtracking : either you make the travel interesting or you get rid of it altogether. Fast travel options or a dynamic world that will change and make the journey back different from the outward journey. It's a sidescroller so you can easily make the journey part of the experience by introducing platforming elements and puzzles (which you have already done it seems). It's not just an obligatory step to get from one point of interest to the other. Then all you need is to find ways to make the journey different, either by actually making it different (using verticality) or by modifying it on the way back. That or fast travel.   You could have the gobelin go down a cliff to access a certain zone for example and not be able to climb back up so you would need to use a tunnel that runs below it to return to your base. Or have platforming or puzzles change as you do certain things, for example you cross a bridge that later collapses or have your item be consumed when you go through that deadly lake and you need to find a new solution to cross it again. Just having 2 different solutions for each "puzzle" or obstacles and forcing the player to use both to go back and forth would be enough.
  14. Syracus

    Completely custom skills mechanic for RPG

    Regarding your particles, I'm just saying that they are objects with attributes, nothing more. I think I understand what you want to do, even though I don't quite understand how you want to do it and I don't agree on some decisions (I still think your would end up making a better game if you focused on your original system and designed a game around it).   Anyway I'm curious to see a prototype of this if you end up making one.
  15. Syracus

    Completely custom skills mechanic for RPG

    I'm not saying people can't enjoy more simple and straightforward gameplay, I'm saying that people looking for this won't look for your game. The level of customization you want is neither simple nor straightforward and people who want that will look at other games. The people your game will attract will like it because of the extensive and sandboxy customization and those people will probably not care about limited mechanics if they have other options available. There is no reason why a player who has access to both limited physical skills and almost unlimited magical skills will want to use the former. You are basically giving the players a super cool super powerful gun and a shitty pistol and thinking that they will care about the pistol. That won't happen, especially in RPGs where people enjoy finding the best builds and especially in a multiplayer environment where competition is a huge motivation. If the pistol was just a less advanced version of the super cool super powerful gun, you could put it in, it would most likely be useless, but it wouldn't be costly. Unfortunately that is not the case and making the pistol here is making your design extremely complex because it uses a completely different system.   Regarding vocabulary, you are not making the design and the design documents for players, you are making them for yourself and for other game designers or programmers, so it only makes sense to use a vocabulary that makes sense to game designers and programmers, especially if you want to ask for their opinion and you want them to understand your design. Then you can coat that in lore-friendly, player-friendly vocabulary once it's done. Just make the distinction clear, it's not making things more complicated, on the contrary it makes your design a lot clearer and a lot easier to understand. Don't call objects "particles" in your design explanation, talk about objects and then add that in the game you will refer to those as "particles" or "elements".   I still don't think you understand the object/attribute thing. You keep talking about "having to do those one-by-one as opposed to making common rules", that makes no sense to me. All the object types in your game you will need to do one-by-one, if you make a fire object you will have to specify what are its attributes, what are the rules it follows, what makes that object different from a water object. You can make common rules like gravity, but those are just parameters shared by all your objects. In the end you still need to specify that a water object is heavier than an air object otherwise gravity doesn't quite make sense. You still need to give each object a specific model in the game and specific properties otherwise all your objects are identical. It's not something that is different from your mechanic, it's not something that is like your mechanic, it's just how games work. No matter the mechanic you are making you are going to need to do it that way and so your design should reflect that technical limitation. Unless you are planning on inventing a new coding method. If you don't believe me, try to explain how you can make a certain object in your game without using that system and you will see that it's impossible.   When I'm talking about defining a parameter I don't mean that the player should type in code. It can be a graphic interface, but it's still about defining parameters. You are just using a different interface. I feel like you think design should be completely separate from implementation and that merely mentioning anything related to coding is wrong. If the player is not defining parameters, there is no customization possible by definition. Obviously you want to make it more appealing than just a console and graphic UI are pretty much the standard, but that is irrelevant. Just say that you are allowing the player to define parameters through a graph editor like interface. Whether I'm using my hands or a fork to eat, I'm still eating. I basically talked about "eating" and you said "No, I don't want players to eat, I want them to eat with a fork".   I understand that "small", "medium" or "large" is not what you want which is why I said that you needed sliders or an equivalent, since sliders are the kind of tools allowing people to chose from a greater range of customization options. And I also understand that Lego-style constructors is not what you want which is why I'm asking you again : do you really want physical skills ? Your physical constructor is very much a lego-style one. If you really don't want that in your game, why are you pushing to have it in your game even though it's unnecessary ? Once again you should really focus on the magic sandbox spell crafting system and not try to fit everything in that system. "You can't set the size of the fireball but you can choose how much particles to use", you realize that is the exact same thing ? The only difference is the interface : instead of typing in 5 or setting a slider to 5, you are selecting 5 particles. Also how does that work ? You are not crafting the skills in real time so how do you handle the different situations ? Are you crafting a skill that can use a variable amount of particles and it's just about selecting them in real time in the environment ? Or are you crafting a skill that can only be used if there is the right amount of particles available at that moment ? In both cases you would need to set the parameter "number of particles" or "size and shape of the selecting tool". That is what sliders are for (or any equivalent tool that allows you to easily select a value from a large range).   There is no point at which tech design is irrelevant. The sooner you consider tech design, the easier it will be to design and implement all the features you want. It's the house metaphor again : if you design your house without loadbearing walls, it can't work, so you will need to change your design at some point to include loadbearing walls. If you decide to ignore that fact and design freely without having those considerations, you will end up scrapping most of the work you did and having wasted your time and starting again with tech design in mind this time.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!