Messages

61

Design / Re: Damage reduction algorithm - looking for advice

« on: October 03, 2014, 07:27:02 PM »

The way that some games (I think POWDER, maybe some others) deal with this is to display your total cumulative armour score but when you get hit the game randomly determines which part of your body was struck and then uses only the armour value of the item you are wearing in the relevant slot.  This keeps damage reduction within a manageable range and if you think about it makes a lot more sense than the alternative; if somebody stabs you in the chest it's not going to make the slightest bit of difference that you're wearing a helmet as well as a breast plate.  The downside is that the AC rating shown to the player is a bit of an abstraction but higher numbers are still always better, so it's not super misleading.

62

Design / Re: Retinue - game design pitch

« on: September 28, 2014, 07:43:02 PM »

Because the game does not work the same way normal roguelikes do, maybe the best map is also not a dungeon with rooms and corridors, but something else?

Yes, I think it's a good point that I shouldn't try to force Roguelike traits onto it that don't fit purely because that was my initial jumping-off point.  Based on testing so far, I think it will be good to go for a variety of different kinds of spaces, some of which will favour certain types of units over others.  For example, the archer can attack a tile four tiles away in each direction, which makes them deadly in wide open spaces but useless in more cramped ones - I think that's good gameplay-wise and also thematically appropriate.  I've decided to exclude single-tile corridors from the generator, however; they are tedious to move through and too easy to defend.  I'm not sure about single-tile doorways yet.  I may do something like I did in a previous multi-character roguelike I made and make all doors and passages at least two tiles wide.

One question for the mockup, is vision intended to be pervasive, or have you just not implemented LOS yet?

LOS is implemented for light/miasma fields, but at present the player can see the whole dungeon and everything in it.  I haven't yet decided whether to have a 'fog of war' or not.  I'm erring towards it because I'd like to have exploration be a part of the gameplay but it could be a bit difficult/unfair if monsters can jump out of the darkness and potentially insta-kill one of your guys the same turn.  I'll put it in later to try it out - next I'm working on AI and enemy placement so I want to be able to see the whole map anyway for debugging purposes.

A possible solution for the tedium of having to leapfrog your units one at a time is to have a group movement mode that bunches up some number of units at the cost of being less responsive.  If you encounter an enemy you'll want to switch to moving one unit at a time, but once you clear a room you might want to select all the stragglers and tell them to move to a general area as a single command, which would still be evaluated by the game as a sequence of moves.

I'll bear this in mind, but I'm hoping it won't be necessary.  My main solution to the tedium of moving multiple units is to have small, dense levels (at present, only 12x12) so you won't need to be doing too much long-distance travelling anyway.  The 'move anywhere there's light' mechanic also means that you can theoretically get a unit from one side of the map to the other in a single move and you will only need to get the King to the exit to complete the level (at which point everybody else is assumed to make their own way to the stairs ready for the next floor).

Assuming the knight can kill each of the two nearby enemies with a single hit, can he just step forward and take them both out, or are you limited to a single attack per move?  If not, how do you decide which?

Yes, if he steps forwards he can attack both the Zombie and the Rock Monster in the same turn (although in this case he'd only actually kill the Zombie because he's not strong enough to kill the Rock Monster by himself).  This is intended; a core design goal is that a single move should be able to drastically tip the balance.

63

Design / Re: Retinue - game design pitch

« on: September 25, 2014, 10:55:44 PM »

Klaatu... Barada... Necktie...!

I've resurrected this thread since, after many months of sitting with my thumb up my butt (which made it difficult to type), I've recently started working on implementing this idea.

Here's a WIP screenshot:


The glowing white tiles show the player's light zone, the purple shows the enemy miasma, the sword icons (and the orange tint) show the player's combined attack pattern and the skull icons (/red tint) show the enemy's.  It looks a bit busy but I think it's not too bad for something displaying five layers of information on one map.

I haven't implemented too much of the actual mechanics so far, but I've got it calculating the light and damage fields for me and I can move the pieces around, so I've been doing a little bit of semi-manual playtesting against myself to try out the basic idea.  I think it has legs; the light/miasma mechanic seems to work quite well and getting into the right positions to combine attacks without leaving yourself open requires some forward-planning.  It has a bit of the chess-like feel that I was going for.

There are some things I'll need to consider carefully, however.  For instance, the single-tile doorways I currently have in the level generation provide interesting bottlenecks, although they are possibly exploitable in a bad way. In the screenshot above the knight standing in the doorway is effectively invulnerable; neither the Zombie or Gigas (rock monster thingy) in front of him is strong enough to take him out in one hit and they can't get into a position to combine their attacks.  There are possible counters to this, but I'll need to make sure that the AI is smart enough to use them, which could be tricky.  In mitigation, the goal of the player is to get their king to the down stairs as quickly as possible, so being able to stand still in a doorway may not be game-breakingly useful anyway.

When I've got something playable I'll stick it in the incubator or early dev section.

64

