Messages

31

7DRLs / Re: Hellion 7DRL

« on: April 06, 2015, 12:59:55 PM »

Hmmm... interesting.  I suspect that the problem is that your graphics card doesn't support OpenGL 2.0 and/or shaders, although if that is the case I'm a little surprised that it showed you the title screen OK, so maybe there's something else going on.  I'll look into it.

32

Other Announcements / Re: LikeLikeLite Podcast

« on: March 24, 2015, 07:47:32 PM »

I like it!  (Or should that be likelike it?)  The panel seem to have good chemistry and it's interesting that there is a range of different experience levels represented - it gives it a different feel to the more grognard-developer-orientated Roguelike Radio.

Some suggestions:

- The constant background music is very annoying, especially since the audio quality of some of the mics was not great and I was occasionally straining to hear what was being said anyway.  I'm cool with podcasts that add in a bit of background sound or music to give themselves a slightly richer 'feel' but I think it should be done sparingly and preferably mainly in frequencies outside the normal range of human speech (I'm thinking of Dan-Carlin-esque deep dramatic booms etc.)  If in doubt, leave it out.

- This applies to a lot of gaming podcasts that I listen to (including often RR) and always slightly bugs me; you assume that the listener is already familiar with the game under discussion and launch right into talking about it.  In this case, for me, that wasn't an issue since I have played CQ2, but if I hadn't I wouldn't have gotten much idea what it was actually like from the podcast.  It might be a good idea in future to start with a short introductory description of the game, especially if you're going to be discussing games with fall outside the traditional roguelike template.  If you've got the developer on, maybe start by getting them to give you a short 'elevator pitch' explaining what the game is about and why people should play it.

33

7DRLs / Re: Hellion 7DRL

« on: March 22, 2015, 10:54:36 PM »

Thanks!

I've just released a post-challenge update:

Hellion v1.0.1

This keeps the same basic content as before but improves the level generation, adds formations and generally tunes everything a bit more than I was able to do during the challenge itself.

Full changelog:

- Amount of fuel per Elyrium pickup increased slightly
- Recycling items now gives you fuel as well as credits
- Enemy and item generation tweaked to smooth out 'clumps'
- Enemies can now appear flying in various formations
- Amount of energy required for active weapons now shown on energy bar
- Field of view adjusted - should now be easier to tell which 'lane' an object is in
- Enemy spawn rates in each zone adjusted
- Out-of-zone enemy types now slightly more common
- Bugfix: Enemies no longer hurt by collision with pickups
- Bugfix: Items you cannot carry are now automatically trashed for cash and fuel when collected


Also; Hellion got a place in PC Gamer's Top Free Games Of The Week, which I'm pretty pleased with!

34

Programming / Re: Programming graphical effects with delays

« on: March 19, 2015, 11:07:43 PM »

3) A visual actor system that works with the rest of the visual presentation to the player independently of game logic and data: the visual aspects of the game are maintained separate from any game logic code; the visual actor system simply listens for game events that it is interested in and makes decisions about what animations to start, queue, replace, skip, etc.
Pro: Far more flexible than the alternatives.  Can be much nicer looking.
Con: Much, much more complicated and prone to subtle bugs.  Hard to determine if the visual state accurately represents the logical state of the game.
Examples: none that I know of.

I do something a bit like this, which is essentially my own simplified version of the MVVM pattern used by WPF.  This allows me to 'bind' properties of two different objects together.  The way it is implemented is something a bit like this:

- Each game object has getter and setter functions for all of its properties.
- In the setter function, I raise a 'propertyChanged' event, passing the property name as an argument
- Other objects can then subscribe to that event.  These maintain a list of bound property pairs.  When a 'propertyChanged' event gets raised, I use reflection to get the new value of the source property and apply it to the target one.

So, for example, let's say I have a game object A and a visual object B that I want to represent the position of A.  I just call:

Code: [Select]

B.dataContext(A);
B.addDataBinding("position","position");
Then, whenever the 'position' property of A is changed, the 'position' property of B is automatically updated.  Where animation comes in is that rather than immediately setting the property on B, I can instead set it up to automatically apply an animation that tweens from the old value to the new one.

Advantages of this system:
- It's super-flexible.
- My game logic and display logic can be completely separate.  If I want to move A from X to Y I just set its position to Y.  The visual representation B takes care of the tweening - I don't need to pollute my game code to deal with it.
- It's very easy and fast to set up new property bindings, or to completely change the way existing ones work.
- I can easily have multiple visual objects attached to the same game object.  For instance in Hellion, every game object has a 3D sprite in the main view and a top-down sprite in the 2D map.

