Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Milcho

Member Since 29 Jan 2011
Offline Last Active Oct 22 2014 06:55 PM

#5091273 Would a trade system work?

Posted by Milcho on 03 September 2013 - 06:26 AM


Let the people choose the "currency" such as the wastelanders in Fallout used caps as a store of value.

 

This actually reminds me of what happened in Guild Wars. Guild Wars had gold (only, no silver/copper), and you were limited to carrying 100k gold on any one character (bank stored way more I think).

 

The thing is, some items that were being traded started becoming more valuable than the 100k gold limit on a character. Since no one wants to do a trade in multiple parts, because of how insecure that is, people started using a very rare crafting item that was dropped in a specific area as currency replacement - the item was Glob of Ectoplasm.

 

Globs had variable price, even at NPC traders (the prices varied there based on supply/demand), but even so, people took to using them as substitute for large transactions of currency, since the supply of ectoplasm was always strictly limited (it was hard to farm), and also since it was a consumable, valuable item - so that the market wouldn't be overrun with it as a supply.

 

I'm pretty sure that mmo economics is a field of its own, since it can become incredibly complex.. but having a rare, limited in supply item could just lead to people using it as currency naturally (kind of what happened with gold in real life I suppose)




#5090124 Would a trade system work?

Posted by Milcho on 29 August 2013 - 09:47 AM

Didn't see it mentioned, but Path of Exile has a no gold trade system, and is an mmo (with instanced combat areas, but still an mmo).

