Messages

1

Traditional Roguelikes (Turn-based) / Re: What "not-major-roguelike" do you think it should be considered "major"?

« on: August 28, 2013, 01:18:05 PM »

Cataclysm seems to have a fairly huge following, even if for some reason it hasn't caught up here too much. Definitely major, if you ask me

2

Early Dev / Re: Ultima Ratio Regum development feedback

« on: August 05, 2013, 08:18:29 AM »

Agreed that memorising some things would be nice! I just solved the first level of a ziggurat, but just thinking of "looking" at a tile, then pressing "a" for the block, and then remembering which blocks have what is a process that's a lot more involved than it could be.

Mousing over the blocks bringing you up a description would immediately solve this. Same for the inscriptions! Provided, of course, you've looked at them before perhaps?

3

Player's Plaza / Re: Games without monotony

« on: August 05, 2013, 07:42:12 AM »

It probably has to do with randomised generation of content. Spelunky's enemies are very limited (for each area). For the first one there's bats, spiders and humans. Items also are not randomised, and there's a handful of them that drastically alter gameplay. Thus, with such a limited, hand-crafted set of new items, you can really tailor how they are going to handle the player's experience.

By contrast, roguelikes have a ton of enemies that vary little (goblins, orcs and gnolls are really much the same in crawl, except for minor differences), and lots of weapons that also vary little. They don't fundamentally change gameplay, so naturally there's less options for them to become game changers. So roguelikes tend to have constant but limited progression. One more AC from the new Armour, a little bit more damage from a new weapon, scrolls that give you a little more attack or defence, and increase in a skill, etc.

I guess you could try randomising the effect of weapons and items in general, but randomisation would probably mean that you'd revert at least a little to the limited progression situation (some gloves that let you cling to wall for 1s, then gloves who let you cling to walls for 2s, etc). It would probably also generate items that are strictly worse than those you already have (which does not happen in Spelunky, since all items are simply different, and all of them useful), or items that are overpowered.

4

Programming / Re: Window managers and "printing messages"

« on: August 04, 2013, 02:46:26 PM »

Yes, that's how I'd do it - but I'm definitely not sure it's the best way

5

Programming / Re: Window managers and "printing messages"

« on: August 04, 2013, 10:06:42 AM »

You are indeed splitting the game logic. You essentially have a pre-attack piece of logic that checks for possible interrupts, which is handled in 3. The interrupts are sent out as events somehow, and the GUI state is updated to deal with player input for the interrupt.

After that, like I say back in step 5, you are in the usual game loop, which looks at the game and the GUI and draws it. The rest of the game attack logic is executed after the player has dealt with the interrupt GUI stuff. Once the game attack logic FINISHES executing, you do the rest of the game turn logic, which has other monsters execute and so forth

6

Other Announcements / Re: Losing interest in roguelikes

« on: August 02, 2013, 02:40:56 PM »

I'll concede the point, but I personally kind of enjoy this sort of meta-game. I like the idea that there's a little something that carries on from all my dead characters... and I don't mean my ghosts that are trying to kill me.

I like to enjoy the basic gameplay, and then between the games that use the basic gameplay, there's some bigger meta-game. I really like that feeling of involvement, progression and power to change the way things go

7

Programming / Re: Nausicaa Engine

« on: August 02, 2013, 08:47:01 AM »

Hahahahah, that's totally programmer art, to be honest. The sad part is it probably won't get better since I'm hopeless. Though by eventually making units and graphics fully accessible and moddable, I hope something neat might come out of it eventually

8

Other Announcements / Re: Losing interest in roguelikes

« on: August 02, 2013, 08:45:41 AM »

In defence of Rogue Legacy, some people HAVE beaten it with their very first character... so it is possible, but probably only insane people can actually do it.

9

Programming / Re: Window managers and "printing messages"

« on: July 31, 2013, 11:41:22 PM »

I'd even go as far as to say that you don't need to update any of the screen while the logic is going, though that depends on how you organise your main loop. I think you were talking about redrawing only parts of the screen in some other thread... but I think you could still only do graphics related stuff when you handle graphics, later in the main loop. I tend to do:

• Game update
• Draw
• Player Input

In this situation, when the events are sent, nothing is redrawn. The message box just collects information, and can mark itself as "dirty" or "needs update" when it receives a new message. Then, when you come to the Draw part of the main loop, the message box display is updated if it's dirty.

Let us know how it goes!

10

Programming / Re: Window managers and "printing messages"

« on: July 31, 2013, 10:02:58 PM »

I'm not sure about your game's specifics. I would say you can NOT queue events, and just handle them as they happen. Then as soon as you notify the EventManager of an Event, it gets handled by all listeners, and the code just continues executing past the .notify(event) call.

What I was saying is that you could have a EventManager.queueEvent(event) and then EventManager.handleQueuedEvents(), but I don't currently see any use for this.

What I would do in that situation is have the message box be the first pane to get access to input. Then, you'd do the turn logic, and shoot off all game events. The message box pane receives all of that, and updates what it needs to show, but doesn't scroll down.

