Messages

1

Design / Re: What makes a good strategy game?

« on: December 04, 2016, 12:16:04 PM »

Doules: if you haven't heard of it yet there is a pretty good open-source implementation of Battletech for computers. You can do multiplayer with friends, etc. Not being a huge fan of the game as you seem to be I'm not sure which rules version it uses or how faithful it is but from an outsider's point of view it seems to take everything pretty seriously. You can also play single-player against the AI, of course!

http://megamek.org/about

Oh, I love MM. It's pretty much the only way I can play battletech given where I live. They have pretty much every option from the current ruleset implemented, but not alpha strike (my personal favorite) or BattleForce (my second favorite). I still play it all the time, but I wish someone would write a working implementation of AS or BF...

2

Design / Re: What makes a good strategy game?

« on: December 01, 2016, 10:03:05 AM »

The zooming in rules are part of the BattleForce rule set found in the BattleForce boxed sets and now in CBT: Strategic Operations and CBT: Interstellar Operations. Pretty fun stuff. Honestly, my favorite version of BattleTech is the Alpha Strike Ruleset from, well, CBT: Alpha Strike. All the fun of BT in 1/4 the time. Remember how a lance on lance fight used to take 2-3 hours? Yeah, in AS you can fight a company vs. company fight (with some conventional elements reinforcing both sides) in the same time.

3

Design / Re: What makes a good strategy game?

« on: November 30, 2016, 01:57:13 PM »

A good strategy game is a game in which a competent player who is thinking at the same level of abstraction as the game will intuitively recognize the range of possible outcomes from an action. That's because the reverse will also be true. They can predict the range of actions which can produce a desire outcome.

Victoria II is a prime example of NOT to do this. 1) The layer of abstraction is... muddled at best. You're kind of the king of a 19th century power, except you have to keep track of individual populations down into the low hundreds (sure, you can ignore that. But if it's meant to be ignored, it should be hidden from the player). Furthermore, a lot of the knobs you can fiddle with (militancy and consciousness, for instance) don't have immediately self-evident outcomes, and certainly not intuitive ones.

A better example of this would be a game like Starcraft 2. Need more minerals? There's a clear and intuitive action (well, set of actions) that do that. The combat is similarly clear.

So what's the targeted layer of abstraction. I'm in a similar bind to you, in that I hope to expand Qaf to range from dungeoneering to kingdom building. But those are vastly different levels of abstraction. As a dungeon delver, I care whether that blow severed his weapon hand or opened up his stomach (it might affect whether that armor is salvageable or not). But as the captain of a force of 100 swordsmen, I don't care about how each monster is put down, only that they have been and at what cost to my own men.

The best implementation I've seen of this yet is in a tabletop game called Battletech. The rules themselves are clunky at times, but the implementation is beautiful. They have strategic combat rules where each counter represents a platoon of troops and damage is highly abstracted. But at any point in the game when two units are within a certain range of each other, the players can agree to "Invoke Battletech rules". The rest of the combat is frozen while these two units drop down to a highly detailed resolution model (it tracks individual missiles from ammo bin to impact point). At the end, you up-convert the units and resume the battle. I think you have to do something similar. I also think it should be a sharp switch (even display-wise) so that you 'reset' the player's abstraction level to the appropriate level.

TL;DR: Think hard about the layer of abstraction you want and make sure that no decision the player is making falls below that abstraction layer. That's what makes a good strategy game: good abstraction.

4

Incubator / Re: Qaf - A roguelike implemented in Python

« on: November 30, 2016, 06:38:21 AM »

Newest update to Qaf: https://github.com/jonathanabennett/Qaf/releases/latest

Version 0.1.1-Alpha

Release notes:

This minor point release addresses bugs found in the initial 0.1.0-Alpha release. Explanations below:

[Bugs]

• #2: Resolved logging import issues so that Qaf.log displays all module names.
• #9: Fixed corpse display bug by removing corpses from the game until I have implemented equipment. At that point, corpses will be added back in as equipment.
• #10 Fixed a typo in monster.Monster
• #11 Fixed a typo in readme.MD
• #12 Fixed crash on start by expanding compatibility to include all terminals with curses support, regardless of colors.
• #13 Fixed infinite loop caused unbound keystrokes.

[Features]

• Code refactoring. It may not directly impact gameplay, but it sure makes my life easier!
• Game over message. Now the game no longer directly crashes out when you die!

[Due in the next release]

• Improved pathfinding: Monsters will path directly to the player rather than pathing randomly to 1 of 3 tiles nearer to the player.
• Improved AI: Monsters will have the ability to 'cower' based on their health. Also, monster pathing distance will be based on monster AI.
• Basic equipment: permanently equipment equipment. Mostly for vetting how modifiers will get passed to attributes, skills, etc.
• Passive defense: Add a defense skill which makes you harder to hit.
• Implement basic hit location logic: Precursor to the intended combat model of modeling wounds to locations rather than depleting hit point pools.
• Expanded beastiary: Add several more monsters and monster types.

