Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Luckless

#1
"A little different from last time you played."

Playing around with how you do things, finding things that work and things that fail is a big part of what makes the game fun for a lot of people. Be careful about robbing yourself of exploration in this regard.

I recently started playing again, and have been attempting some new layouts compared to how I played before. In the past I frequently used trap corridors and turret heavy kill zones. This time I've been trying to build 'strong houses', with lots of doors in and out of the base, and bedrooms/workshops ringing the core of the base as a sort of double layer defence wall, with two or three ways outside of the base to repel attackers from while not using turrets.

For my next game I'm going to take it a step further and essentially build "Star Forts" from the 15th century from the get go to address issues I had early on with my current run. The outer walls get loaded with doors and the doors are fronted with sandbags, and every now and then, spaced about the range of my main weapon at the time, I'll put narrow bastions projecting out from the wall.

When an attack comes along I will recruit all my soldiers and rush them to the doors on the side the attackers are coming from, but they'll remain safely hidden INSIDE the walls. After the attackers have spread out and are looking over the walls I'll start popping them out of the doors in strategic locations. Anyone who starts to draw fire ducks back inside, and I can safely run them to the next point-of-fire.

If a section of wall comes under attack, then I main the bastions and catch the enemies in a cross fire. If they attack a bastion then my soldiers start popping out the doors along the walls.
#2
General Discussion / Re: Plasteel Auto turrets
December 18, 2015, 04:53:30 PM
Quote from: JimmyAgnt007 on December 18, 2015, 11:47:53 AM
Im with Duban on this.  Set them up cheap and replace the ones the AI likes to attack.  It would be nice if we could uninstall them and move them about like other things.

Or tanks... Take the fight to them!
#3
General Discussion / Re: Megascarab paradox
September 26, 2015, 07:56:36 AM
Quote from: SpaceDrunk on September 21, 2015, 10:43:46 PM
We should be able to genetically engineer giant megascarabs, or mega megascarabs, or whatever.

gigascarabs?
#4
Side note reminder for international discussions involving numbers: Some countries use the period character for decimal notation, and some use the comma. Also different regions group digits in decimal notation different, some spacing every 3 digits with a comma, some with the period, and some with just a space. Other countries also group digits in interesting/weird ways.

Numbers are fun!


But still my earlier post was partly about how wealth, resources, and technology are not always as evenly spread as many people seem to think it will be, especially when talking about the future. I live in a city where the vast majority of people own a car and drive everywhere, but I walk pretty much all the time because I spend my money on things other than a money pit of a car. Some simply can't afford to own their own car, and make do without.


And even if you can afford some technology, you may not have the resources on hand to constantly use it. Fuel and maintenance requirements may simply be too high to use it all the time, so you would hold it in reserve for when it really matters. (I saw a photo from a few years ago of combatants somewhere overseas. They had modified a heavy truck into a light armoured vehicle, but mostly hauled it around with horses, and only fired up the engine to actually engage in combat due to how hard it was to get fuel at the time.) Just because you have access to a given technology doesn't mean you always get to employ it all the time.
#5
One thing to remember about advancing technology is that it doesn't advance evenly, and it isn't always universally available even if it is relatively cheap. Just look at computers in our current world, and just how cheap and easy it is to get your hands on something like a Raspberry Pi. Now go look at regions of extreme poverty.

There can also be a huge difference between general knowledge of a technology, but even with extremely detailed knowledge of the subject it may not be practical or even remotely possible to produce that technology. Myself and several of my former classmates from university all have the technical knowledge to design a fully functional nuclear explosive device, including practical knowledge needed to machine everything involved, but we simply don't have access to the resources needed to undertake such project even if we could find some way around the law to get away with trying to build such a thing. ("We just wanted to build one to prove that we could, we didn't plan to set it off at any point... honest!" probably won't fly very well. At least I hope it wouldn't.)


