Messages

16

Programming / Re: Legalized items/exp farming

« on: November 17, 2013, 12:02:28 AM »

Here's an idea: instead of "grinding", why not make your tedious chores involve (almost literally) "farming"?  For example, make the player do something to start a process -- plant a seed, prune a fruit tree, sneak a dragon egg into the giant eagle's nest so she'll sit on it, etc -- and then require that a certain amount of time pass before the benefit is ready to be picked up.  This could be a specified number of game turns, or even real-world elapsed time.  Instead of grinding with repetitive actions, the player has to plan ahead and think about multitasking -- what can he do while waiting for the prize.  You still accomplish your design goal, though, which I think I understand to be that you want the player to be able to guarantee a certain quantity of treasure is produced.

17

Programming / Re: seeking entertaining game with hackable SQL database

« on: September 06, 2013, 08:14:59 PM »

I think there are a few games that are built like this, not commercial games but maybe some personal projects like roguelikes.  Aurora4x, for example, is built right on top of an Access database.  Building database-driven websites is part of the course, but that'll come later.  Right now I'd like to simply show students how to peek at an existing data model in an interesting place and try to hack it with SQL.

18

Programming / Re: Persistent world? Yes or no?

« on: August 27, 2013, 10:50:00 PM »

I think it depends how many things you are procedurally generating.  If you are generating species of plants, types of boss monsters (like demons etc in Dwarf Fortress), civilizations at war and peace (like in Dwarf Fortress), then it's a waste if players CANNOT re-enter the world and experience those things in another way.  Each playthrough feels like a new chapter in the saga of that civilization or whatever.

On the other hand, if the only procedural generation is, e.g., the correspondence between obfuscated potion names ("swirly potion", "pink potion" etc) and their actual effects (invisible, poison, etc), then there's no reason to let them re-play it.  Nothing is gained but something important is lost.

19

Programming / Re: Damn The Rats

« on: August 27, 2013, 10:45:18 PM »

One thing might be that there's a cost per attack either of mana, or ammunition, or just "tiredness" from swinging that big sword.  And this cost increases as the spells get more powerful, the sword gets bigger, etc.  So the problem with rats at that high level is that they tire you out or force you to waste your ammunition... right before some serious enemy shows up...

20

Programming / seeking entertaining game with hackable SQL database

« on: August 26, 2013, 06:59:50 PM »

Hi all,
I'm teaching a database course this semester, and will be teaching the students how to use SQL.  One of the things that I think would be fun for them is to show them how to use SQL to hack into a game and cheat -- give themselves more gold or something.  Can any of you recommend a game that is build on a SQL database (could be MySQL, or Access or something else), which is accessible (i.e. not encrypted or hidden on a remote server)?

I'm thinking that a lightweight and graphical RPG would be better for this than something complex, just because I'm not sure all of the students are "hard core" enough to enjoy an ASCII masterpiece like Nethack.  But a game of any genre could be useful as a class exercise.

21

Programming / Re: Races and roles

« on: July 24, 2013, 02:04:05 PM »

D+D was a naked ripoff of (or "homage to") Tolkein, with classes and races taken right out of the Lord of the Rings.  In that context, allowing a player to play a dwarf wizard or elf barbarian would indeed be silly.  I did not mean to imply that those combinations would not work in your game, only to suggest that the idea of having races as classes might be a valuable one for simplifying your players' choices and imposing some context to the choice.  If any of your races can play any of your classes, then whatever backstory you create about the races is irrelevant.  The race choice has no context and there's no real reason to have more than one race anyway.

22

Programming / Re: Making a one dimensional roguelike interesting.

« on: July 23, 2013, 07:55:55 PM »

You could also do a little bit of a ballistics type game like Bowmaster where you are setting the angle and power of the spells you cast or arrows you fire, trying to take out enemies while they approach.

23

Programming / Re: Races and roles

« on: July 23, 2013, 07:45:13 PM »

In the original Dungeons and Dragons (at least I think it was original, I played it in the 1980s), the classes if I recall correctly were "fighter", "mage", "thief", and "dwarf", "elf", and "halfling".  It wasn't possible to make endless combinations of race and class.  Doing it that way rules out silly combinations like Dwarf wizards and Elf barbarians.  You might find that something similar works fine for your game.

24

Programming / Re: A major decison that I need to make regarging game-play.

« on: July 18, 2013, 04:39:45 PM »