5

Design / Re: Supported movement keys?

« on: November 28, 2016, 12:55:23 PM »

I am considering user-defined keys, but that's a low priority...

In roguelikes it should be high priority, because there are different opinions about movement keys, including hjkl style. I think arrow keys with ctrl and other modifiers to get diagonal movement is actually quite nice. Not to mention that the game could have automatic travel options to help navigation. Something like "go to nearest item/door/object" etc.

I'm with Krice (Holy shit, did I just say that?)

YKU
H  L
BJN

That's my preference because I use VIM as my IDE. But my friends who grew up on Call of Duty would prefer WASD. Just set it up as a config file, just about every modern languages supports those in a simple library (you aren't coding this in bare C or Assembly, are you?)

6

Design / Re: Design of game action systems/architecture

« on: November 28, 2016, 10:39:43 AM »

Why is your targeting routine adding an event to the queue before it finishes? If the player cancels, then your targeting routine should return without ever speaking to the event handler.

7

Incubator / Re: Qaf - A roguelike implemented in Python

« on: November 28, 2016, 07:33:19 AM »

I've hit the 0.1.0-Alpha release for Qaf! Still very basic, but it's developing. I'd like to get some feedback, so please take a look at it.

https://github.com/jonathanabennett/Qaf/tree/0.1.0-Alpha

8

Incubator / Qaf - A roguelike implemented in Python

« on: November 19, 2016, 01:59:36 PM »

Hello, you might have noticed I stopped working on practicerl. Actually, you probably didn't, I imagine all of you have more important things to do than camp my github profile. At any rate, development didn't stop, it got shifted around and forked sufficiently that attempting to merge it back into the old repo would have been more trouble than I was interested in.

It has come a long way, and if anybody wanted to take a look at it and give me feedback, I'd love to have it. This is honestly the most complicated code base I've ever actively worked in, so I'm certain I've done several horrible things. In fact, I can think of a few horrible things I hope to be fixing once I finish the push to an Alpha release.

What works:
1) Level generation w/ the placement of monsters (Orcs and trolls at the moment).
2) Movement in all 8 directions using the traditional keys.
3) Monsters know how far away they are from you.

What doesn't work yet:
1) Combat. That will be my focus next week. I expect to have a playable alpha by Friday. Specifically, that means a single level filled with monsters you can try to kill who will also try to kill you. No healing, so it's more a question of how many you can kill before you succumb to your wounds, but then again that's most roguelikes so... excellent!
2) Logging. I attempted to create a log file, but it's failing to log for me and I'm not sure why.
3) Messages. They show up, but they all just overwrite each other, none of them go down to the next line. If anybody could help me figure out what I've done wrong there, I'd appreciate it.
4) FOV. I haven't even bothered yet because I'll be writing it by hand. I've read the implementations on roguebasin. I don't understand them well enough to rewrite them. And since this is a learning exercise, not a AAA game, I don't want to copy/paste code. I've worked up a mental representation of how raycasting works, but I had one of those for A* for years before I finally worked out how to do it. Fortunately, the A* stuff (particularly the recursiveness of it) should help in implementing this so I doubt it will take that long.
5) Error catching. If your terminal doesn't have enough colors, hard crash. If your screen is too big, it sometimes hard crashes. If you do something it doesn't expect, hard crash.
5) Saves

