|
381
|
Developer / Technical / Re: Pathfinding technique
|
on: May 26, 2009, 10:58:14 AM
|
So far, I haven't needed it to be faster than what it is - I guess it all depends on the size of your search space and how many pathfinding agents you have... It will all be fun to look into when I run into a need for it  Yeah, same here, until now. I'm just bemoaning the long (sometimes infinite... but that's another issue) startup time I have as my pathfinder makes a measly 20-25 roads on a not-very-big terrain :S Replacing the storage structures doesn't really make the main algorithm code any more complex, it's just a bit of extra tucked-away support code.
|
|
|
|
|
382
|
Developer / Technical / Re: Pathfinding technique
|
on: May 26, 2009, 10:11:17 AM
|
(though not the fastest) Depending on what you're using it for - specifically how big the open and closed lists get - you can get a massive speed increase out of improving the cost of getting the best node from the open list and checking if a node exists in the open/closed lists ("GetHighestPriority" and "ItemExists"). This means using some fancy storage type for the lists instead of plain arrays/lists... binary heap maybe? I can't remember the exact one, as my current A* implementation is itself badly needing this optimisation...
|
|
|
|
|
383
|
Developer / Design / Re: What is your game design style?
|
on: May 26, 2009, 09:58:50 AM
|
Well, if it's useful, fair enough. It just seemed to me to follow a familar pattern of the Myers-Briggs Type Indicator or even those "Which X are you?" tests. I felt like it was forcing me to make fairly arbitrary choices, and the result is one of a set of (pretty much) fixed pieces of text. Anyway, I did it twice (since about half of the questions could have several answers) and got "The Experience" and "The Open Experience", and felt the Forer effect tugging at me strongly as I read them 
|
|
|
|
|
386
|
Developer / Playtesting / Re: Spelunky v0.99.8
|
on: May 25, 2009, 12:45:20 PM
|
Holy fuck this is great. Seminal. I played ages ago when there were some nasty crashes and the controls were a bit wrong, but now Spelunky consumes my free seconds. That is all. [Apart from - a few years ago I was thinking of doing a Roguelike platformer, but only got as far as a brainstormy design wiki and later on a very simple prototype. This is thousands of times better than it would have turned out, had I made it and solved the hundreds of design problems.. so yeah.  ]
|
|
|
|
|
387
|
Developer / Technical / Re: Pathfinding technique
|
on: May 23, 2009, 04:37:48 AM
|
Ah yes, thanks! I remember this from your Flash pathfinding demo thing (I think...) It's interesting - I will definitely implement this someday. Will be nice to have this (maybe specifically for player-hunting) and A* available in the same game, so NPCs can use whichever is best for their current task. [OpenOffice - yeah I thought I had it installed and it just wasn't associated with the PPT file type, but turns out it's not actually on this PC, and I've been using Google Docs for everything]
|
|
|
|
|
388
|
Community / DevLogs / Re: Codex (an RPG)
|
on: May 23, 2009, 01:57:09 AM
|
Interesting! Seems like you have a really solid philosophy behind the world and the story. Nice Amiga-ish look too  I was wondering about how movement/travel would work as presented in the first pic, but the "Travel" explains it. Sounds like a good plan. I find I have not much patience for reading lots of text in games - which is weird, as I love Planescape. Maybe it's all about how things are revealed, and allowing the player to dig into the detailed world/backstory stuff under their own initiative? (Minor point on the text: Since its a big fundamental thing, but with a generic name, should "energy" be capitalised, i.e. the Energy? By anology with "God"/"god")
|
|
|
|
|
390
|
Developer / Technical / Re: Pathfinding technique
|
on: May 18, 2009, 09:03:56 AM
|
[Off topic: Is there a way to view .PPTs without MS Office? Not sure if i've read that paper before but can't check it now..] Whatever it says, you are certainly right about A* not being the only solution for "pathfinding", as long as you mean "Getting from A to B". For literally finding a path between two nodes in a network it's very hard to beat A*, as long as you use good data representation and a good heuristic, and don't expect to be able to hack about with it without understanding it. That "Amit's A*" page is totally awesome for this stuff. It's also not just for finding physical paths, you can use it to find a path through any kind of configuration space, for example those annoying silding block puzzles. If you mean "getting from A to B", then as mentioned there are lots of other techniques depending on the situation. E.g. This. As you might have deduced, I am a terrible pedant when it comes to use of the word "pathfinding." Or any word, for that matter. 
|
|
|
|
|
391
|
Community / Creative / Re: Personal Deadlines
|
on: May 17, 2009, 08:31:20 AM
|
|
Heh that's what I'd hope!
Actually on my current work project we do a sort of pair-programming, in that we review eachother's code with both people at the same PC before checking in. It has much of the same benefits. Even just having to explain something to someone else can make you think critically.
|
|
|
|
|
392
|
Community / Creative / Re: Personal Deadlines
|
on: May 17, 2009, 12:47:15 AM
|
Reminds me of assembla. One of the main issues of online scrum is you miss the real world shame element that drives scrum IMHO. Heh, yeah, looks almost identical  Sadly, I've never used Scrum (or any other Agile system) in a "day job", so I can't compare it for effectiveness of collaboration. Putting stuff from the backlog into a sprint, setting a vague end date and ticking it all off is quite satisfying though, in a softer more fluid way than deadlines (especially because my sprints grow and shrink quite happily). Is pair programming really based on shame and guilt? Jeez... sounds terrible!
|
|
|
|
|
393
|
Community / DevLogs / Re: undeRLord
|
on: May 16, 2009, 10:30:43 AM
|
Looking at those pics, it looks like the biclops  takes up 2x2 grid squares. Is that right? If so, that's really cool - I can imagine ducking into those little 1-square-wide alcoves and doorways and outwitting him. He is slow and stupid right? Right? 
|
|
|
|
|
395
|
Developer / Design / Re: Procedural Gameplay
|
on: May 15, 2009, 02:39:45 PM
|
I could do it so that it is effectively like a random game name generator Yeah, seems reasonable. Certainly worth a go for a first version to get some ideas. It might depend on how you want to frame the scenarios - I mean, whether you want an infinite chain of stuff that keeps growing, or short episodes of scenarios. It doesn't really matter much at this stage though IMO. I'm not sure how I could easily put any gameplay into a prototype of this idea without getting drawn into needing art assets and having to code up the actual mechanics. I would say having something that generates a text-based description of some sequence/combinations of scenarios would be pretty cool to have, and should tell you some useful stuff. It could be a fun toy guess it's not strictly a gameplay prototype. There isn't really a way around writing some gameplay code (maybe some super-simple Geom Wars or Diablo-like thing?) but you really don't need to go near art assets! Just draw some squares and triangles with faces on or some crap like that :D Someone else might have some better ideas about simple gameplay... Oh, and this and this are great threads! (see this post for an interesting procedural story system... I wasn't going to shamelessly steal the idea, honest vdgmprgrmr  )
|
|
|
|
|
396
|
Developer / Design / Re: Procedural Gameplay
|
on: May 15, 2009, 01:57:45 PM
|
Regarding RLs, I probably go for the easier ones too (IVAN  ), although I'm pretty happy to die a lot as long an interesting story (well, series of situations) unfolds in the process. All troop styles in MnB get significantly randomized. Character stats are different in every game, per troop (so, troop abilities arent even constant between games). Items get randomized on a per unit basis. And then you fight those on a 3d battlefield. How then does MnB manage to keep battle difficulty predictable?
Really? Eqiupment is slightly randomised, although within such tight boundaries that you can pretty reliably tell (say) a Nord Footman from a Nord Warrior just by looking at them. Are stats random? Anyway, apart from that I think it does quite a bit of adjustment of damage done per hit etc, but the difficulty of a battle is really determined by the numbers and types of troops, and the situation. I'd consider M&B more of a (very finely-crafted) sandbox than PG, but then it does have a lot of design features that would work for a PG game world, so I agree that it's an interesting example. Mephs: Please prototype and report back!! 
|
|
|
|
|
397
|
Community / Creative / Re: Personal Deadlines
|
on: May 15, 2009, 01:13:43 PM
|
I found personal deadlines to personally be ineffective. I get better result with burndown charts and ticking off features from a list I wish to add. To actually be able to physically see your progress is very motivating rather than just knowing that I got something finished.
Yes! This seems to be working well for me too, although I've never really tried the deadline-based method. Probably because my free time to work on stuff is quite unpredictable so short deadlines don't work. (And with longterm deadlines I think I lose focus) I'm using www.acunote.com, which is free for small teams (including teams of 1) and really slick. It does burndown charts and stuff, but i'm not really using for anything more than dumping a vast list of tasks and then organising them into "sprints" (it's an implementation of Scrum, but it's much simpler than it sounds)
|
|
|
|
|
398
|
Developer / Design / Re: Procedural Gameplay
|
on: May 15, 2009, 01:05:04 PM
|
|
Out-of-depth monsters are a pretty minor factor in the spikyness of RLs. There are several games where you can turn them off and the game is still very random, and indeed appeals to a different audience even than Diablo.
If you consider the scores and summaries on a RL high-score table will you can tell that the difficulty curve is much noisier (and maybe distributed across multiple game sessions) in a different way to a traditional hand-crafted game.
|
|
|
|
|
399
|
Developer / Design / Re: Procedural Gameplay
|
on: May 15, 2009, 12:45:40 PM
|
You should absolutely prototype that scenario-generation system you described in the first post! It sounds really good in theory. You'll get more inspiration and ideas from the successes (or other results) of that than anything else. You'll also quickly see how good the success rate is, and whether scenarios generated are different in interesting ways. You should sit and run it 30 or so times at least  If you have that random scenario generator I think it could be applied to any of those genres you listed - "survive for X minutes" or whatever could be interpreted in any of them, with a bit of genre-specific code that acts on the output of the generator. Whenever you have a game with this type of thing you kind of give up having a smooth difficulty progression Yep, you could either suppress some of the potentially interesting spikyness of the PG system (could ruin it), design in some kind of safety net... maybe some sort of player choice... or you can just leave it spiky and hope that its fun enough even when you get dumping into an unfair situation!
|
|
|
|
|
400
|
Community / DevLogs / Re: Sprout - Devthread
|
on: May 15, 2009, 11:14:51 AM
|
|
Maaan... sorry to hear about the disaster. I was just about to download and have a go, but found out the mediafire link seems to point to an empty folder. Looks really nice though.
I guess there's no way to get a distributed build back off someone who downloaded it and at least recover the assets...? Can you even do that with GM? I have no idea...
|
|
|
|
|