Some technology simply works well enough that it is going to be rather hard to replace. Take the common hammer for example. Go in to any research lab dealing with building advanced robotics, even when those robotics are focused on use in manufacturing, and you're going to find a hammer. Why? Because sometimes the easiest way to fix something involves bashing it (carefully) with a big hunk metal on a stick. And even with all the awesome new materials we have on hand, I personally still tend to prefer a good old fashioned wooden handle on my hammers. Why? Because it is easy to work with and fix should it break. Trying to fix broken fibre glass handles is just a headache.


When it comes to projecting a force at a distance with the goal of destroying a relatively soft target, such as another human, well then you are going to be hard pressed to trump the reliability of setting off a chemical reaction to generate a rapidly expanding gas to propel some manner of small projectile to a high velocity and send it spinning about its axis out a barrel. We've made lots of nice refinements on guns, but we really haven't changed a great deal beyond fine details on the concept in a few hundred years. We've improved loading mechanics, we've improved casing and projectiles, and we've improved the propellents. I really can't think of anything all that innovative being done in the field of small arms since designs dating back to the 50s and 60s other than optics from the late 80s. If you want something that is cheap and easy for pretty much anyone to build, even thousands of years into the future, well it is probably still going to be hard to trump building a variant on design concepts we've been using since probably before the vast majority of the people playing this game were born. Physics won't change the fact that small arms are highly effective at what they do while being very easy to produce.
#6
General Discussion / Re: Faaaaaarms.
July 17, 2015, 02:10:49 PM
Quote from: Devon_v on July 17, 2015, 02:01:13 PM
I would imagine that tasty animals would have been kept the same by the humans that enjoy them. Nobody wants Betapigs running amok eating everyone, it's the pigs who are to be eaten. :)

Tastes change over time, and some breeds die off completely. Maybe there was a long point in history where it was considered unmanly/unsporting to raise such tame and easy creatures as the common pig, so the "Razor Spine Back" was developed and completely eclipsed all other bloodlines causing them to die out before anyone realized just how dumb the idea really was?
#7
General Discussion / Re: Should Tynan have a day off?
December 01, 2014, 06:11:47 PM
Yeah, anyone who didn't get the hint that my previous comment was sarcastic is probably in for a very awkward time in life.

However, I think it is good for communities around projects like this to understand how development works, and encourage the developers to work at a sustainable pace.

Many DO work far too hard, putting in far too many hours early on in a project. I've seen some independent developer types who put in 160-190 hour work weeks on their projects for a year or more and rarely taking a day off, thinking that they were doing such a great thing by getting sooooo much done. Then the burnout hits, and development grinds to a halt. Customers become pissed, and relations evaporate. Then I would see many hitting brick walls in their own code base when they finally did manage to get their head back around and focus on development again. Lots of little hacks, and half documented code everywhere. Developing software is easy when it is all fresh in your brain. Your mind is able to handle everything and keep track of what exactly is going on in each section, and remember what needs improvement/advancement... But once you start dropping the balls, then things can really unravel in a hurry. Had they been working far slower, with 40, or even just 30 hours a week, then they're forced to put down the balls and then actually Look at stuff each time they come back to it after a break. Design flaws get spotted so much easier, and you ask yourself "Why on earth would I do it that way?" The sooner a change is made or an error corrected, then the smaller the impact on the entire project is.

So, really the short of my comment is: Remain Calm. Software development is a hard and complex thing to do correctly, and the long term payoff can be far more with a more sedate development cycle than one of breakneck speed which produces vast amounts of half-baked content for you to temporarily enjoy.
#8
General Discussion / Re: Should Tynan have a day off?
December 01, 2014, 11:59:00 AM
He should clearly work 18 hour days, every day, and be forced to listen to people constantly nagging and harassing him about updates and how he sucks at his job because there are bugs, or features aren't done exactly the way a small but overly vocal minority wants them... this should clearly continue until he is so fed up with the community that he gives everyone the finger, deletes everything, and go takes a job writing banking software or something.