It currently has no dependencies outside of the Python Standard Library (several of the files import a library called attr, but none of those files get imported at the moment). Run python3 cursescolors.py and make sure you have all the colors (I haven't put any error checking or fallback for color-poor terminals) and then run python3 game.py to play. Press q to quit the game. This is known to work in Linux with an xterm-256colors terminal. Not tested in any other platform (well, that's not quite true. I know it doesn't handle color-poor terminals because I tried it in a plain xterm terminal). Once more, feedback would be greatly appreciated.

https://github.com/jonathanabennett/Qaf

9

Programming / Re: Dijkstra Maps... What have I done!?

« on: October 12, 2016, 07:40:26 AM »

Oh my god! Not only did that fix it, it runs about 100x faster.

But more importantly, because you tweaked code I had already written, I know how it works. I KNOW HOW IT WORKS!

For 10 years, I've poked at A* and Dijkstra maps without grokking what was happening well enough to implement it in code. But now i do. You, sir, are a God among men. May the @ always sing your praises until the heat death of the universe.

10

Programming / Re: Dijkstra Maps... What have I done!?

« on: October 11, 2016, 08:01:14 AM »

I see where you are setting " cell.visited = True ".
But I dont see where you are testing this to prevent running over those cells again.

But shouldn't I still check each one to verify that the current cell isn't a better path?

When I was using .visited, the map sometimes ended up looking like this:

Code: [Select]

9 8 4 5 6
8 7 3 4 5
7 6 2 3 4
6 1 1 1 3
5 1 0 1 2
4 1 1 1 2
3 2 2 2 2
Because I'm not using a priority queue, it just pops the first one, which leads to trails around the map.

11

Programming / Dijkstra Maps... What have I done!?

« on: October 10, 2016, 02:29:14 PM »

So, I'm attempting to use a Dijkstra map/heat map in my game (since that's obviously the easiest way to handle monster AI movement). But I've done something horribly, horribly wrong. In a 12x12 empty room, it takes 80 seconds to run. Since it's the heat centered on the player, it's going to have to update pretty much every turn. The problem is definitely that I'm visiting nodes too often (it takes 8,000 iterations to do an empty 8x8 room and I don't want to even consider how many it takes for a 12x12, but I estimate it to be about 41,500 or so). Below is the function (written in Python). I've pulled this out of a Map class, but before I try optimizing the data structure of the tiles or their storage, I want to cut the number of visits down to what it's supposed to be (a bit less than half what it is now if I'm reading the O() notation on Dijkstra's correctly. How can I fix this?

Code: [Select]

    def heatmap(self, source_x,source_y):
        l_open = []
        source = self.lookup(source_x,source_y)
        if source: l_open.append(source)
        start = True
       
        while l_open:
            cell = l_open.pop()
            cell.visited = True
            neighbors = []
            addrs = self.get_neighbor_addrs(cell.x,cell.y)
            for addr in addrs:
                c = self.lookup(addr[0],addr[1])
                if c:
                    if c is not cell and not c.blocked:
                        neighbors.append(c)
            if start:
                start = False
                cell.previous = cell
                cell.value = 0
                for neighbor in neighbors:
                    neighbor.previous = cell
                    l_open.append(neighbor)
               
            else:
                neighbors.sort(key=lambda x: x.value)
                cell.previous = neighbors[0]
                cell.value = neighbors[0].value + 1
                for neighbor in neighbors:
                    if cell.value < neighbor.value:
                        if not neighbor in l_open:
                            l_open.append(neighbor)

        return self.render(0,self.width, 0,self.height,True)
*The only changes made to this code was the removal of variables and print() commands I was using to track the output.

12

Programming / Re: DIY programming language

« on: August 29, 2016, 09:56:10 AM »

Java is compiled into a specific form of byte code

Yes, it's for java, not for any other language. At least I haven't heard you could compile some other language to java byte code and run with jvm (well, except Scala I guess?). So the java byte code IS java, just in a sort of half-ass-compiled way, slower than pure machine code.

Java byte code is Java only in the loosest possible definition of that word. You wouldn't look at an executable compiled from a C++ program for a Windows machine and say, "Oh, that was written in Windows. I don't do windows."

It wasn't written in Windows, it was written in C++, it just happens have been compiled against the windows environment. JVM is the same. It's an environment you can compile code against. I can't think of any reason you couldn't compile any language against the JVM environment (though I can think of several reasons why you shouldn't compile done languages against JVM).

JVM allows you to write once, play anywhere. That's why it's a "half-ass-compiled" sort of thing. The local JVM interprets the specifics of X vs. DirectX vs. iDisplay (no clue what apple calls their display suite) or various file system things or other interoperability concerns. It is slower, a fact highly unlikely to matter unless you've implemented particle physics in your game (in which case, don't do that. The world doesn't need 2 Dwarf Fortresses) because it's pretty damn fast. For reference, Minecraft is written in Java. It runs just fine speed wise.

13

Programming / Re: DIY programming language

« on: August 20, 2016, 08:08:39 AM »

If the videos are too 1980's for you, consider the book. It's available free online. https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start

14

Programming / Re: DIY programming language

« on: August 15, 2016, 01:01:54 AM »

Mind blowing is an understatement for that series. Every time I watch that video series, i feel like everything I knew about computers goes pear shaped.

15

Programming / Re: DIY programming language

« on: August 03, 2016, 08:32:20 AM »

Also, typed variables make reading your code almost infinitely easier because it reminds you what that variable is

I think these are equally easy to read:

a=1;
int a=1;

In both cases you know it's a integer variable. Type conversions should be strict (using conversion, not just typing a=b), I agree with that.

Sure, that's easy to read. But what about with precalculated value?
a = 5*15
// Several lines of code to set up other variables
return_value = a*2

Versus

int a = 5*15
// Several lines of code to set up other variables
int return_value = a*2

These are obviously intentionally brain dead examples because I'm not going to take the time to type fully functional code into my phone. But surely you can see a case this could happen.