Then, because the message box pane is getting the input first, and it's in a state in which it hasn't shown everything (there's a "more" prompt), it will consume all input. If it's the ENTER key (for example), it scrolls down. If it's not, it does nothing, but it still consumes the input.


Would this work?

11

Programming / Re: Nausicaa Engine

« on: July 31, 2013, 09:57:00 PM »

Some little bit of visual progress, finally!

This is using a subclassed GameManager called Planet 5521, which is the name for the crappy simple game I'm going to try to use as a showcase for this. GameStates are using a ProcessManager to which you attach processes. These define your main loop in each game state. In this case, I have a process which takes care of input (which propagates to the HumanView), and tells the HumanView to draw.

GameStates do not necessarily know about graphics. I want to be able to use GameManagers and GameStates for non-visual state. The MainMenuState receives the HumanView and manipulates its content pane directly to add a NGUISprite for the background, and two NGUIBasicButtons for the choices.

Next up is making the actual game state. I am thinking that all of the game's representation is actually going to be made out of GUI components. Units will simple GUI Sprites with some extra information. This should allow me to get all of the mouse events easily, which is pretty cool. I'm kind of worried that as the unit count gets too big, traversing all of the GUI tree every time the mouse moves might get pretty terrible, but we'll see.

I'm still wondering how exactly I'm going to handle the separation of model and view. In particular, I'm going to have units walking around, and they might have different weapons. I need a way to specify where the weapon is going to be help for every frame of the moving animation, where it's going to fire from, where it's pointing, etc. Part of this is going in the model, part of this is going in the view itself, and I'm just not sure how to work this out. Needs a little more thought

Code on GitHub has been updated.

12

Programming / Re: Game balance and leveling.

« on: July 30, 2013, 02:45:58 PM »

Thanks for putting these thoughts out Vanguard. I was struggling to write down how I felt about this, but you just described my favourite system as well!

13

Programming / Re: Window managers and "printing messages"

« on: July 30, 2013, 11:54:09 AM »

I have an EventManager class, which has a singleton instance, but other things can also be/have EventManagers. For instance, any entity in a game can be an EM, the game world itself can also be an EM for purely game related events (nothing that requires UI, etc), and so forth.

The Event Manager interface is simply "notify(event)", and "registerListener(eventType)". Every time you send a notify, it will check whether there are any listeners for that event type, and send them a notification that that event happened.

I've seen some people queue events and handle them explicitly in the loop, but that might not be necessary.

14

Programming / Re: Nausicaa Engine

« on: July 29, 2013, 08:28:50 PM »

Again, some really nice input! Thanks a ton!

I don't have a good time at all programming the graphics stuff, so I doubt I will separate too much of it. Either way, PySFML is available for a few platforms, and that takes care of that for me

I think right now my ancillaries are the Processes and perhaps the way I'm thinking of using some systems. All of the game related logic will be in systems, working as either event handlers/functional objects, that might or might not get called every game tick, and Processes are going to be more general and application oriented. They might handle such things as animations, checking quests (although this is a little bit more game logicky.....).



Yeah, Trystan, I've been reading and coding non-game stuff for quite a while, and it's starting to weigh on me. Though I really feel that this is going to help me structure every game from now on - not that I've ever completed one

Krice: from my limited experience, you can really work on exposing many things. I think King Arthur's Gold is starting to do it, exposing most logic for most items available in the game, though I'm not entirely sure. At this moment, allowing players to define animations and unit data for a 2d game is relatively easy, though you still need to hardcode a lot of effects. Still, you can essentially make games with the same mechanics, but completely different themes.

Other than that, entity systems are nice because for many 2d games you really can reuse components and systems without having to worry. All of the physics-related components, for instance, can be reused. If you have a flexible enough system for drawing things to the screen, a lot of the graphics code also does not need to be redone.

But if you go from a roguelike to a 2d platformer, then sure, a lot of code is going to have to be rewritten.

15

Programming / Re: Window managers and "printing messages"

« on: July 29, 2013, 07:12:53 PM »

Well, when you attack, everything should happen, the messages for everything that happens since your attack all the way to your next turn (e.g. monsters attack, etc) are going back to the message pane, and then it gets drawn. Once that's one, you can scroll up and down. I don't see any essential logic separation that needs to happen here.

However, let's try another example. Suppose than when you are attacked, you get the choice of parrying with your sword, or using your shield. Perhaps the shield is safer, but doesn't allow you to counter-attack, while parrying using your sword is harder but might allow a counter-attack. Thus, somehow, you should get a prompt between one of your turns and your next turn.

I guess in general, we're just talking about "interrupts". Some action is executing, but we determine that there's some input that can happen before this. That's a very interesting problem that I can't think of a solution to off-hand. I'll try to use events as little as possible, but I feel they are needed.

I assume that whenever your player does an action, it takes a number of ticks. The world stores how many are left to execute.

• Suppose you, the hero H, attack the monster M. You slash it but don't kill it. It takes 50 units util your next action.
  
• After 25 units, it's M's turn. He attacks you. The logic calls player.startAttack(M).
• player.startAttack(M) checks that there's a possible interrupt. It pushes a ShieldInterruptEvent.
• The GUI catches the ShieldInterruptEvent and creates an ShieldInterruptPane in the GUI, which contains the ShieldInterruptEvent .
• The game is now in the usual loop, but the ShieldInterruptPane is capturing all the input events and not letting them proceed anywhere else.
• Once the player provides adequate input, it uses the ShieldInterruptEvent to make a callback to player.finaliseAttack() with appropriate attack modifications.

You can probably have an Attack class that's being passed around the events and modified as it goes through these things?

The advantage of this is that the same way that the ShieldInterruptEvent is caught by the is caught by the GUI, it may also be caught by the AI enemy, and thus this method can also work for non-player Shield interrupts.

How does this sound?