Grid Sage Forums
- May 14, 2024, 01:14:51 PM
- Welcome, Guest
|
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.
Pages: [1]
1
Ideas / Re: Hot wheels idea
« on: November 29, 2016, 04:16:28 PM »
Sounds fun to me, although I think that there's a fine line between it being balanced, fun and consistent with the rest of gameplay. I'm not really sure if I'd want my robot to keep rolling because I forget to hit the brakes but on the other hand if there's no realisticish consequences to momentum then really what you're doing is balancing a reward for players for moving continuously in a straight line against a punishment for when they don't do so.
2
Ideas / Re: Interface / kb (alpha vs num)
« on: November 29, 2016, 04:05:09 PM »In the above scenario, hold Ctrl-Shift and press 'i' followed by '2' and it will swap those two. No modal '/' necessary.
Damn don't know how I missed that. Been doing it with the / the entire time.
3
Ideas / Re: Interface / kb (alpha vs num)
« on: November 27, 2016, 05:53:55 PM »Hm, I don't understand what you're suggesting. Part swapping does what makes the most sense when working from either direction--if swapping in an item from the inventory, you want to know what slots are valid for it, whereas if swapping out an item from a slot, you want to know what inventory items are valid for that slot.
http://imgur.com/a/ES0PB
Ok, so my point here is that these things already have labels.
If I look at the screen and decide, 'ok I want to swap I and 2' then I can press / and then 2I and it will work, but I can't press I2 and have it work.
The current functionality may be useful if you decide 'I really want to swap out I.. for something, but I'm not sure what' or 'I'd like to compare each of my equipped items with potential upgrades', but personally (and admittedly from a new player standpoint) I more often want to reference the labels that already exist on the screen.
4
Ideas / Interface / kb (alpha vs num)
« on: November 27, 2016, 07:31:43 AM »
When you do:
/-Number: it provides you with prompting to help you pick the right choice from the currently lettered items in your inventory.
When you do:
/-Alpha: it creates a new list of alphas from your inventory that has nothing to do with their current labels.
I like the way /-Number works a lot better, and if it's possible to extend this functionality to /-Alpha I think it would be good as an option if there's a reason for the current functionality or, if not, the only method.
/-Number: it provides you with prompting to help you pick the right choice from the currently lettered items in your inventory.
When you do:
/-Alpha: it creates a new list of alphas from your inventory that has nothing to do with their current labels.
I like the way /-Number works a lot better, and if it's possible to extend this functionality to /-Alpha I think it would be good as an option if there's a reason for the current functionality or, if not, the only method.
5
Well from a high level view -- anything your robot knows and remembers is data in its little databanks.
In its memory banks for an square, item, robot, wall, terminal, device, smelly hobbit, etc the raw data would be something like this:
- The known properties of it, when last seen.
- Coordinates for the last place I detected it?
- Turnstamp for last time I detected it.
I think that pretty much covers it. I might be missing something you'd really need but with robust queries those are the only things you need to associate in other data
for example:
QRYDFN for Where might I productively look for some butter?
SELECT coordinates
FROM items INNER JOIN squares
ON items.coordinates = squares.coordinates
WHERE items.lastseen = squares.lastseen
AND items.name = "BUTTER";
Note: 'last' is semi-ambiguous. What 'last' means depends on whether the robot is able to distinguish between two things that are the same (the game can, but should the robot be able to depends on many factors. Perhaps 'he' has a digital prong that sprays RFIDs on everything 'he' finds, but more likely it's only able to positively* distinguish things based on where they are unless they're transmitting an ID that your robot is scanning.) So for things that he can identify uniquely, 'last' refers to the last time he knew where a particular thing was, whereas if he can't uniquely identify a particular thing 'last' means (more or less) the last time he 'saw' a thing of type at a particular.
(I say 'positively' because if he knows things about the thing he might be able to make an even fuzzier match than 'location' (I mean, if an assault rifle is where you last saw an assault rifle, that doesn't ACTUALLY mean it's the same assault rifle) and for anything that has non-default properties that are visible to the robot this might make for a pretty decent match, although I'd say it's questionable whether the robot should really be considered to 'know' as much about objects as we're presented with in-game, especially about EVERYTHING that he's ever seen. Maybe after the player looks at the object it's not too unreasonable to think that he knows that the hover unit is at 29/30 integrity, but honestly if he can really, really do that it's surprising all the things he can't do. I'm not saying take that data away, but if you implemented what I'm suggesting here I could see an argument for having some corruption in the reports, especially for older data)
In its memory banks for an square, item, robot, wall, terminal, device, smelly hobbit, etc the raw data would be something like this:
- The known properties of it, when last seen.
- Coordinates for the last place I detected it?
- Turnstamp for last time I detected it.
I think that pretty much covers it. I might be missing something you'd really need but with robust queries those are the only things you need to associate in other data
for example:
QRYDFN for Where might I productively look for some butter?
SELECT coordinates
FROM items INNER JOIN squares
ON items.coordinates = squares.coordinates
WHERE items.lastseen = squares.lastseen
AND items.name = "BUTTER";
Note: 'last' is semi-ambiguous. What 'last' means depends on whether the robot is able to distinguish between two things that are the same (the game can, but should the robot be able to depends on many factors. Perhaps 'he' has a digital prong that sprays RFIDs on everything 'he' finds, but more likely it's only able to positively* distinguish things based on where they are unless they're transmitting an ID that your robot is scanning.) So for things that he can identify uniquely, 'last' refers to the last time he knew where a particular thing was, whereas if he can't uniquely identify a particular thing 'last' means (more or less) the last time he 'saw' a thing of type at a particular.
(I say 'positively' because if he knows things about the thing he might be able to make an even fuzzier match than 'location' (I mean, if an assault rifle is where you last saw an assault rifle, that doesn't ACTUALLY mean it's the same assault rifle) and for anything that has non-default properties that are visible to the robot this might make for a pretty decent match, although I'd say it's questionable whether the robot should really be considered to 'know' as much about objects as we're presented with in-game, especially about EVERYTHING that he's ever seen. Maybe after the player looks at the object it's not too unreasonable to think that he knows that the hover unit is at 29/30 integrity, but honestly if he can really, really do that it's surprising all the things he can't do. I'm not saying take that data away, but if you implemented what I'm suggesting here I could see an argument for having some corruption in the reports, especially for older data)
6
Ideas / Re: defaults
« on: November 24, 2016, 09:07:30 AM »I would agree with that sentiment for most games, actually. Though in the case of Cogmind, there are an extremely low number of errors, quite different from what you find in a lot of other alpha games. That's because most of my testing is done via automation before I release an update, so I can catch and fix stuff much more quickly than players could, and most of that stuff never reaches players in the first place. I can have the game play itself thousands of times under extreme conditions, and this tends to weed out pretty much all the bad stuff so that only a subset of bugs--stuff that it really takes a human to find and describe--actually make it through, and those are the kinds of things that wouldn't appear in an error report anyway.
Can this be accessible to us in some way? I want to program my robot. I think that's what first drew me to this idea, was memories of shitty games from my childhood where you were allegedly going to be able to program a robot. I know there's stuff out there now like that, but this one kind of just fell across my path and reminded me of it at a time when I was particularly susceptible to robot nostalgia.
7
Fun thought:
Allow database queries that generate reports on 'known data'. Allow players to construct reusable query definitions and bind these to some set of keys to allow players to get quick reports on things that they might find interesting.
Depending on how things are implemented in the game right now this might not be possible without a gigantic overhaul.. But I think that from what I've seen it might be plausible.
(I thought about this because it occurred to me that it would be good to have a 'seen objects list' report that could be generated and ideally interacted with to some extent, but then my data analytics background kicked in.)
Allow database queries that generate reports on 'known data'. Allow players to construct reusable query definitions and bind these to some set of keys to allow players to get quick reports on things that they might find interesting.
Depending on how things are implemented in the game right now this might not be possible without a gigantic overhaul.. But I think that from what I've seen it might be plausible.
(I thought about this because it occurred to me that it would be good to have a 'seen objects list' report that could be generated and ideally interacted with to some extent, but then my data analytics background kicked in.)
8
Ideas / Re: defaults
« on: November 23, 2016, 05:25:58 PM »With Cogmind I wanted to avoid all modal barriers to starting the game--you watch the intro and *bam* there you are in the world. So that means no start menu, and no prompts.
Interesting point. I mean it's obviously your call but on this:
Specifically with regard to reporting, all online features that send data are disabled by default because some people are extremely sensitive to that sort of thing.
I personally think that getting error reports is worth breaking that goal during alpha. The sensitivity issue is why I went with the prompting as an alternative suggestion here. I mean, I we did pay to be in this alpha, but I've always felt that if I'm going to participate in an alpha or beta I need to drop the consumer attitude and participate. Mind you, this is honestly the first time I've ever paid to be part of an alpha so maybe I'm just not familiar with how much of a headache it would be to expect players to send logs or opt out.
Quote
And actually, in the end many experts prefer this option to be on because it saves you a turn if you're fleeing pursuers that could otherwise fire on you before you've ascended (which would take a second action after actually moving onto the exit itself).
Yeah, tbh for beginners though I think the frustration of finding out they don't get to pick up their phat lewts is more of a disappointment than the possibility of dying because they had to take an extra turn (which honestly I doubt they'd even think about until they are expert at the game). Speaking as someone who is barely past being a beginner -- I die a lot, and it's fun -- if I ever die because I'm on the stairs that will be the day I swap that option, but for now my deaths seem to focus more on the being greedy and careless end of the spectrum.
That said, one possibility that popped into my head when you mentioned that reasoning.. Perhaps allow players to use <> from any space around the passage as long as there isn't anything in the way.
Quote
Yep, this one again is for beginners, as it's a way to teach them how the system works. It totally should be on by default, but if this happens automatically, new players will be less likely to quickly figure out that parts can be toggled, and must be active to work. (I'd love if it were on by default, because then I could free up the 'p' key for something more valuable/frequently used, but alas, it's too important that it remains as it is now.)
Yeah, don't disagree.
Quote
So thanks for the suggestions, though I'm looking at this from a very different perspective than a regular player might! Remember that with Cogmind I'm also trying to get people who've never even played a roguelike before to enjoy it. They can gradually work their way into the options menu and its many secrets
I will say one of the things I like most about this game is that while from a rogue-like players perspective it it clearly a roguelike, it almost feels like you had at most heard rumors that roguelikes existed and you researched them enough to hear about permadeath, but then got bored and just decided to make one. That's a gross exaggeration, but it doesn't feel as highly derivative. I've played some great roguelikes that were incredibly innovative, but I this is the first that I can recall playing that I can really see myself forgetting that I'm actually playing a roguelike.
9
- for alpha imo you should think about having report errors be the standard default, or at least prompt us to choose right off
- name would be a nice thing to be prompted to choose
Changes to defaults in general that I'd make:
-autoascend=on should go off imo
-if not for being part of the tutorial that leads players to it I'd say auto-enable parts should probably be on by default (it may rob players of volition slightly unlike autoascend=on new players will always want it on)
Personally I'd also max out on UI elements as well as a default but that may just be me. I know I have a bias on that one so I won't really make that a suggestion as much as a stating of personal preferences that should probably be ignored.
- name would be a nice thing to be prompted to choose
Changes to defaults in general that I'd make:
-autoascend=on should go off imo
-if not for being part of the tutorial that leads players to it I'd say auto-enable parts should probably be on by default (it may rob players of volition slightly unlike autoascend=on new players will always want it on)
Personally I'd also max out on UI elements as well as a default but that may just be me. I know I have a bias on that one so I won't really make that a suggestion as much as a stating of personal preferences that should probably be ignored.
Pages: [1]