Disadvantages:
- It was very complicated and took a lot of work to set up in the first place (although now it's there it doesn't give me much trouble).
- Because it uses reflection, it is relatively inefficient.  (Although not so much that it's had a noticeable effect in any of the scenarios I've used it in so far.)

35

7DRLs / Hellion 7DRL

« on: March 17, 2015, 08:52:12 PM »

My 7DRL entry this year is Hellion - a rail-shooter Roguelike, which plays a bit like a turn-based, grid-based version of Starfox.  In it, you must pilot a new experimental fighter-craft through waves of genocidal robots and destroy the avatar of the machine god.

For more information, see here:
www.vitruality.com/2015/03/hellion-7drl/

Download link:
http://pnjeffries.itch.io/hellion

36

Design / Re: Adaptive Difficulty

« on: March 09, 2015, 07:38:30 PM »

I really don't see anything that adaptive difficulty would give you that simply providing different difficulty modes wouldn't do a lot better.

Well, it takes the "designer job" of picking the right difficulty away from the player.

No, it does the exact opposite - it takes the 'designer job' of picking the right difficulty away from the designer and gives it to the player, but in an extremely obtuse and indirect way that means that it may not give the player what they want anyway.

I think declaring it a 'designer job' is a little arbitrary in the first place.  If I'm in a restaurant and the waiter asks how I want my stake cooked, I don't rebuke him with "that's a 'chef job'!".  I might get a bit cross, however, were he to hover around watching me eat, then decide that because I'm eating slowly it's obviously because it's too rare for me and grab it off my plate without asking to stick it back under the grill a bit longer.  That's basically how I see the difference between difficulty selection and adaptive difficulty.

Anyone interested in how to do adaptive difficulty right should look into Auro (available for iOS and Android). It effectively features a "single-player matchmaking system" that lets you rank up (and down) between matches to keep the challenge level optimal (just as flow theory postulates). It's a great approach that gets rid of a lot of the typical roguelike problems, e.g. them being about "highscores" (and therefore runs taking longer and longer, results becoming more and more meaningless etc.) or you just never winning (and therefore missing out on an important side of the feedback).

I haven't played Auro, so I can't speak with any authority and may well be wrong, but the way you describe it this sounds more like a progression system that allows incremental loss rather than the kind of adaptive difficulty that the OP was talking about.  Presumably going up in rank is a (meta?)goal of the game, so going down by one actually makes this more difficult (in the same way dying and starting the level/game again would).  It does sound like a good system, but I'm not sure it's what we're talking about.

37

Design / Re: Spell system

« on: February 24, 2015, 11:21:32 PM »

Sounds interesting, and great art style as always.

I'm having trouble imagining how the spell idea would work - if each spell costs 1 mana and you get 1 mana back per floor, that would seem to effectively limit you to one spell per floor, which seems like it would push the player away from the interesting gameplay of using clever combinations of spells.

Of the three options there I think I like the sound of the 'artifact' system best, although I'm not sure I fully understand your ideas for the other two.

As a general point, it seems like deterministic combat mixed with a small limit on the number of spells/items/artifacts that can be carried would result in fairly repetitive gameplay where you'd be forced to use the same moves again and again and again.  To introduce more variety perhaps you could instead do something a bit like Chaos Reborn where you have a 'deck' of spells that you draw a random hand from that determines your current options.  Your initial character customisation would be selecting that starting deck.  Or, perhaps you have some kind of Dominion-style-deck-building-thing as you go through the game.

38

Other Announcements / Re: Potentially hosting IRDC (Europe!) at University of Lincoln (UK).

« on: February 09, 2015, 08:32:08 PM »

Sounds good to me - I'd definitely try to attend (work permitting).  I'd also be up for presenting something - perhaps an updated version of the 'procedural generation in (real world) architecture' talk that I gave at the London one a couple of years back, if that would be of interest to anybody...(?)

39

Design / Re: Going beyond hack and slash

« on: February 04, 2015, 12:34:07 AM »

Interesting.  Not sure its a scalable idea in and of itself, but as you suggest, adding the mechanics to a larger scoped project seems promising.  Unfortunately I can find neither source nor dev blog so I'm a bit in the dark as to what those mechanics are. 

Off topic: its this kinda thing (The Inquistor) that upsets me a bit.  Let's face it, you're not going to make serious money off a niche of a niche unless it goes viral.   If you neither share the code nor blog the development process, its worthless other than an "it is possible" statement.  I guess the idea of giving back to the community is lost on some.

