No but if you know any cheap snipers let me know 
-
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
- Joined
- Nov 4, 2007
- Messages
- 14,991
Unless the pests really pissed you off.
Saving and Loading is now REALLY complete. I ran into logistic issues with reinitialization. For instance, each town has "startup" commands in addition to a looping script. Should these commands be re-executed after a game is loaded? I discovered that the answer is "no". There were other issues, of course, some of which were solved properly, and some were solved by imposing limitations.
Currently, you can LOAD from anywhere, but you can SAVE only when in a non-encounter area, and while not engaged in dialogue.
In unrelated news, Age of Decadence team posted an interesting screenshot of their dialogue editor (http://www.irontowerstudio.com/forum/in ... l#msg54807), so I decided to post a screenshot of my dialogue+quest compiler as well.
And here's weekly screenshot of Shelter... in editor mode.
Meanwhile I am back to implementing skeletal game flow. Stay tuned.
Currently, you can LOAD from anywhere, but you can SAVE only when in a non-encounter area, and while not engaged in dialogue.
In unrelated news, Age of Decadence team posted an interesting screenshot of their dialogue editor (http://www.irontowerstudio.com/forum/in ... l#msg54807), so I decided to post a screenshot of my dialogue+quest compiler as well.
And here's weekly screenshot of Shelter... in editor mode.
Meanwhile I am back to implementing skeletal game flow. Stay tuned.
Yeah, their visual "unfolding" approach may be easier to work with, but my tag-based approach allows for "hanging stuff under various branches", i.e. reusing content.
I.E. if you ask someone about the woods, you may get an option to ask about BEARS. But then if you ask them about what animals they eat, logically, the BEARS entry could still apply. So this approach allows to just "summon it by tag" instead of putting a duplicate.
I wish I could make mine more accessible, though, but maybe in the next, uh, project.
I.E. if you ask someone about the woods, you may get an option to ask about BEARS. But then if you ask them about what animals they eat, logically, the BEARS entry could still apply. So this approach allows to just "summon it by tag" instead of putting a duplicate.
I wish I could make mine more accessible, though, but maybe in the next, uh, project.
I'm making lemons out of lemonade - trying to integrate knowledge from book on programming theory my manager has been force-feeding me, with Shelter project. Surprisingly, I learned that a lot of advice the authors give has already been implemented in Shelter.
It has an external scripting language - check.
It has a SCRIPT GENERATOR for that language - check.
It has a console - check.
It avoids having duplicate documentation instances that need to be kept in sync - check. Zorlag (dialogue editor) generates people's location, place description and quest reports automatically on compile.
It has regression testing - check. The prison area designed a while back, was and still is being used as a ground for checking how all of the features work together. When new game save/load routines started breaking shit, it again became relevant and invaluable. It tests dialogue scripting, stat checks, combat (lethal and non-lethal), object interaction, inventory/item management.
A very important problem that I'm aware of as well, but unable to fix, is the "broken window syndrome". Building the game has been an evolving process. Initially it all started clean. Think() here, Render() there, handle movement here, items there...
But since the project is new to me, eventually ugly pieces started appearing here and there. Broken windows. Many of them have been "patched up" instead of being fixed elegantly.
There are reasons for this:
1) preceding framework limits how much I can do without breaking more shit
2) with the constantly interrupted development, I keep forgetting how parts of the project work, and am
very prone to breaking shit
This is why this week I also implemented a source control system, so I could always revert to a time when shit wasn't broken.
The "broken window syndrome" has buried other projects at much earlier stages, but Shelter is like a ghost train, relentlessly moving forward in a dark cloud of smoke, leaving behind shattered pieces of glass and melted rails.
Yet as much as it pains me, I may need to redo combat AI and UI management. Over Shelter's evolution, they have grown, a patch over a patch over a patch, into something incomprehensible, and now I have a much clearer vision of what they should, and should not, do.
But I am also working on content... at a snail's pace, as usual. If someone can figure a way to make an e-ink screen, like Kindle DX, to view C++ code (and let me use a normal keyboard), let me know. My dry eye syndrome (DES) is not getting any better.
Weekly screenshot:
It has an external scripting language - check.
It has a SCRIPT GENERATOR for that language - check.
It has a console - check.
It avoids having duplicate documentation instances that need to be kept in sync - check. Zorlag (dialogue editor) generates people's location, place description and quest reports automatically on compile.
It has regression testing - check. The prison area designed a while back, was and still is being used as a ground for checking how all of the features work together. When new game save/load routines started breaking shit, it again became relevant and invaluable. It tests dialogue scripting, stat checks, combat (lethal and non-lethal), object interaction, inventory/item management.
A very important problem that I'm aware of as well, but unable to fix, is the "broken window syndrome". Building the game has been an evolving process. Initially it all started clean. Think() here, Render() there, handle movement here, items there...
But since the project is new to me, eventually ugly pieces started appearing here and there. Broken windows. Many of them have been "patched up" instead of being fixed elegantly.
There are reasons for this:
1) preceding framework limits how much I can do without breaking more shit
2) with the constantly interrupted development, I keep forgetting how parts of the project work, and am
very prone to breaking shit
This is why this week I also implemented a source control system, so I could always revert to a time when shit wasn't broken.
The "broken window syndrome" has buried other projects at much earlier stages, but Shelter is like a ghost train, relentlessly moving forward in a dark cloud of smoke, leaving behind shattered pieces of glass and melted rails.
Yet as much as it pains me, I may need to redo combat AI and UI management. Over Shelter's evolution, they have grown, a patch over a patch over a patch, into something incomprehensible, and now I have a much clearer vision of what they should, and should not, do.
But I am also working on content... at a snail's pace, as usual. If someone can figure a way to make an e-ink screen, like Kindle DX, to view C++ code (and let me use a normal keyboard), let me know. My dry eye syndrome (DES) is not getting any better.
Weekly screenshot:
Thanks 
My "revision control system" consisted of making archives of "keypoint freezes".
My "revision control system" consisted of making archives of "keypoint freezes".
Kosmonaut said:
I don't work with other programmers, but I adopted Mercurial because my company is moving toward it. You know, lemons out of lemonade and all.
Of course, keeping this mindset from the beginning, I should've written the entire game in PERL. But then by now I would've probably jumped off a bridge.
Mercurial is good enough.
shihonage, I think you should spend a week or so to refactor the entire code base. This is what programmers usually do when they embark on foreign territory: they write hack code first to get something up, and then with that experience they rewrite the entire engine into something more organized.
I did at least one complete rewrite when I wrote GORE for InfestedRL, and trust me, the extra time spent is totally worth it.
shihonage, I think you should spend a week or so to refactor the entire code base. This is what programmers usually do when they embark on foreign territory: they write hack code first to get something up, and then with that experience they rewrite the entire engine into something more organized.
I did at least one complete rewrite when I wrote GORE for InfestedRL, and trust me, the extra time spent is totally worth it.
Refactoring (essentially, rewriting) the entire game would take me, I estimate, at least 2 months, and that is if I was unemployed, and was able to dedicate 4 hours a day just to that task.
Remember, that everything you take for granted, code had to be written to do, and chances are, it was more complex than it seemed. This realization does not quite fully dawn until you're actually in the middle of the project.
At this point I intend to only do selective refactoring (as mentioned above). Global refactoring may take place between Shelter and Shelter II: Empire Strikes Back.
Remember, that everything you take for granted, code had to be written to do, and chances are, it was more complex than it seemed. This realization does not quite fully dawn until you're actually in the middle of the project.
At this point I intend to only do selective refactoring (as mentioned above). Global refactoring may take place between Shelter and Shelter II: Empire Strikes Back.
Good point. Things can turn spaghetti real quick before you realize it.
BTW, I noticed some render inconsistencies in your screenshot, specifically on the gaps in near the southern wall. Is that intentional?
BTW, I noticed some render inconsistencies in your screenshot, specifically on the gaps in near the southern wall. Is that intentional?
- Joined
- Nov 4, 2007
- Messages
- 14,991
What can I say, Poland (as you already know) is not your run-of-the-mill country.soggie said:
soggie said:
That was the second map made for the game, and it went through at least two different map format conversions. The first map was in yet another format and did not survive.
In the end, it is still a placeholder map, considering that whoever retiles it will have to use new graphics and check wall/passability all over again.
soggie said:
You mean handling obstruction of this type:
I simply swapped places between Y-loop and X-loop. X-loop is the main one, going from left to right, and Y-loop is going from top to bottom (now no longer MAIN, but NESTED).
This is based on the assumption that the left-upper corner (see red rectangle) of every object is their "start point".
Now, how do I get to align that corner visually? I store pixel X,Y display offsets for every isometric bitmap, and they're adjusted by keypad keys in realtime in the editor. And saved.
Here's what I meant:
Let's say your render order is X-first, which basically means your renderer will render from northeast to southwest, and then move on to the next row. Refer to the numbers in the tiles.
Assuming that is the correct render order, and assuming that on the red outlined tile underneath the cursor you draw the entire ship, wouldn't the red dude overlap the ship because he is rendered after the ship?
Let's say your render order is X-first, which basically means your renderer will render from northeast to southwest, and then move on to the next row. Refer to the numbers in the tiles.
Assuming that is the correct render order, and assuming that on the red outlined tile underneath the cursor you draw the entire ship, wouldn't the red dude overlap the ship because he is rendered after the ship?
An actor wouldn't be able to step onto an impassable (blue) tile such as that one, because it belongs to the ship.
The engine cannot handle people walking inside multi-tile objects, only going around them, and the general assumption is that a multi-tile object is a rectangular, filled, block.
But if I wanted to fuse something static onto the ship in specific order, I have layers for that which are rendered in certain order. That's how we place stuff onto walls and tables, and combine doors with security terminals.
The engine cannot handle people walking inside multi-tile objects, only going around them, and the general assumption is that a multi-tile object is a rectangular, filled, block.
But if I wanted to fuse something static onto the ship in specific order, I have layers for that which are rendered in certain order. That's how we place stuff onto walls and tables, and combine doors with security terminals.
It would no longer apply.The ship is X+1 compared to the guy, and as such, is rendered in the next iteration, properly obscuring him.
Dude, I was confused by this isometric crap for the longest time. Still am, a bit
As an Amazon Associate, rpgcodex.net earns from qualifying purchases.