But really, scheduling breaks and time off is an important thing. It is so easy for developers to burn out, or get into the 'ineffective coding' slump that appears like they're making headway, but are really writing nasty hack code that will just become a nightmare over time and slow development in the future. And members of the community need to remember that writing software is NOT easy to do well, and is not a quick thing. Things take time.
#9
Ideas / Re: Get rid of Nutrient Paste Dispenser?
March 10, 2014, 06:35:26 PM
I wouldn't mind seeing an 'advanced tech' feature added to the game. Things like the NPD would require one or more 'advanced tech modules' which would be expensive, but one or two would crash with you at the start.

The NPD would make life far 'easier', but the food it makes wouldn't be nearly as good as a skilled cook could produce. It could however be upgraded over time with research unlocks and skill based improvements to the machine to lessen the negative effect, but even the best upgrades would only offer a very minimal bonus if any.

An unskilled cook would have a chance of producing rather bad food or even waste food, while a reasonably skilled cook would give a decent bonus to, and a very skilled one would grant a very nice bonus, but of course at the cost of the time and labour needed to dedicate someone to the job.
#10
Food has been an issue for me as well.

Besides just managing when and how much I make I've had the issue of even when I had a fair number of meals ready then pawns would still path to enjoy the tasty tasty paste, which they would promptly complain about.

However simply saying "Always eat meals first" might not be the best solution in larger bases that might have multiple meal stations. (Maybe multiple 'home zones' so you can configure sub-communities that will use their own resources first before checking others.)

The other problem I've been having is the lack of visibility on things like the stone cutting bench. Having a clear ring on how far they will go to grab stuff might be nice, as would maybe being able to select a dumping area as their 'go-to' point to grab stuff first. (That way you can queue up haulers to drag stuff from far away to keep the crafter rolling.)
#11
Ideas / Re: Meals will be stackable?
March 07, 2014, 09:42:05 PM
Meals stack together with others of the same kind, and become an ordered list of spoil times. Colonists would of course take oldest first, and ideally will store them in neat stacks near where they're made.

Storage could be a technology tree with related devices. Start off with just a cupboard that would give no storage bonus. Next would be basic refrigeration, but it would append a 'second life' value to meals stored in it. (Colonists don't enjoy older meals, but they're still better than paste) Refrigeration could be upgraded in ways such as extending the 'first life' aspect of a meal as well as its second life. Could have a secondary device that would restore meals that had been stored.

This way you could prep a pile of meals at once and then have your cook move on to other jobs that might have them working further from the meal prep area.
#12
Heavy handed moderation rules such as that are an excellent way to poison a community and needlessly create hard feelings and alienate members, and they are made worse with abrupt application of moderation powers when no communication is attempted.

Excessive "my way or the highway" results in many choosing the highway, and leaving a clique that is at risk of becoming absolutely horrible for new people to join.

General guide lines on posts are good, but leave the creator free to be flexible with how they post. Readability is important, not that they have followed the letter of an arbitrary template 100%. 100% strict templates are actually a great way to reduce readability.

In cases where readability is less than desired the first tool used should be to communicate with the poster to inform them of your opinion. Explain what you feel is wrong and how it can be improved. Barring little things like obvious typos on links and such that break things and are easy to fix, or actual broken rules/abusive posts, the original poster should be given the chance to fix their post as they feel best.

If a mod still feels that a post is less readable than it should be, then they should continue the discussion. "I know better than you because I'm a mod!" is not a great stance for moderators to help build a community up.
#13
Ideas / Re: Procedural Landscapes / Large maps.
February 21, 2014, 11:52:55 AM
Some options for how to handle things when 'going off map':

1. Split time: When you form up a group to go off map, a secondary save if created. You play one or the other for a given amount of time and then have to switch back to the other save. This 'jumps you back' in time, and you play forward from there. Things that you trigger from one save may show up again in the other. Such as if you play forward with an adventuring party you might find a traveling merchant and send him toward your camp, or come across another group of survivors and invite them to join you. When you go back and play forward from the base perspective these events will then happen.

If you bring the adventuring party home, then you automatically jump back and play the base forward, eventually having the party arriving home at the correct time.

