-
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
Incline SHELTER update thread
- Thread starter shihonage
- Start date
poocolator
Erudite
Kosmonaut said::Dshihonage said:Unradscorpion said:
Unradscorpion
Arbiter
- Joined
- May 19, 2008
- Messages
- 1,488
What have I done
I'm still finishing the encounter management system. Right now you have a certain fixed chance to have an encounter once in 8 seconds of MOVEMENT.
If this occurs, you now have "OUTDOORSMAN skill %" chance of canceling the encounter, as if it was never triggered in the first place.
Then, an encounter gets chosen from the large circles that happen to overlap where Player is standing, based on their "probability weight".
I've also started a "Shelter calculations" document as not to get lost in this type of information.
More work should be done this week.
If this occurs, you now have "OUTDOORSMAN skill %" chance of canceling the encounter, as if it was never triggered in the first place.
Then, an encounter gets chosen from the large circles that happen to overlap where Player is standing, based on their "probability weight".
I've also started a "Shelter calculations" document as not to get lost in this type of information.
More work should be done this week.
Good point. I'll take it out.
eklektyk
Erudite
progress is always welcome
keep up good work
keep up good work
Proper encounter handling is now complete.
Of course, if I didn't have a computer job and dry eye syndrome, this would've been finished 3 weeks ago. I always feel my eyes "battery" and how much "text reading tolerance" I have left at any given moment. I wish I could get an e-paper screen just for coding.
Anyway...
The new encounter system was lacking two things:
1) encounter "big map" radius management/selection (completed a week earlier)
2) deleting assets after you exit the encounter
2) proved to be more of a problem than initially anticipated. Deleting "encounter people" and "encounter objects (like shelves)" was easy - just cutting off the tail of the arrays containing them, because the encounter always added them at the end. Voila. That took about 7% of my time.
The other 93% was taken by ITEMS. I couldn't just do the same with items. Picture this:
Player enters encounter.
Two NPCs are spawned.
Player kills them, and takes ONE pistol from their corpses.
Player exits encounter.
Item array is shortened to previous size.
Player discovers that his pistol has vanished, because it was part of "encounter items", and the inventory slot references NOTHING.
So I put a tracker on each item, to be able to see which person it belongs to. With this knowledge, I could go through "encounter items" when encounter is exited, and delete those that DO NOT BELONG TO A PERSON (or corpse) THAT EXISTS.
This presented challenges, as the item equipment&generation routines couldn't discern between inventory of objects(shelves,etc) and NPCs, and also they didn't return anything if the equip action failed (as it was previously considered a non-critical, quit-and-whatever, error), so a new "datapath" had to be laid through these routines.
Then I realized that item deletion wasn't actually implemented. To do it the traditional way, by shifting the array by one element onto their former space, would require me to go through each container and person and reindex references in their entire inventory for each single item deletion.
This broke my brain for a while, until I realized that there is a simpler approach - just "zero out" the item, and modify the AddItemToGame() function so that it doesn't append new items at the end of array. First, it scans the entire item list for a "zeroed out" item, and sees if the new item can take that spot.
And so, finally, it works.
Goodbye, encounter system. Hello, random new task which is not yet chosen out of many.
Of course, if I didn't have a computer job and dry eye syndrome, this would've been finished 3 weeks ago. I always feel my eyes "battery" and how much "text reading tolerance" I have left at any given moment. I wish I could get an e-paper screen just for coding.
Anyway...
The new encounter system was lacking two things:
1) encounter "big map" radius management/selection (completed a week earlier)
2) deleting assets after you exit the encounter
2) proved to be more of a problem than initially anticipated. Deleting "encounter people" and "encounter objects (like shelves)" was easy - just cutting off the tail of the arrays containing them, because the encounter always added them at the end. Voila. That took about 7% of my time.
The other 93% was taken by ITEMS. I couldn't just do the same with items. Picture this:
Player enters encounter.
Two NPCs are spawned.
Player kills them, and takes ONE pistol from their corpses.
Player exits encounter.
Item array is shortened to previous size.
Player discovers that his pistol has vanished, because it was part of "encounter items", and the inventory slot references NOTHING.
So I put a tracker on each item, to be able to see which person it belongs to. With this knowledge, I could go through "encounter items" when encounter is exited, and delete those that DO NOT BELONG TO A PERSON (or corpse) THAT EXISTS.
This presented challenges, as the item equipment&generation routines couldn't discern between inventory of objects(shelves,etc) and NPCs, and also they didn't return anything if the equip action failed (as it was previously considered a non-critical, quit-and-whatever, error), so a new "datapath" had to be laid through these routines.
Then I realized that item deletion wasn't actually implemented. To do it the traditional way, by shifting the array by one element onto their former space, would require me to go through each container and person and reindex references in their entire inventory for each single item deletion.
This broke my brain for a while, until I realized that there is a simpler approach - just "zero out" the item, and modify the AddItemToGame() function so that it doesn't append new items at the end of array. First, it scans the entire item list for a "zeroed out" item, and sees if the new item can take that spot.
And so, finally, it works.
Goodbye, encounter system. Hello, random new task which is not yet chosen out of many.
BethesdaLove
Arbiter
- Joined
- Aug 7, 2008
- Messages
- 1,998
I don't want to sound negative but I cant help myself.
You guys will have to do ALL the sprites for the game...
Multidirectional character animation sprites... Oh god...
My prayers are with you.
You guys will have to do ALL the sprites for the game...
Multidirectional character animation sprites... Oh god...
My prayers are with you.
A helpful guy on NMA pointed us toward SPRITEFORGE which looks awesome.
But thanks for the prayers
But thanks for the prayers
shihonage, don't you have an entity manager or something like that? You're practically managing entities manually by manipulating their data storage rather than abstracting it completely, which I believe to be a much easier way to handle it.
If you have an entity manager, all you need to do is to reference each instance of an object with its ID, use a hash table or a dictionary to keep track of said ID, and then have the manager handle the add/delete routine itself. This way, you can plug in a memory watcher or an auditor to the manager without needing to touch code anywhere else.
Of all places in the system, entity management is probably the one that makes most sense to encapsulate. Heck, I spent the first 2 weeks of my development just to get the manager to work, before any other parts of the engine had been written at all.
As for the item location thing, why not just add a flag to the entity that says where the item is, and when you iterate through the entity array, just have the renderer check if the item exists in the current view before adding it to the render queue?
Right now the way you do it seem to be a little hack-ish.
If you have an entity manager, all you need to do is to reference each instance of an object with its ID, use a hash table or a dictionary to keep track of said ID, and then have the manager handle the add/delete routine itself. This way, you can plug in a memory watcher or an auditor to the manager without needing to touch code anywhere else.
Of all places in the system, entity management is probably the one that makes most sense to encapsulate. Heck, I spent the first 2 weeks of my development just to get the manager to work, before any other parts of the engine had been written at all.
As for the item location thing, why not just add a flag to the entity that says where the item is, and when you iterate through the entity array, just have the renderer check if the item exists in the current view before adding it to the render queue?
Right now the way you do it seem to be a little hack-ish.
Yar, unlike many people, I don't have stellar knowledge of OOP and related features. There are obviously more elegant ways to deal with this, and I would use some of them if I started the project from scratch. Alas, it evolved from codebase initiated in January 2000.
As for render queue, I don't know what you're referring to. None of this was related to the renderer.
As for render queue, I don't know what you're referring to. None of this was related to the renderer.
shihonage said:
About the render queue, what I meant was, it's best to separate logical data from presentation data. Your entity manager is logical data, while the sprites that represents your entities are presentation data.
What you can do is maintain logical data (position, location, stats, etc) with a manager and then maintain your presentation data (sprite instance, animation state, z-order, etc) with another, and then have your presentation manager (renderer) render the scene according to what the entity manager dictates.
Well, at least that's what I do - I have a render manager (with a factory) and an entity manager (with its own factory too), and the render manager is the one that polls the entity manager to find out what to render - thus the render queue.
You can accomplish all these with structural programming too - it'll just be less organized but the code should theoretically be slightly faster.
I do know what a render queue is, and my Think() and Render() parts are separate, though I've no doubt your approach is more organized.
I said "I don't know what you're referring to" because you were solving some kind of renderer-related problem that I don't actually have.
I said "I don't know what you're referring to" because you were solving some kind of renderer-related problem that I don't actually have.
Haven't touched the renderer code for the past month.
This week I created 5 different iterations of document describing Shelter setting and game start. Simplifying. Distilling the setting&start to fit into 7 sentences.
It is hard to comprehend the iron grip that the game mechanics hold on the setting itself, until you work on these at the lowest level.
For instance, in Fallout, one of the first goals was to make the Player discover Shady Sands, seemingly on their own. Discovering things on your own is a vital part of feeling like an adventurer. How can you accomplish that without explicitly revealing the town on the map, and pulling back the curtain in the process?
The solution was interesting: reveal a DIFFERENT place on Player's map, and put Shady Sands between start area and THAT place. Seems basic, but it was necessary, and, as it seems, irreplaceable.
Such problems and solutions defined the majority of Fallout. Another example: there's a main quest, with a suitably "epic" goal. But just how urgent should it be?
Let's imagine for a moment that the very game area is crumbling due to massive earthquakes, and your goal is to stabilize the planet's core by launching a Subatomic Stabilizer Device(tm) into it.
While the planet around you is falling apart, does it really make any sense to go around killing Radscorpions or rescuing someone's daughter from the local hostiles?
This is why Fallout's threat was more subtle. Not all mutants were hostile. Some you could talk to (even The Master himself). Their threat was a slower, creeping one, and it wasn't out of intentions that were 100% evil in nature. The threat loomed on the horizon, instead of trampling over the Player's sensibilities with an overblown urgency.
On the other hand... in earlier documents, Shelter's "threat" was a totalitarian regime. Now, that may work in a movie like Equilibrium, but in a game, that is just too passive. The regime is always there. People have lived with it before your do-gooder quest, and they can continue to do so. It can't expand anymore than it already has... unless you strap on some convoluted catalyst on top of it.
In the Player, fighting against a faceless regime is more likely to generate apathy rather than interest.
This is why, in current iteration of Shelter document, the game's main threat is a takeover by robots. They mean well, but they go about it entirely the wrong way.
Note: this is not final
It is hard to comprehend the iron grip that the game mechanics hold on the setting itself, until you work on these at the lowest level.
For instance, in Fallout, one of the first goals was to make the Player discover Shady Sands, seemingly on their own. Discovering things on your own is a vital part of feeling like an adventurer. How can you accomplish that without explicitly revealing the town on the map, and pulling back the curtain in the process?
The solution was interesting: reveal a DIFFERENT place on Player's map, and put Shady Sands between start area and THAT place. Seems basic, but it was necessary, and, as it seems, irreplaceable.
Such problems and solutions defined the majority of Fallout. Another example: there's a main quest, with a suitably "epic" goal. But just how urgent should it be?
Let's imagine for a moment that the very game area is crumbling due to massive earthquakes, and your goal is to stabilize the planet's core by launching a Subatomic Stabilizer Device(tm) into it.
While the planet around you is falling apart, does it really make any sense to go around killing Radscorpions or rescuing someone's daughter from the local hostiles?
This is why Fallout's threat was more subtle. Not all mutants were hostile. Some you could talk to (even The Master himself). Their threat was a slower, creeping one, and it wasn't out of intentions that were 100% evil in nature. The threat loomed on the horizon, instead of trampling over the Player's sensibilities with an overblown urgency.
On the other hand... in earlier documents, Shelter's "threat" was a totalitarian regime. Now, that may work in a movie like Equilibrium, but in a game, that is just too passive. The regime is always there. People have lived with it before your do-gooder quest, and they can continue to do so. It can't expand anymore than it already has... unless you strap on some convoluted catalyst on top of it.
In the Player, fighting against a faceless regime is more likely to generate apathy rather than interest.
This is why, in current iteration of Shelter document, the game's main threat is a takeover by robots. They mean well, but they go about it entirely the wrong way.
Note: this is not final
oldmanpaco
Master of Siestas
The problem with robots is they lack human emotion. Robots can generate fear but not empathy. The best enemies are ones you can relate too. The Master was trying to save humanity, Irinicus was trying to regain his soul, ect.
Of course you can circumvent this many, many ways - Mad scientist has downloaded his brain, robots have 'evolved', robots are simply following direction from misguided long dead creators (SF1).
But what do I know.
Of course you can circumvent this many, many ways - Mad scientist has downloaded his brain, robots have 'evolved', robots are simply following direction from misguided long dead creators (SF1).
But what do I know.
As someone just pointed out on NMA, robots are actually a lamer idea than the previous totalitarian regime idea, which I actually spent a lot of time and "discarded ideas" on. I even had detailed chain quests about freeing people from prison and lab experiments, in one of the old documents...
So many freaking documents...
Fuck robots, I'm going back to the regime.
So many freaking documents...
Fuck robots, I'm going back to the regime.
eklektyk
Erudite
You can still use robots and those quest
as a side/secondary quests/missions some minor yet persistent low level threat to some vilage/traveling merchant
it can still work albeit on a much smaller scale
my 5 cents
as a side/secondary quests/missions some minor yet persistent low level threat to some vilage/traveling merchant
it can still work albeit on a much smaller scale
my 5 cents
Dear Reader,
This was the least productive week ever. Hardly anything was done whatsoever. I could go on about just how little was done, or why, but I won't.
This was the least productive week ever. Hardly anything was done whatsoever. I could go on about just how little was done, or why, but I won't.
I made the new HUD optional so that Shelter takes up less screen space in a window for development purposes...
Other than that and a few internal tweaks, nothing.
In the past two weeks I've been given two projects to write in a horrendous language called PERL. I just handed in the first one to my manager, for which no doubt I'll receive a beating tomorrow during code review.
Shelter is written in C (core game), Pascal (dialogue/quest compiler), and SSL (Shelter Scripting Language, which makes for most of the active content).
I have decades of experience in building complex things, an abstract skill that has little to do with programming languages, yet lack of which makes projects of this magnitude fail.
I am not one of those "programmer" types. I don't make beautiful code, and I can't hold 5 languages in my head. I can barely hold ONE at a time, and it takes me effort to switch.
Being forced to work with PERL pretty much renders me 98% useless when I come home and try to work on my so-called "hobby".
A "hobby". What a riot. Normal people have hobbies. Y'know, collecting stamps, or kicking homeless into traffic.
Shelter is far beyond a "hobby". No sane person would keep at it. It is an obsession. I debug parts of it in my sleep.
Other than that and a few internal tweaks, nothing.
In the past two weeks I've been given two projects to write in a horrendous language called PERL. I just handed in the first one to my manager, for which no doubt I'll receive a beating tomorrow during code review.
Shelter is written in C (core game), Pascal (dialogue/quest compiler), and SSL (Shelter Scripting Language, which makes for most of the active content).
I have decades of experience in building complex things, an abstract skill that has little to do with programming languages, yet lack of which makes projects of this magnitude fail.
I am not one of those "programmer" types. I don't make beautiful code, and I can't hold 5 languages in my head. I can barely hold ONE at a time, and it takes me effort to switch.
Being forced to work with PERL pretty much renders me 98% useless when I come home and try to work on my so-called "hobby".
A "hobby". What a riot. Normal people have hobbies. Y'know, collecting stamps, or kicking homeless into traffic.
Shelter is far beyond a "hobby". No sane person would keep at it. It is an obsession. I debug parts of it in my sleep.
I hear ya.
Right now I'm skipping between 3 languages: PHP (with HTML, CSS and JS thrown in the mix) for my work, Python for my roguelike, and C++ for my game engine. Even after years of being trained to skip on languages (started with C++, move to Java, then to Actionscript, back to Java, on to Javascript, and finally to PHP), I still rely heavily on short 'refresher cheat sheets' that I keep around for each language just in case I need to dive back into one of them one day for some project.
You're an architect type I guess, for having your brain fit in more comfortably with the big picture.
Right now I'm skipping between 3 languages: PHP (with HTML, CSS and JS thrown in the mix) for my work, Python for my roguelike, and C++ for my game engine. Even after years of being trained to skip on languages (started with C++, move to Java, then to Actionscript, back to Java, on to Javascript, and finally to PHP), I still rely heavily on short 'refresher cheat sheets' that I keep around for each language just in case I need to dive back into one of them one day for some project.
You're an architect type I guess, for having your brain fit in more comfortably with the big picture.
As an Amazon Associate, rpgcodex.net earns from qualifying purchases.