Other Announcements / Re: Procedural Generation Jam

« on: September 17, 2014, 06:41:52 PM »

Got my ticket, so I'll be along to heckle.

65

Programming / Re: Theory about popularity of languages

« on: September 15, 2014, 11:18:56 PM »

On a related note – and probably making a fool of myself in light of my previous comments  I'm considering starting with Java to write something for Android devices. Would Eclipse IDE be a good place to start? I don't know Java or C/C++ from before, the only language I've learned to any noticeable extent being Python.

I use Eclipse; it's OK.  There are some things I don't like about it but that's mainly because I'm more used to Visual Studio, if I had used it first I probably wouldn't be too bothered.  I've also tried out NetBeans in the past for Java, but settled on Eclipse I think mainly because it seemed more stable and the android emulation tools were slightly more advanced, although this was a couple of years ago so that opinion may be out of date.

66

Programming / Re: Writer needs Coder

« on: September 15, 2014, 07:30:44 PM »

I think everybody else has already covered the 'give up trying to convince anybody to make your game for you' angle, so I'll add some advice on learning to do it yourself:

If you find C++ too difficult then don't use C++.  It's a great language if you know what you're doing but it's absolutely the worst language to pick for somebody who (to be blunt) is too lazy to learn how to use it properly.  The good news is there are plenty of other languages and game making tools which are a lot easier to get to grips with.  Python is a pretty nice language for beginners and it does a lot of stuff for you that C++ doesn't - you'll definitely be able to learn it and use it a lot faster.  If you really can't deal with that then there are other things like Gamemaker out there that you could try.

67

Programming / Re: Visual Basic as gui engine?

« on: September 12, 2014, 10:46:12 PM »

VB.NET is the main language I use at work and I've also used it for a couple of non-game hobby projects such as the spriting tool I recently released.  So if you have any specific questions about it ask away.

So far as GUI goes, you have two main options; WinForms and Windows Presentation Foundation (WPF), which work in very different ways.  Of the two, I greatly prefer WPF as it's more powerful and much easier to maintain.  Its data-binding features make it very fast to set up a GUI with very little (or no) bridging code-behind.  On the downside using it effectively means getting used to XAML and setting up your architecture to be compatible with the MVVM pattern, so it's slightly less straightforward to get to grips with than WinForms.  There are also some things in it which you would think would be trivial to accomplish but that can require some complicated work-arounds.

I've used the pro and express versions of VS more-or-less interchangeably and express is good enough for most purposes.  It's missing some functionality to do with debugging and build instructions, although actually sometimes they've simply removed the interface for these things from the express version and you can still activate them by editing the project file.  If I remember correctly you don't need a Live ID to download, but you do need to register with one to carry on using the express versions after 30 days.

68

Other Announcements / Procedural Generation Jam

« on: September 04, 2014, 06:30:08 PM »

Saw this announced on Twitter yesterday, looks like it may be of interest to some people here:
http://itch.io/jam/procjam

69

Temple of the Roguelike / Re: Planning a mini 7DRL challenge for October.

« on: September 03, 2014, 08:48:27 PM »

Correct me if I'm wrong but it seems to me that "ordinary" roguelikes have no place in these 7drl's. I'm having "normal"  ideas but having looked at previous extremely weird (in contrast to normal roguelikes, not implying that weirdness is bad) entries or tech demos nullifies any interest at participating.

I don't think that's true.  Indeed, I think most people's first 7DRL is probably fairly 'normal', it's just that once you've shown you can make a roguelike in 7 days you tend to then move on to doing something a bit more extravagant the next time around.

70

Temple of the Roguelike / Re: Planning a mini 7DRL challenge for October.

« on: September 02, 2014, 08:47:37 PM »

Maybe.  I do have a 7DRL idea that I'm itching to put to good use, although October looks like it may be a busy month for me.

71

Programming / Re: Dungeon Generation standard elements

« on: September 02, 2014, 06:35:09 PM »

How about Up/Down Stairs (or some other more generic entry/exit tile)?

72

Early Dev / Re: Char - ASCII 3D roguelike

« on: August 16, 2014, 08:59:21 PM »

Looking at the preview images - do you actually need the gridlines at all?  It looks like it should be fairly easy to tell the tiles apart without them and it might look a bit cleaner, so maybe you could only show them for things like targeting a ranged weapon/spell, when more precision would be needed.

73

Development Process & non-technical / Re: Copyright and Licensing: Nothing to fear but fear itself?

« on: August 14, 2014, 12:03:16 AM »

That said, try not to be such a twit about saying GPL stuff is unusable for commercial projects.  If you want to write commercial closed-source programs, there is absolutely nothing that prevents you from using GPL tools to do so.  gcc, gdb, and the rest of the toolchain you need for creating software are all open source, and you can use them as much as you like to create things that aren't.