I actually think the OP's idea is very good, but I would just have it less verbose.  Instead of a text description, make it look like a data readout.  You could build a mini-map of the cavern as they click the buttons to "go left" or "go right" or "split up".  Use little green dots to indicate where party members are, and place numbers or status bars next to each green dot indicating how many torches that person has left, and how much free inventory for collecting mushrooms etc.  Red question marks could indicate where suspicious noises or smells seem to be coming from.  If you want, program it so that each person separated from the party leader operates on their own, by AI, so the party leader has to infer where they are (perhaps by making them trail a string) and try to bring the party back together once the goal is accomplished.  It makes it almost like a little puzzle game within your RL game.

25

Programming / Re: how game developers are using stats + data mining

« on: June 26, 2013, 02:19:18 AM »

Noooooo, not R!!!!

I've recently been touch in inappropriate ways by R

...

Also, don't use R.

I actually offered a college course on data visualization with R this spring.  (Didn't get enough signups to go ahead with it though, so the minds of the young were spared this time.)

It's not for everybody, but it's got some very neat features and lots of packages are available if you're into data analytics and visualizations.

I've used it to program computer simulations for research papers, and it worked well enough to get my dissertation committee to sign off on my doctorate, but it seems to eat memory or slow down for some arbitrary reason when you do a lot of repetitions, so it's not the best tool and I'm looking into Python now.

26

Programming / Re: how game developers are using stats + data mining

« on: June 26, 2013, 02:11:30 AM »

I think data mining might be particularly valuable with MMOs where you want to understand the emergent behavior that you can't get from interviewing individual players.  EVE-Online does a lot of analytics that they share with the community, and I know they use them to try and figure out which ships are overpowered, how asteroid minerals might need to be balanced, what's going on with the in-game economy and so forth.

27

Programming / Re: New language

« on: June 19, 2013, 03:59:51 PM »

I will second Python.  It's very easy to learn, quick to code, and has some interesting differences from other languages.  I like that it requires precision but without a lot of extraneous typing (for example, the indentation of loops and other code blocks must be consistent, but you don't need lots of "{}" symbols that you'll lose track of).

If compilation errors due to mismatched braces are your biggest problem, then of course, languages that don't have braces are an obvious choice.

What I meant was, I like that a language is designed to force you to be precise.  As in, there's almost always one best way to do something.  (I am the exact opposite of whoever Perl was designed for.)  But the way that other languages accomplish precision is to be extremely wordy (like Java) and/or clutter up your code with lots of brackets, parentheses, semicolons, etc.  Python manages to be a precise language but is also very easy to write and easy to read.

28

Programming / how game developers are using stats + data mining

« on: June 19, 2013, 03:52:37 PM »

My academic work is in the area of business intelligence and big data.  I was browsing articles about the R language (at R-Bloggers.com) and came on this interesting link.  It's a presentation about the use of analytics the gaming industry called "Knowing How People are Playing Your Game Gives You the Winning Hand".

Obviously I don't have a game sophisticated enough for this, but there's some interesting ideas in it.  For example, you might try to build a model of user behavior to adapt the AI.  Or you might analyze where people have difficulties, or what interventions might prevent somebody from dropping the game.

Worth a look?  Get any inspiration?

http://blog.revolutionanalytics.com/2013/06/how-big-data-and-statistical-modeling-are-changing-video-games.html

29

Programming / Re: "Game state"-based game loop.

« on: June 05, 2013, 06:18:41 PM »

2. A finite state machine (where you only have one state at a time) does, not quite fit games. Instead I would have something more like a state stack. You push new states onto the stack and pop them off when they are done. You could go with something as simple as calling render() for everything in the stack or you could get a little bit more clever and only call render() down the stack until you reach a state to renders the entire screen. Similar rules can be applied to the other common functions.

I've been doing something like that with my Python roguelike projects.
The pyglet library's window object allows you to stack event handlers, and you can end them with "return False" to pass the handler down the stack or "return True" to stop it.  So for example I have a main game mode which catches "ESC" and opens a menu mode.  The menu mode is "on top" of the main game. 

Rendering routines go bottom up, so the game is drawn and then the menu is superimposed on it, blocking part of it from view.  Event handlers go in reverse.  The menu mode, for example, catches "ESC" and closes the menu, but sends "return True" so that the "ESC" handler for the main game mode does not re-open the menu.

30

Programming / Re: New language

« on: June 05, 2013, 06:05:10 PM »

I will second Python.  It's very easy to learn, quick to code, and has some interesting differences from other languages.  I like that it requires precision but without a lot of extraneous typing (for example, the indentation of loops and other code blocks must be consistent, but you don't need lots of "{}" symbols that you'll lose track of).  It's also the best interactive/scripting language I've seen in terms of running quickly and not blowing up your RAM.  By using C++ libraries you can optimize the speed quite well.