This works the same as TV shows or movies that focus on different characters doing different things that fall along the same timeline. And the story teller can even weave them together: You don't know it as you don't get to see anything with you come 'home', but your party arrives back just in time to see a group of bandits attacking or something.

2. Single time line with 'estimated simulation' for one or the other. (Not my favourite for most base building) This assumes that bases become 'stable' at some point. They develop enough that they don't really need any more attention, and the colonists just go about their daily lives of growing food and making items. The mining is done, all the buildings are where you would want them, and it is just upkeep from then on. Once you are at that point you are free to 'wander' away. When you come back the story teller will come up with a summary: Raiders hit, X and Y died, Z was captured, someone joined, merchant showed up and we carried out the usual transactions.

3. AI only missions: The 'extra world' is more a high level map view, and you send groups out on this that will then procedurally give you results: found X, Y died in a fire fight, brought back items A, B, and C, etc.

Other options/variants are possible, but I think these are a good starting point for discussion.
#14
Ideas / Re: Procedural Landscapes / Large maps.
February 21, 2014, 07:20:30 AM
Quote from: StorymasterQ on February 20, 2014, 07:05:21 PM
Quote from: TimMartland on February 20, 2014, 03:04:41 PM
@Luckless Good ideas. Bandit camps would be an especially welcome feature - you could destroy them to lower the amount of raiders and the frequency of their attacks.
Couldn't it also in fact increase the frequency? Because from their point of view, we'll be the raiders...

Not if every single one of them is already dead...

But personally I would prefer combat to be secondary to base building and survival. It should be possible for the game to be hard and still fun without the storyteller throwing a single raider your way. Combat should be one of many interesting challenges to face. Maybe you'll go 'off exploring' to find a large chunk of space ship that fell to the planet, or have the option to build small exploration satellites that will flag something away from the base as having some resources. Maybe you will travel to get to markets to trade stuff, or perhaps your colony will just be doing really really well, and you want to take a group of people off on a random adventure just to see what is over the next mountain.
#15
Ideas / Re: Procedural Landscapes / Large maps.
February 20, 2014, 12:02:34 PM
As big as the developer wants to put the time into making it.

By using multi level chunks/cells that allow split path finding it also becomes fairly easy to split the map into chunks that can be loaded in and out as needed. Plus it would be possible to 'estimate' bits that are away from the main areas.

Bandit camps don't get calculated as precisely as the player's colony. Rather than carefully tracking every last position of everything, the camp merely gets stored as a location, with a population list, item list, and 'production level'. Nothing actually gets calculated beyond that till it is needed, and then things get generated on the fly. First time you go there the map gets generated, people's positions get updated, etc.

While you are right there things get fully calculated as in your main colony. If you step away from the camp then their last positions get saved. If you step right back then the game looks back at the last save data point for the camp and updates the raider's positions based on how far they could have moved and things go back as they were. If you go well away from the camp then the map is saved for later (or regenerated from seed), and it goes back to vague estimations.

Vague estimations get updated at a high level 'tick' rate. New people come and go, total food/resource/item levels are used or generated at a preset rate, etc. These 'groups' can shift from one high level zone to a nearby one, become flagged as moving or 'setting up camp', or even raid each other to 'exchange' goods and resources based on very simple estimations rather than processing out detailed tile based interactions.

The goal is to keep only the most basic information possible and do as little math on stuff the player isn't directly working with as you can, and only do hard number crunching at the last minute when it becomes directly relevant.


A really interesting option that a classmate was working with for a similar game (closer to dwarf fortress than rim world) was making the game itself a 'multiplayer' client that then connected to a server that handled the actual 'world'. That server could be configured to be fairly small and hosted locally alongside the player's client, or they could configure it for a far larger and more complex world, and dedicate a server box to it. (Which could either pause the simulation or keep things going when the user exited their single player game. He had the option of either allowing the world to continue while the user wasn't there, or taking a snap-shot of it and the server then sat there pre-calculating different stuff to add flavour to the game.)