It goes further than that.  Reference: http://blog.milkingthegnu.org/2008/04/gpl-for-dummies.html and http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs.  One usage scenario would be to write your game under GPL as a fully playable but limited trial version, the proprietary plugin expands that into the full game.  This is perfectly legal using a GPLv3 section 7 exception clause.  As I mentioned in an earlier post, also possible is GPL client with proprietary server, where server can be an actual game server, a simple content server, or something in between.  There are numerous opportunities along these lines if you bother to look for them.

You could do all that, but is there any particularly compelling reason why you would?  In your scenario the heart of your commercial offering is proprietary code (which seems against the spirit of the thing) and you're having to specifically exempt yourself from part of the GPL to even do that, something which you can't do anyway if you're using anybody else's GPL code which doesn't include that exception clause.  Most likely, you can only do this if you're the original author of the whole program, in which case you're only making life more difficult for yourself by using the GPL in the first place, for no real benefit that I can see.

More to the point, there's no reason why you should be able to make money off of GPL code that other people have written.  But it does mean that the GPL isn't always an appropriate license to use.  To be clear; I think the GPL is great (and I have the Blender T-shirt to prove it) when it matches the goals and intentions of the people using it and they have made an informed choice to adopt it.  I don't think that is always the case and I don't think that pretending it doesn't have significant drawbacks so far as commercial development goes helps anybody.

74

Development Process & non-technical / Re: Copyright and Licensing: Nothing to fear but fear itself?

« on: August 13, 2014, 07:05:20 PM »

No, there's no reason for not to let anyone else to make money from the GPL code you wrote and the license does not stop that. It just states that if they distribute the program, they also have to distribute the source code. That's two different things. GPL is about making code free as speech, not free as beer.

That's technically true, but in reality it's a bit of a meaningless distinction.  You can charge money for a copy of a GPL program, but then the very first person you sell it to can also sell copies or distribute it for free (as in beer) to whoever they like, so it's not like it's a particularly brilliant business plan.

Edit: It's worth adding that this neatly exemplifies my concerns about people using the GPL not being aware of the implications.  Somebody looking into using the license might ask whether their code could still be used in commercial software and be told by a GPL proponent 'Yes, of course!', when that's about as misleading an answer as it's possible to give while still remaining entirely truthful.

75

Development Process & non-technical / Re: Copyright and Licensing: Nothing to fear but fear itself?

« on: August 12, 2014, 08:05:27 PM »

it also locks out people who write free and open software, but who don't mind commercial developers making use of it,

As above, commercial software developers can and do "make use of" GPLed software all the time, all they are not allowed to do is slap their own license on it.  It's really simple, if YOUR contribution is more important than the GPLed software, just write it all yourself, if you're leveraging GPLed software and just need a few tweaks, release your contributions, how hard is that?

Sure, as a commercial software developer you can 'make use of' GPL software in lots of different ways; you could print it out and turn it into a pretty hat, for example.  You can't make use of it as a library in your commercial application, however, which I think it's pretty clear is what I meant.  Also just because your own code might be more important to the overall enterprise, it doesn't follow that re-writing a GPL library is a trivial thing to do - otherwise why bother with the GPL in the first place?

people who are hobby coders ... making money off of their work

You're having some definitional problems here, you might want to sort that out.

No I'm not; you're having reading comprehension problems.  It's perfectly possible to be a hobby coder presently, but wish to retain the option to turn your hobby project into a commercial one in the future, which is the part of that sentence you hilariously edited out.  Many many indie developers have 'gone pro' in exactly this manner.

people like Eben who don't want to even look at the code for fear of exposing themselves and so on.

Yes, making licensing decisions based on unfounded paranoia is a great idea.

I didn't say it was; although I do actually condone Eben's decision there, for reasons that have nothing to do with 'unfounded paranoia'.  I agree that the risk of running into legal trouble by doing that is pretty small, but I think there's also a moral issue of respecting the original author's intent.  They may be using the GPL because they don't want their work going to help commercial software development in any way.  Probably not, but if you're being super-conscientious you might still not feel comfortable with using it even indirectly (without checking with them, at least).

So, to me, it seems a little puritanical and overlooks the massive grey area between open-source zealotry and evil money-grubbing capitalism in which rather a lot of useful software development takes place.

It doesn't overlook a thing, I'm aware of and sympathetic to the "I just want to give my software away with no strings attached" point of view, and I don't have a problem with it.  This view is shared by most of the Free Software community, it's just the community has decided as a whole that building a GPLed or otherwise copyleft software ecosystem is a Good Idea.

You may not have a problem with that point of view, but the GPL does because it explicitly prevents it.  Its whole purpose is to attach strings.  Which is perfectly fine by me if it's what people want - I fully support their right to release code they've written under absolutely any terms they like and there are far worse things than wanting to support a healthy free software ecosystem.  My only worry with the GPL is that sometimes people may use it as a 'default' open-source license because it's popular without fully thinking through the consequences, which might not match their intent.  I suspect that the decline in use of the GPL compared to more permissive open source licenses is partly because those consequences are being more widely understood.