As I understand it, the game generates a murder victim, witnesses, murderer and motive and then simulates the various stages of the crime (i.e. acquiring the murder weapon, finding the victim, the murder, disposing of the evidence, somebody discovering the body) and records who saw what when.  He talked a bit about it on Twitter during procjam but I don't think he actually has a blog anywhere.  I would imagine that since it was made for a jam the source code is probably not really fit for public consumption (my own jam code certainly never is!).

Likewise off-topic: I'm not sure I really agree that making things like The Inquisitor is worthless unless you 'give back to the community' in the way you suggest.  Sure, it's nice when people share their techniques but ultimately unless you want to create exactly the same game again you're going to need to come up with your own way of implementing it anyway.  Simply proving that something new and interesting is achievable is a pretty big contribution to the community by itself, in my eyes.

40

Challenges / Re: 7DRL Challenge for 2015?

« on: February 03, 2015, 08:42:34 PM »

P.S.S Aren't the reviewers like a secret society or something, you guys are totally opening yourself up to bribes. On a completely unrelated note I just started a PayPal account....PM me, you know you want to.

Judges are just volunteers, any old idiot can do it*.  Also, I deeply resent the implication that I have, at any time, not been open to bribes.

*Provided you know the secret ceremonial handshake and have passed the sacred rite of Kahda-dorhn, of course.

41

Challenges / Re: 7DRL Challenge for 2015?

« on: February 03, 2015, 12:18:24 AM »

http://7drl.roguetemple.com/Reviews

Is that the final version of the page?  I thought that was just a temporary version while the reviews were being worked on.  The old version with tabulated scores was much better, in my opinion.

I was a bit disappointed to realize it's a 3 point scale, as the first page of reviews seemed to vindicate my view that 7DRLs are a waste of time.

yeah I've never found the numbers attached to the reviews to be much use. A category for roguelikeness is understandable but doesn't really help people find a decent game. The written comments are much better feedback as a developer and I've always been thankful for that aspect of the reviews of any of my games.

As a reviewer, the 'roguelikeness' category was a slightly annoying impediment. I don't like assigning number values anyway, but that particular category irked me. Having high 'roguelikeness' doesn't mean that it's a better game or more fun to play. Bah!

As another reviewer, I agree - in fact I think all of the scoring categories are a bit ill-considered (my personal most-hated being 'scope') and the criteria a little vague.  This year I may forgo the official judging process and just try to write mini-reviews of as many games as possible.

42

Design / Re: Going beyond hack and slash

« on: February 02, 2015, 11:20:49 PM »

I would put forward The Inquisitor from the recent procjam as a successful (if limited) attempt at a non-combat roguelike.  I don't see any reasons why the systems it uses could not be added to a larger roguelike (either in concert with combat mechanics or not) to make NPC interactions a bit more interesting.

43

Design / Re: Going beyond hack and slash

« on: December 27, 2014, 08:46:41 AM »

Maybe losing and just playing around should be fun? 99% of the time we spend in permadeath roguelikes involves losing and not progressing. Maybe we should make losing and not progressing fun?

In Roguelikes losing and progressing are not mutually exclusive - dying can be an important step towards winning if it teaches you something that you can use to do better in your next run.  I think part of what you might be identifying as 'fun' here is that Nethack is a more complicated game with more systems to learn, so there's more chance of a death contributing to your knowledge of the game and consequently dying feels like less of a waste of time (and so is less frustrating) than in a more straightforward game when you die for pretty much the same reason you died the last 10 times.

44

Development Process & non-technical / Re: Dungeon generator protoype

« on: December 26, 2014, 04:54:08 PM »

We're actually putting a lot of thought into keeping that feeling without using grids or turn-based game-play.

A common mistake when trying to do this is to simply make a game real-time but very slow-paced, which I think rather misses the point.  Turn-based roguelikes allow you to take half an hour deliberating per turn if you like, or you can keep hitting the keys and be the other side of the level in a couple of seconds - they are as slow- or as fast-paced as you want them to be at that moment in time.  Roguelikes can be killed stone-dead by an enforced slow pace (for example, those with too-slow animations).

To explain an idiosyncrasy of this forum: Krice is perpetually making posts, whatever the topic may be, about how his never-seen-but-always-talked-about twenty-year project is going to do everything much better than everything else that has ever been made.  In retaliation, Mushroom Patch has started making parody posts in the same style.  Taking anything either one of them says seriously is a waste of time.

45

Development Process & non-technical / Re: Dungeon generator protoype

« on: December 18, 2014, 11:25:08 PM »

Looks very nice.  The shafts of light in particular add a lot of atmosphere.  Are the meshes being generated fully procedurally or are they being assembled out of pre-made chunks?