Messages

1

Programming / Re: Realtime or semi-realtime turns

« on: November 03, 2011, 01:27:37 PM »

For semi-realtime I think Baldurs Gate gets more right than it gets wrong, but the lack of explicit turns is a definite mark against it (even though it's turn based under the hood). It does a very good job of keeping the flow going even with a large party though.

I've not played Dungeon Master, so I'll try and hunt that out. Cheers.

2

Programming / Re: Realtime or semi-realtime turns

« on: November 03, 2011, 12:48:05 PM »

I kind of agree with him about the fact that a real time roguelike is an oxymoron being not rogue-like as one of the most important factor in rogue was the possibility for the player to take his time before taking a choice.

Yes, having time to sit back and think is something I'd rather not lose, which is why I said 'semi-realtime' rather than full realtime. Part of my dilemma is exactly how much control to give the player and in what way. Pausing at any time is high on the list, and I'm trying to figure out how to integrate single turn stepping for really tricky bits.

3

Programming / Re: Realtime or semi-realtime turns

« on: November 03, 2011, 12:28:06 PM »

suggestions very welcome. Thanks.

This is a forum for roguelikes. You can talk about realtime games elsewhere.

How about some constructive criticism rather than sniping from the sidelines like you always do? Have you considered that 'semi-realtime' and 'roguelike' are not mutually exclusive, or does that not fit in with your exceptionally narrow world view?

4

Programming / Re: Realtime or semi-realtime turns

« on: November 03, 2011, 12:25:37 PM »

I'm biased, I like the  semi realtime/realtime, as you can see in my 7drl (tomb of rawdin) and non-7drl game, Cracks and Crevices. Both use the same mechanic. You get so many seconds per turn, or its implied you passed and everyone else gets a turn... makes for some interesting tactics imo.

Playing a few of the semi-realtime 7drl's is what's nudged me down this road. I can't remember if I played your though, sorry. :S

Did you ever consider/try adding a pause button for when things get particularly frantic?

5

Programming / Re: Realtime or semi-realtime turns

« on: November 03, 2011, 12:20:48 PM »

Most of the games dealt with these sorts of problems by making everything outside of combat real time, and everything in combat turn-based.  The transition would be handled by "interrupts", when a new enemy came into view of a character, time would stop and that character would get a chance to take a turn.  Generally if the enemy didn't notice the player and the player didn't do anything to attack, play would resume to real-time, otherwise it would continue turn-based after the interrupting player had their turn.  Some games had weirder systems, Space Hulk for example was a FPS squad-based strategy game, and it had a "freeze time" concept.  At any time the player could exit out of the FPS view and see a tactical map, where they could give squad members orders to move, cover an area, fire at will, etc.  But the freeze time was limited, so the player had to give orders quickly and then go back to the FPS view.

Yes, I have toyed with this idea. The thing I don't like is when there's a small/distant enemy who you're just trying to ignore and you keep being forced back into combat mode, when you really want to just walk away. And I still want non-combat commands (open chest, set trap, disarm trap, etc.) to be turn based, so it doesn't entirely fit.

It may be the best compromise though, so it's definitely something I'm keeping in mind.

6

Programming / Re: Realtime or semi-realtime turns

« on: October 31, 2011, 04:35:23 PM »

All good points, and I would urge you to try Albion so you can see why I'm trying to speed things up.

I think it'll definitely need a 'panic button' where you can hit enter or something and halt time so you can think about your next move. I'm not against people agonising over every turn if they want to, but I want easy battles and actions (like walking from one side of the room to another) to be quicker and smoother.

Perhaps an automatic stop-time if a monster X levels above your party comes into view would be a good idea too...

7

Programming / Realtime or semi-realtime turns

« on: October 31, 2011, 02:01:11 PM »

Has anyone around here experimented with realtime or semi-realtime roguelikes? I've played one (a 7DRL IIRC) and the forum search comes up with a couple of multiplayer ones, but I'd like to get more thoughts on how a semi-realtime roguelike would be for a 'proper' game.

At the moment Albion ( http://roguetemple.com/forums/index.php?topic=1330.0 ) is a bit too slow, due to it's party-based nature. I'd like to speed up the tedious moving aspect but without loosing the turn-by-turn nature and fine grained control.

Thoughts (especially from people who've played Albion) and suggestions very welcome (unless your name is Krice). Thanks.

8

Traditional Roguelikes (Turn Based) / Re: ARRP 2010: Albion

« on: September 29, 2010, 09:03:07 AM »

Any relation of this to an old computer RPG Albion? Not sure how well known is that, but I don't like two games to have the same name...

It's just a coincidence, I've never heard of that game before I'm afraid. 'Albion' is a very old name for England, so it pops up a lot in fantasy RPG settings (IIRC the world in Fable is called Albion too). Albion was just a placeholder name originally but I've got quite attached to it, so it may or may not change in future.

In terms of games Albion is largely inspired by Exile, Baldur's Gate and Shining Force.

9

Traditional Roguelikes (Turn Based) / Re: ARRP 2010: Albion

« on: September 24, 2010, 09:16:07 AM »

Thanks guys.

I found the movement system quite annoying when there was no monsters present,  as I would like to move freely with out the step countdown.  I also think that grouping movement should auto switch to your leader (when no monsters around). 

I've been through a few different versions of the movement, and I'm still not entirely happy with it, yet I haven't figured out a way to make it quicker to use without sacrificing the strict turn-based approach. The grouped movement is currently a good compromise, but it could do with being slicker. Suggestions are welcome.

I also think that grouping movement should auto switch to your leader (when no monsters around). 

I'm not sure I understand what you're after here? Related, I'm not sure yet whether I want the user to nominate a 'party leader' or not. Later you'll be able to swap in/out members of your party, so the concept of a leader might not make sense. OTOH, having your leader grant certain bonuses based on class (eg. nominating a warrior as your leader makes everyone hit harder) could add some interesting tactical choices.

10

Traditional Roguelikes (Turn Based) / Re: ARRP 2010: Albion

« on: September 23, 2010, 04:44:30 PM »

Thanks. Adding 'proper' graphics to a roguelike is proving more time consuming than I had planned, but the results are worth it IMHO. Still lots to do before it's a complete game though...

11

Traditional Roguelikes (Turn Based) / ARRP 2010: Albion

« on: September 19, 2010, 10:33:17 PM »

Albion is my attempt at a graphical roguelike, and I've been meaning to post it up here for a while, so the ARRP gave me the push I needed.
 

 

 

 
More information on the game page here

Or try the direct link to play the game here.

It's mostly mouse-based at the moment, but the numpad works for general movement and simple actions as well. Everything has tooltips so hopefully things will be reasonably obvious how to play.

I've been working on this about a year, off and on. It's playable and should be bug free, but there's no win condition and the actual mechanics are pretty simple at the moment. And it's hideously unbalanced at the moment as well, since I'm still trying to figure out how I want my basic combat equations to work.

Feedback of all kinds greatly appreciated. Thanks.

12

Programming / Re: Version control

« on: June 28, 2010, 09:02:09 AM »

One thing fundamentally different with svn and git is that svn branches are just copies of the directory (and tags are read-only copies), whereas git (and I believe Mercurial also) repository is a "pool" of commits and branches + tags are just pointers to certain commits. This leads to smaller repo size and super-fast, very cheap branching.

You mean "super fast and cheap branching" in svn, right?

If you have a large project, copying the files to make a new branch in svn can take some time. Also, at the same time you double the disk space usage.

To make a branch/tag in SVN, you do indeed 'make a copy', but you do it directly on the server with a copy command. This makes it near-instant and doesn't require any additional file space since internally it's just marked as a copy of an existing revision.

If you're making branches/tags by copying a local workspace and checking it in again, you're Doing It Wrong.

13

Programming / Re: Version control

« on: June 22, 2010, 10:33:08 AM »

At the very least it's easier than manually copying and zipping folders.

Really? Started looking at hundred page manual of CVS and when I saw linux-like command line stuff I stopped right there. Easier?

Firstly, don't use CVS. It's old and creaky - Subversion (SVN) was written to be a modern replacement for it, so use that instead.

If you're on windows, ditch all that command line crap and install tortoiseSVN: http://tortoisesvn.net/node/347

It puts all the svn operations on your context menu, so you just have to update / commit with a single click. Once that's installed read tortoise's help and it'll show you how to set up a repository and working copy (again, all through the context menu, no command line required).