The way it works there (from the stuff I've seen), is that when you 'sell' items to a trader you get scroll and/or stone fragments. Enough of these (10 i think) automatically make a stone or scroll. The stones/scrolls are also used to 'buy' items. Trading between players is also possible and it just comes down to bargaining.

 

The key why that works though, I think, is that the stones/scrolls are one time use items that are quite commonly used in game (such as identifying items, or augmenting items) - and thus gives them value without flooding the market with them.




#5088114 Non-combat space exploration idea, feedback welcomed

Posted by Milcho on 22 August 2013 - 09:47 AM


I'm curious whether you feel it is useful to have loss conditions at all in a non-combat exploration game with no external risks?

 

Well, among one of the many games that inspired me is a game called Motherload, a flash based 2d grid-digger game. It was fairly popular, and there's even a greenlight version being made. The game had you digging for different minerals, then coming back to the top to sell them. It had cargo size limits, as well as limited fuel - and essentially had you die when you ran out of fuel. Despite that, it was still interesting, and kind of addictive to push yourself to go digging deeper for better materials. It's one of the feelings I was hoping to re-create (only in space). 

 

The idea of just getting a high score as an ultimate goal doesn't have much of an appeal to me, and neither does time-limited exploration. I have some vague ideas about other possible end-game goals - possibly involving unique missions and solving some mystery - but I'm holding off on that until I get the basic gameplay settled.




#5088090 Non-combat space exploration idea, feedback welcomed

Posted by Milcho on 22 August 2013 - 08:06 AM

Thanks for the input guys. I now have a fairly good idea of how buying new ships can affect gameplay:
 
List of ship features, dependent on ship size and specialization. Larger ships improve on all aspects, but different varieties specialize in one (or two) areas.
  • Crew Capacity: maximum number of crew members you can hire for this ship
  • Optimal Crew: A range given for each ship's optimal number of crew members. If outside the range, crew receive a morale penalty (i.e understaffed or crowded)
  • Cargo Space: measured in cubic meters - how much cargo you can carry on the ship, and all non-mounted equipment, including Rations, takes up cargo space.
  • Sensor Slots: how many sensors you can equip on this ship (excluding the default build in Directional Radiowave which comes standard with all)
  • Advanced Equipment Slot: Used for the Scientific Scanner and for the Ram Scoop.
  • Fuel Capacity: Something I overlooked. Chemical fuel is used as you free-fly around (only if you accelerate/decelerate), while Deuterium fuel would limit to how big of hops you can make between star systems
 
The mountable equipment on each ship:
  • Heat Sensors: require one free sensor slot
  • Planetary Sensors: require one free sensor slot
  • Scientific Sensors: require one free sensor slot - this only provides the location of spatial anomalies, not the ability to scan them (locations become an item and can be sold)
  • Scientific Scanner: requires one free Advanced Equipment Slot - provides the ability to scan spatial anomalies, requires Scientist to operate
  • Ram Scoop: requires one free Advanced Equipment Slot - if you fly though a Gas giant with this equipped, it replenishes your Deuterium fuel supply.
 
To give an idea of the scale I'm thinking of: starter ships would start with crew cap of 4, limited storage space (need to work out exact size), 1 sensor slots, little fuel capacity (also need to work out units) and no Advanced Equipment slots. There'll be a few starter ships to pick from, each giving a little bonus to a specific area - more crew, more fuel, more cargo or one more sensor slot. Same type of specialization would apply for later ships. The largest ship will have a crew cap of no more than 20. 
I'm also thinking of a couple of new crew roles to give a reason and a way to expand crew size:
  • Cook: If present on board, and you give more than 1 ration a day to your crew, gives a morale boost. Only one allowed on-board.
  • Xenobiologist: If present, you can send a simple exploration mission anywhere on a habitable world that has a small chance to refill your rations.



#5087574 Non-combat space exploration idea, feedback welcomed

Posted by Milcho on 20 August 2013 - 07:03 AM

I've been experimenting with this idea for a 2d top down space exploration and survival game, sort of rogue like. Feedback would be great - I'll try to point out things that I really need feedback on, but any is welcomed.

 

Some notes on small things, don't need any specific feedback, but just to give a better idea:

  1. 2D topdown view, with realistic space flight physics, barring gravity (I think it makes flight significantly more complex, but not more fun). All stellar objects (planets, moons, asteroids, stars) will be real sized. I've experimented to see if I can get it working, see this video (turn hd to see the stars in background)
  2. The 2D topdown view, and a simple solar system/galaxy map (for 'jumps' inside the system and between systems) are the only two views. No controlling crew, no other perspectives or models besides your ship and various other space objects. Crew and your character don't have any graphical design, but simply are a name and specialization + stats (base morale, hire price, salary/week that sort of thing). All interaction is done through text-based descriptions and player choices.

Some of the key gameplay ideas. I'm most interested in feedback on these:

  1. Interaction: Stopping over certain objects allows interaction and choices via a text menu (nothing fancy), and results/feedback is also given via text description. For example, stopping over ship debris allows options to scan or try to scavenge resources. Stopping over a city on a planet allows for trading (components, materials, rations), and for hiring new crew members. Further examples of interactive objects: space stations, derelict ships, asteroids, spacial anomalies, and terrestrial planets/moons
  2. Crew: You have a list of crew on your ship. Each crew member has a specialization that serves a purpose, either on ship, or on Missions (described below). Crew members also have morale (starting at random value) that takes penalties if you fail to pay their weekly salary, or if you have insufficient Rations. If a crew member's Morale gets low enough he/she leaves the ship.
    1. Pilot: needed to fly a ship. If his morale drops too low and he leaves, you are 'moved' to the last city/space station you vsited. 
    2. Commander: Increases survival odds of everyone if present in mission. Allows for 'Negotiate' option, if available on missions
    3. Engineer: allows repair of ship components whilst in space (if components are present). Guarantees safe recovery of   components if present on Missions.
    4. Scientist: Can turn Raw Data (obtained from scanning spatial anomalies) into Research Notes. Can research Unknown Objects (recovered from certain missions) and turn them into specific and valuable objects (to sell or to use). Guarantees safe recovery of Unknown Objects if present on Mission.
    5. Mercenary: Allows for 'Attack' option if present on Missions.
    6. Doctor: Can heal Badly Injured crew whilst in space. Reduces odds of any crew member dying if he's present on a Mission.
    7. Companion: Adds to crew morale, does not require a salary, only one per ship. Adds additional trade options in certain space stations/cities. Your character must have a minimum reputation before being able to ask a companion to join the crew, and have a minimum number of crew members to keep her on board.
  3. Your character: Your character is like all other crew - he has a specialization that you can pick at start. The only difference is that your character is not affected by Morale, and thus will never leave. However your character is affected by rations, and if he hasn't eaten anything in some time, he dies, resulting in Game Over.
  4. Survival: You must provide rations for your crew each day. You can select number of rations to per day (0,1,2,3 or 4) - and each provides a different Morale boost/loss to each crew. You must pay weekly salary of your crew (on individual crew basis, in full or none) - paying/not paying has a Morale boost/loss effect on each crew.
    Two types of fuel must be resupplied: Chemical fuel for free space flight, and Deuterium for FTL jumps.
    In addition to that, your Ship has various Equipment, some optional, other required to survive. Each equipment piece has a durability value that has a chance of decreasing at the end of each day. Failing to repair vital equipment results in death. (permanent). Repairing equipment can be done at a City or Space station for currency, or may be done anywhere for free, if you have an Engineer and if the needed components are available in ship inventory.
  5. Exploration: Procedurally generated systems, each containing random features. Various ship Equipment is used to explore and discover different objects and missions. Optional equipment must be purchased at Cities or Space Stations.
    1. Radio sensors: Always present, can detect directional radio transmissions (i.e. from Derelict Ships, or Crash Sites) inside a single Star System.
    2. Heat Sensors: Optional, can detect Ship Debris inside a single Star System. 
    3. Planetary Sensors: Can detect possible locations of Settlements and Ruins when near a Planet.
    4. Scientific Sensors: Can detect the presence of spatial anomalies inside a single Star System.
  6. Missions: Most interactive objects (except Cities and Space Stations) provide some sort of scripted mission. Missions are displayed as text description only, i.e.: You click Explore when stopped over a Settlement, and you're provided with a short text intro to the settlement and the people. At this point various options may open up, depending on the scripting and crew present on the mission. If you have a Commander present, you may be given an option to Nagotiate. This will result in different events happening (all through text) than if you didn't have a Commander on the Mission. Other crew member types open up various other  options if present on the mission, with branching possible at every decision point, and different rewards (or problems, such as getting one of your crew injured or killed) arise depending on the branch taken. This all happens through text commands. Missions will have to be manually written based on type, and picked at random when a Star System is generated.

So, that's the concept, more or less. The main goals in the game are to survive, explore, and get rich. I've thought about possibly including big goals like buying a new ship, but I've yet to figure out what gameplay effect this may have, though it might be good to have big goals like that.

 

I'm interested in whether you think this idea sounds interesting - it's really a 2D space flying + text adventure mix. Any comments on the gameplay mechanics - i.e. are they clear, do they sound tedious, would they be interesting would be appreciated, but any other comments, suggestions, ideas or criticism are also welcome.




#5080388 Evolution

Posted by Milcho on 25 July 2013 - 04:02 AM


BTW, have any of you played Spore?

 

The idea you described is hundreds of times closer to actual evolution than Spore ever was. Spore had no evolution - you got to collect 'points' and 'body parts' from skeletons, then you could build your species in any way you wanted to. If you got the right parts, you could be a herbivore biped one generation, and then be a carnivore quadraped with two mouths and three eyes the next. 

 

There is no natural selection (especially since you controlled a single organism) and there are no environmental conditions to put pressure on you to design a certain way. 

It did make a semi-decent game, mostly because of the final stage - space exploration (if you ask me). 

 

 

But perhaps one thing you can take away, to involve the player more is to do what Spore did, and put the player in the shoes of a single character.

 

Basically, have some system with enough complexity to simulate evolutionary pressure and mutation, but force the player to try and survive from a single creature perspective. Each time the player creature dies, make the player pick one of the creatures from the next generation, creatures that were generated through the game's evolution mechanics. If you make the environmental conditions vary randomly, the player will be forced to try and survive with whatever creature he picked, whether that creatures mutations favor the conditions or not. The score can simply compare how the player's creature is doing vs the other creatures from that generation (which the player didn't pick)

 

That's just a vague idea though, there's probably more ways you can implement it, but putting the player in a position where he has to anticipate a single, randomly generated, creature's survivability in future conditions sounds kind of interesting to me.




#5078944 Orbit (ellipse) collision detection between many many objects

Posted by Milcho on 19 July 2013 - 09:54 AM

As apatriarca said, two spheres may collide even if their orbits don't intersect (and in reality orbits in 3d, which are just lines, will rarely intersect, unless you impose restriction of being on the same plane).

 

But you can do a sort of hybrid approach with the region idea you mentioned originally. There's two ways I can think of, off the top of my head, depending on how much data overhead you can afford.

 

One is to separate your space into an imaginary rectangular grid, where each cell is size NxNxN. Then, at startup, traverse the orbit of each sphere using equations for an ellipse, my suggestions is using parametric form). Each little jump you make along the ellipse (make sure jumps are of size N/2 at maximum), record which cell your ellipse passes through. Then, account for the radius of the sphere travelling along the ellipse, and record the other cells which your sphere will fall into, if it were at that position on its elliptical orbit.

 

This way, for each cell, you'll have a list of spheres that can possibly pass through that rectangular cell, and you only have to check for collision with those, making sure you don't repeat collision checks (so if you're on sphere A, and just checked if it collides with sphere B in that cell, don't bother checking if sphere B collides with sphere A). The problem with this is that it requires a lot of overhead, especially if you make your grid too small. And if you make your grid too large, you'll start having to go through a lot more checks - so there's a sweet spot depending on your setup.

 

 

Note: I just realized that the next method assumes all your ellipses have one common (or very nearly so) orbiting point, like planets around the sun, which may not be what you meant

Alternatively,  instead of making a rectangular grid, make spherical shells, of certain thickness (again, varied depending on your setup, and again having a sweet spot of being neither too thick, nor too thin). You can easily calculate the perihelion and aphelion of each elliptical orbit (and add/subtract the sphere's radius) so you will know which of these spherical shells your sphere can pass through. Then when performing collision for a sphere check which other spheres pass through the same spherical shell in which your sphere currently is. 

 

The upside is that you'll need a lot less data storage here, than in the cubical grid method. The downside, as I mentioned in the note, is that this will really only work well when all your elliptical orbits have a common, or nearly common, orbiting point. 




#5078579 Death and Mining in a 2D Top Down RPG

Posted by Milcho on 17 July 2013 - 04:33 PM


I could have an actual family system where at any one time, you can take a family member and be them (only the adults), and be able to specialize their skills somewhat. A party system, where you can actively control a single person, and if they die, it's permanent. Thoughts? Or do I need to be more clear?

 

I think that makes sense. There was a system kind of like that in The Guild 2. There's a few questions to ask yourself: do you only control once character at a time, until he dies? Are you free to switch between characters of the family at any time? What do the characters you're not controlling do when you're not controlling them? I mean, these are all open questions, depending on how you want a game to feel, but a system like that can definitely work.

 

As for the caves, yeah, I think your idea of levels would work nicely. And making all rocks mine-able is good imo. Prospecting.. hmm, perhaps could give you a hint at where ore might be? At least, give you some sort of percentage overlay on the rocks. But yeah, that sounds kind of interesting too, and I can see it working.




#5078408 Death and Mining in a 2D Top Down RPG

Posted by Milcho on 17 July 2013 - 04:55 AM

There was a similar discussion about death recently, you can read some of the replies for death in that thread.

 

My personal favorites is what Servant said, or alternatively, having an inheritance system (most recently implemented in Rogue Legacy) - where your character really 'dies', but you continue to play with a descendant of your character. 

 

The descendant system also gives opportunity to make death be an actual threat without having a total wipe. For example, one way to implement it is to have everything your character carries drop to the ground, while stuff in a bank or house storage or anything similar, stays the same. This way once you get some good minerals/ores from mining deep in a cave, you have to escape alive in order to bring them back, or you'll need to go retrieve them with your next character.

 

Other than those two methods, any sort of resurrection requires some amounts of hand-waving and deity/magic intervention.

 

As for mining, I've never been a fan of straight up nodes, nor am I a fan of regenerating ores. In your cave, you could have 'rocky' tiles that can be mined for a chance to obtain ores. Doesn't mean that each tile will yield an ore, while some may strike rich, and give you a few at the same time. And as you said, the deeper you go into a cave,  the chance of getting better ores increases. If you can create fairly large caves, you'll never have to regenerate the ore randomly. To decrease travel time, you can add 'checkpoints' to the caves, so that once you reach a certain point, you can then go to and from the cave entrance straight to that point in the cave (sort of like "I've gotten here before, I'm know my character can make it there without trouble" thing). In a way simulating a mining tunnel system, since most serious mining in a realistic environment happens in deeper caves/holes.




#5075456 Should RPG mechanics/objects be mysterious or have easy/clear expanation?

Posted by Milcho on 05 July 2013 - 07:56 AM

I don't know if the majority of players prefer all mechanics to be visible, or for them to discover the effects/mechanics on their own. 

 

But I think there's no clear right or wrong. I think this is an important design decision that will give your game a different feel depending on how you chose. If you hide mechanics, you gotta make sure they're interesting and useful to discover (like ingredient properties in oblivion), and not just pointlessly hidden (like how the #$@! do I drop inventory items in Oblivion?)

 

I agree with Archbishop that a player shouldn't have to leave the game to find necessary information to play. But I don't think that means that you should clearly describe all mechanics. Again, depending on how you want your game to feel, you could hide stuff like effects at praying at alters or potions or scrolls.

 

But if you do, you can also prevent these from being clearly documented on some wiki by introducing a randomized element each time a game starts. So on one playthrough, red potions will heal you, while on another playthrough, red potions might curse you with blood curse and lower your hp. If you can mix and match elements with effects, you can keep the feeling of unknown danger present each playthrough, forcing players to go through discovering things on their own each time, making it an integral part of your game. This should render most outside documentation useless - but again, it will give your game a totally different feel.

 

Like I said - I think that there's no right choice here - but if you pick to hide mechanics, it makes discovery a gameplay element, so you should do your best to make sure its fun and has a purpose.




#5075253 Cost of area transitions

Posted by Milcho on 04 July 2013 - 08:53 AM

Obviously one cost is time. Lots of loading-screen-like transitions will force the player to spend a lot of time waiting around doing nothing, and probably getting bored. I can't tell you how annoyed I've been when I've had to exit/enter a building in a city in Skyrim twice in a row, spending nearly five minutes just because I forgot to leave some random item.  Something that should have taken me a minute tops, suddenly took about five times longer.

 

It's also quite immersion breaking if the player finds a way to overcome the invisible walls between zones, and find themselves in limbo. Not to mention that depending on how your gameplay works, it may get the player stuck forever in limbo, ruining all progress (this happened to me in Arkham City after having beat the whole campaign, thankfully, but still was annoying)

 

I've also disliked how some games allow you to be in a position to affect another area (say, on top of a wall above a battlefield), but you couldn't affect the other area simply because it was 'another area' and you had to go load into it before you could affect it.

 

There's other issues too if your game is multiplayer. For example, in EVE and its open pvp nature, having specific entrance/exit points in a system causes them to act as choke points for player killings, traps, etc. In EVE its more or less a game mechanic they've worked in, but it's something I've always hated.

 

The only time I've really seen player feedback for a game is in GW2. That game is very much divided into areas - and quite the opposite of what most games in its genre are doing. I've only seen a few people complaint about the area transitions, but most were ok with it, especially given that the areas are quite large. I imagine if the areas were smaller, it would be a lot more annoying to the player. Well, I've also seen some random feedback from people regarding the next gen consoles, and how they expect no loading areas. Not sure if it's a make-or-break feature, but it can hurt your game if done horribly wrong.

 

There's also technical difficulties involved in making area transitions. The most obvious one I can think of is AI. If you have any sort of AI, friendly or otherwise, and they have to move at some point - follow/attack the player - you must either write the AI with the ability to use the area transitions, or to give the player a possible exploit if the AI doesn't follow through area transitions. I've seen some pretty bad issues in TES games with AI using area transitions. They get stuck right before exiting, I have to re-enter and push them, or they enter an area before me, and when I enter only a second later, I find they've seemingly disappeared, having advanced much further than the second difference between them using the door and me using the door would allow.

 

I think as long as you make the areas large enough, minimize the loading times. make the separations as natural as possible, and don't divide areas that look like they should logistically be the same area, the area transitions aren't a major problem. To each his own, but if any of those things above stick out in a game, I often start disliking the area transitions.




#5074731 Input Required - Feudalism (game)

Posted by Milcho on 02 July 2013 - 07:41 AM


So, you mean not a city building but a village building?

 

When you said this, I thought of the Settlers VI. You can't say you're building a city there, as the population probably never goes above 500. Yet the game has surprising amount of depth. Hunter's huts to catch wild game, Butcher's shop to turn it into food. Then a soap-maker that uses the fat to produce soap for hygene. Woodcutter huts to provide wood, broom maker for more hygene. Farm for cows or sheep, cheese maker, banner maker (for citizen happiness), beekeeper huts, meadery, wheat fields, bread maker. On top of that, the way you earn gold is from taxes to the shops

 

The reason why you'd need more than one, at least in that game, is that each shop can produce limited output - i think up to 9 citizens can live off of one shop. But even with a hundred citizens, that means you need quite a few shops (of different variety - for example the breadmaker, sausge maker, smokehouse, cheesemaker all satisfy the 'hunger' need)

 

Actually that game sort of matches the original description in this thread, though its obviously not exactly the same. Still, I think it's something to learn from if making a village-building game.




#5074698 The purpose of crew when you fly the ship?

Posted by Milcho on 02 July 2013 - 04:53 AM

It's interesting to see this because I've been working on something very similar in concept. Mainly crew types and roles.

 

My approach is slightly different I suppose. I mean less Trek, and more Firefly you could say.

 

Some of the things I have written down, copied from my notes

 

  • Commander

    • Increases survivability odds for everyone on Missions

    • Can negotiate with Human Survivors or Tribes found on Missions

    • Provides small morale boost for all crew on ship
  • Pilot

    • Required to fly any Spaceship

  • Engineer

    • Can Repair ship components

    • Can safely recover Repair Parts while on Missions

  • Scientist

    • Can research Unknown Objects and analyze Recovered Data

    • Can safely recover Research Data while on Missions

  • Mercenary

    • Increases odds to kill hostile Humans on missions

  • Doctor

    • Can heal Badly Injured crew on ship

    • Greatly reduces odds of any crew Dying while on Missions (leaving them Critically Wounded - unable to fight or function, but not dead, instead)

  • Companion (female only)

    • Gives crew morale on board a ship

    • Can find new Contacts in Cities

    • Does not require you to pay her a Salary

 

I like your idea for cook, as something else that can raise crew morale. My idea was that each crew member has some base morale level that's affected by things like not getting enough rations each day, not being paid last month, having another crew member die on a mission, or the above listed boosts from other crew. The idea was that once morale drops low enough, that crew member becomes unusable, and if morale drops even lower they will leave your ship.

 

Still lots of things to be covered, and I have more notes working on this, but this part seemed relevant to your post. Er, as a small note though, I list things like 'survival odds on missions' because I envisioned missions as sort of just text-based, where you click "send team" and are given a report of what's going on, with maybe occasionally having a decision - and not actually playing out the mission with the crew. (this is in the style of how you send Commandos to board other ships in Nexus: The Jupiter Incident)




#5074694 Reviving/resurrecting players in semi-realistic RPG?

Posted by Milcho on 02 July 2013 - 04:36 AM

One way you could explain 'resurrection' in a non-tech, non-magical way is to change the way being 'killed' is treated. Often times people can be knocked unconscious,  badly wounded, or just generally appear to be dead, while still only being in a near-death state. 

 

Once you can explain it like that, you could, lore-wise, say that some random passer by has found you and either helped you heal, or returned you to a hospital or something. This seems like a reasonable explanation for outdoors areas, though not necessarily for the Dungeon Of Ultimate Doom (or other places like that) where random passers by are unlikely. But that could be just another way to make your dungeons unique and make them seem like an actual threat, like some place that truly is dangerous for the player, where they can die permanently.

 

Of course, always being badly wounded or having a near-death experience might also seem unrealistic, so you could give a small chance for perma-death every time you're 'killed'. You could make it dependent on how often the player dies - i.e. if they haven't died in over an hour, there's 1% chance of perma-death, but if they die twice in ten minutes, there's a 50% chance of perma-death on that second 'death'.




#5049891 rpg: what's left once you're high level?

Posted by Milcho on 04 April 2013 - 05:40 AM

This probably isn't what you were aiming for, but it came to mind right after reading the title:

 

If you start off designing an RPG without levels, you may find it easier to give the player things to do after the end of the game.

The typical goal of a lot of RPGs (aside from completing story) is to undertake tasks to level up continuously. Since most rpgs have some sort of a level limit, this goal eventually runs dry, leaving the player with a feeling of lack of progress in doing much else. 

My opinion on the matter is that if you don't make leveling up a goal from the start, you may be able to acclimate the player to getting the sense of progress from other accomplishments, thus leaving more options for end game.

 

Not sure if any of this will fit with your setting, but some of my ideas on this have been:

 

1 Allow player to receive training from hard to find and difficult to reach people/locations, to permanently improve their stats or combat or learn a new skill. You can then add more and more such locations to further challenge players to improve their characters by seeking out such things. Challenges could be more than just 'fight x number of y' - but things like jumping puzzles, environmental hazards (snowstorms that can freeze you, random magma flows) or a combination of the above.

 

2. Make exploration interesting in more than just a visual way. Give the player some basic (even if not fully complete) ability to interact with the environment. For example being able to 'search' through at the current player's location in the water bed in a lake or river for a chance to find something useful - where certain areas are more likely to yield a useful resource (gold, lost items that could be returned, or.. even just  a sharpened obsidian shard that can be used to fashion a new spear) Mix in some random negative elements like searching in some areas can result in being bitten by an unknown insect and have hazardous effects

 

3. If you have a story with a clear end, make some, even trivial, post-story-end follow up quests that only trigger once main story is complete. Like if you happen to rescue some minor npc along the story, make them become available at some location (though not directly indicated to player that they are, meaning player would have to visit them at their own initiative, not due to quest log of 'Visit npcX') to talk to, whereupon they give you something unique. Bonus points if you tie that in with above idea for distant location training of skills.

 

4. Make a system that allows open ended expansion of skills. I mean, a lot of games have very clearly defined skill trees or something akin to that, where you know in advance how many points and skills you can obtain. It makes games very calculable in my opinion, and grouped with a leveling system with a potential max level, gives a very clear idea of "I've beat this game" feeling to players. If you simply had some list of skills that didn't give indication of whether or not you could learn more (couple with idea 1 above), a player may not always be 100% sure if he's truly discovered/completed everything.

 

Hmm, anyway, hope this didn't get horribly off topic.






PARTNERS