1
Programming / Re: Smart AI vs Expensive AI
« on: June 23, 2014, 02:40:44 AM »
Are you looking to have anything other than reflex agents?
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Programming / Re: Generating a list of unique random numbers
« on: April 14, 2014, 02:40:27 AM »
Whoops. Python is disappoint.
3
Programming / Re: Generating a list of unique random numbers
« on: April 13, 2014, 09:08:53 PM »
random.sample() is a limited function, and it smacks to me of something someone put in to handle their own special case. The Python standard library has many of these sorts of things. There are arbitrary modules in there that almost do what I want, but are just unusable because whomever wrote them wanted them to work in a way that was unusable for me. Back to sample(), I've never had a sequence I needed to pick out a unique list of entries from. If I had to do this, it would be clearer IMO to write the code yourself than to call this function. Most of my random number usage was picking from weighted lists, and repicking was desirable. After all, you want 2x50 arrows sometimes, 1x50 arrows some other times, and so forth.
This is ludicrous. Python standard libraries are written in C- many of which have undergone pretty severe optimizations. I don't even like python for games, but if you're going to use it, you want to leverage the standard libraries as much as possible. Period. Even if a python library doesn't have exactly what you need, it's going to give you better performance to modify the results afterwards than to try and implement it entirely in python. Or you can go shopping for other modules that fit your purpose more precisely. At all costs, avoid coding in actual python as much as possible. That is the more pythonic approach.
Quote
Do you really believe this is a realistic example? Or is it one contrived to employ random.sample()? To me, it seems like the latter. Is there anyone out there other than me that's written loot dropping code, who would write it this way or use random.sample()?
If the OP is asking how to do it, that is sufficiently good enough reason to implement it in that matter or discuss such an implementation. The problem domain is unique to each individual's design goals, it doesn't matter if nobody has done it yet. There are a LOT of ways to utilize sampling for loot. Arguing against its use while ignorant of the problem domain is just silly. The OP isn't asking for advice on how to generate loot, he's asking for a specific algorithm which may be perfect for the game he's working on.
4
Programming / Re: Generating a list of unique random numbers
« on: April 12, 2014, 05:37:25 PM »Even though there is a built-in function, we might still want to understand how this can be implemented. Learning this algorithm will help us apply apply a similar technique to solve other problems.
Thanks Jaxian. Yep, that's exactly where I was going with this. Although I do appreciate your input, requerent.
I think for the most part I understand what you guys are saying, and I'll try some of your suggestions.
EDIT: Oh, and maybe in about a decade I'll have a working prototype to share with you all.
sorry. All I was trying to say is that if the algorithm isn't O(N), it's no good.
5
Programming / Re: Generating a list of unique random numbers
« on: April 12, 2014, 11:55:17 AM »
OMG PEOPLE STOP!
https://docs.python.org/3.5/library/random.html#random.sample
THERE IS A FUNCTION IN THE PYTHON STD FOR THIS EXACTLY.
https://docs.python.org/3.5/library/random.html#random.sample
THERE IS A FUNCTION IN THE PYTHON STD FOR THIS EXACTLY.
6
Programming / Re: Generating a list of unique random numbers
« on: April 12, 2014, 04:54:23 AM »Code: [Select]
random.sample(range(x), y)https://docs.python.org/3.5/library/random.html#random.sample
Pythonic enough?
Edit: Pythonic algorithms leverage the standard lib as much as possible. You shouldn't implement algorithms in python, just instructions.
If you want an algorithm, consider something more dynamic than generate->check->append, which has a potentially sun-burning-out run-time (esp in python). If bit-wise/mask solutions frighten you, try generating the numbers in increasing order. Just add a random delta to the previous value. If you need them shuffled also, you can run a shuffling algo in tandem with the number generation without ever needing to the traverse the currently generated list more than once.
7
Programming / Re: Testing Mazing algorithms
« on: April 11, 2014, 03:45:39 PM »
It's difficult to comprehend what experience each maze-type provides without testing them first. You need to apply LOS and explore them yourself to get an idea of what is reasonable and not.
8
Programming / Re: Multiplayer roguelike implentation through MySQL???
« on: April 09, 2014, 08:57:32 PM »A good precursor of that, "A game is just a database with a UI." Not to be thought of literally as database software.I don't know if I buy that quote. The database implies a model of the "nouns" of the game world, and some of the logical relationships, but doesn't tell the "story" so to speak. Your game should be more than just a UI.
The UI is the manner in which a player interacts with that database. The story is a part of the UI.
9
Programming / Re: Multiplayer roguelike implentation through MySQL???
« on: April 07, 2014, 11:28:09 PM »I attended a presentation at Desert Code Camp on Saturday where the speaker used a great turn of phrase about databases, that the database is "your data at rest". In the application program, your data is "at work". The database should be where it's stored when the application has downtime.
A good precursor of that, "A game is just a database with a UI." Not to be thought of literally as database software.
10
Programming / Re: Multithreading
« on: April 05, 2014, 01:41:40 AM »
You shouldn't thread separate processes, you increase the amount of extra work you have to do by orders of magnitude (mutex and sync) AND increase your overhead AND under-utilize threads AND your application won't scale.
The Thread Pool Pattern will serve you best. When you have groups of like data that are being processed by the same set of instructions, you can just loop through, queueing each one as a job. The Thread Pool will assign each one to the available threads as soon as one is available. In this way, you're always distributing the load over multiple threads. You could even offload processes to the GPU if you're ambitious. After that particular set of instructions finishes with the data, you can run another set of instructions to determine what to do next, offloading each job to the queue for threading. Data is always in synch, threads are always utilized, and you score extra bonus points if you optimize for data/instruction cache misses.
Do pathfinding calculations for ALL monsters at the same time. Then do decision-making for each at the same time... etc. etc. etc. It's a little quirky in a turn-based game, since you may want to change paths so that they are non-blocking, but if your game is engineered/designed well, then it's easy to deal with.
Oh- also, try and schedule jobs according to the cache line size. Say you're processing 4 ints of data each loop per entity, unroll it so that each thread processes the data for 16 at once (64 bytes)-- this lines up with the typical size of a cache line and is a simple way to improve performance.
The Thread Pool Pattern will serve you best. When you have groups of like data that are being processed by the same set of instructions, you can just loop through, queueing each one as a job. The Thread Pool will assign each one to the available threads as soon as one is available. In this way, you're always distributing the load over multiple threads. You could even offload processes to the GPU if you're ambitious. After that particular set of instructions finishes with the data, you can run another set of instructions to determine what to do next, offloading each job to the queue for threading. Data is always in synch, threads are always utilized, and you score extra bonus points if you optimize for data/instruction cache misses.
Do pathfinding calculations for ALL monsters at the same time. Then do decision-making for each at the same time... etc. etc. etc. It's a little quirky in a turn-based game, since you may want to change paths so that they are non-blocking, but if your game is engineered/designed well, then it's easy to deal with.
Oh- also, try and schedule jobs according to the cache line size. Say you're processing 4 ints of data each loop per entity, unroll it so that each thread processes the data for 16 at once (64 bytes)-- this lines up with the typical size of a cache line and is a simple way to improve performance.
11
Programming / Re: Multiplayer roguelike implentation through MySQL???
« on: April 05, 2014, 01:32:40 AM »
Don't use SQL or TCP. These are simply the wrong technologies for an actively running game state on a server-- regardless of the genre.
You want to roll your own UDP protocol so that you can buffer/manage data in a domain-specific way. You also want to manage data in a matter that is active and efficient- a generalized database is just not good for this- latency from cache misses and DB look-up will be so obnoxiously awful that it'll provide a worse bottleneck than waiting for input actions via ping/user decision-making/faux TCP determinism. Even in an RTS, where something like TCP would make sense, the overhead isn't really worth the reduced responsiveness.
You may use SQL and TCP for saving game states, but it is not appropriate for an actively running process/state.
Just use normal data structures in your application. Why would you want SQL anyway? You have to have an authoritative server to ensure AI behaves consistently and to prevent cheating, so... it's not like your clients are communicating directly with the DB (unless you can somehow ensure fidelity across seeds/RNGs, but even then- no cheat prevention)-- there's really no reason to use it apart from persistence... but even that's not a good enough excuse.
That said- SQLite is probably fast /enough/, but I still wouldn't misuse it.
EDIT:
Why don't you just have the clients and server communicate directly?
You want to roll your own UDP protocol so that you can buffer/manage data in a domain-specific way. You also want to manage data in a matter that is active and efficient- a generalized database is just not good for this- latency from cache misses and DB look-up will be so obnoxiously awful that it'll provide a worse bottleneck than waiting for input actions via ping/user decision-making/faux TCP determinism. Even in an RTS, where something like TCP would make sense, the overhead isn't really worth the reduced responsiveness.
You may use SQL and TCP for saving game states, but it is not appropriate for an actively running process/state.
Just use normal data structures in your application. Why would you want SQL anyway? You have to have an authoritative server to ensure AI behaves consistently and to prevent cheating, so... it's not like your clients are communicating directly with the DB (unless you can somehow ensure fidelity across seeds/RNGs, but even then- no cheat prevention)-- there's really no reason to use it apart from persistence... but even that's not a good enough excuse.
That said- SQLite is probably fast /enough/, but I still wouldn't misuse it.
EDIT:
Why don't you just have the clients and server communicate directly?
12
Programming / Re: I don't understand random seeds.
« on: April 05, 2014, 01:15:51 AM »
Alternatively--
dRNG for items/level/monsters etc, but a weighted RNG for combat, spells, gas propagation, etc.
dRNG for items/level/monsters etc, but a weighted RNG for combat, spells, gas propagation, etc.
13
Programming / Re: A guide to using a scripting language in games
« on: March 20, 2014, 08:39:33 AM »
There are typically 2-3 ways you can use scripting languages.
Interpreter-> code is interpreted line-by-line by a VM as it is typed into a console or from a file.
Bytecode-> code is first compiled into bytecode that can later be interpreted by the VM.
Just-In-Time-> code is compiled into bytecode just-before interpretation.
In any case, an interpreter would be linked by your program's executable.
In most cases, you'll want to compile to bytecode first, in which case you get error checking.
Plugging my favorite,
LuaJIT is unequivocally the fastest way to go. It comes very close to performing at native speeds and it includes an extension that parses C-style declarations.
Interpreter-> code is interpreted line-by-line by a VM as it is typed into a console or from a file.
Bytecode-> code is first compiled into bytecode that can later be interpreted by the VM.
Just-In-Time-> code is compiled into bytecode just-before interpretation.
In any case, an interpreter would be linked by your program's executable.
In most cases, you'll want to compile to bytecode first, in which case you get error checking.
Plugging my favorite,
LuaJIT is unequivocally the fastest way to go. It comes very close to performing at native speeds and it includes an extension that parses C-style declarations.
14
Programming / Re: I don't understand random seeds.
« on: March 20, 2014, 08:14:45 AM »Very often the RNG needs to be deterministic.
How so? I don't need that feature in my roguelike games.
Lol. Krice is such a troll.
15
Programming / Re: A guide to using a scripting language in games
« on: March 18, 2014, 03:24:29 AM »
Its poor design to compile data into your game. It's good design to interpret as much logic (game rules*) as possible. The main purpose of scripting is to pull as much data and logic out of your compiled binary.
* Game Rules include algorithms that govern how combat is handled, how AI select behaviors, what items do- etc. They do not include actual number-crunching algorithms (like searching the state tree).
Why? Easier to patch, update, localize, maintain, modify, balance, edit, serialize, network, implement visuals and create supplemental design tools for. Your game is no longer just the executable, but all of the assets, scripts, and data that surround it.
Why not? Fair amount of overhead. Complicates your program's architecture. Slower loading times and run-times.
How? For good experience, make your own parser! You don't need a formal scripting language. Just read lines from a text file and use that information in factory methods to set flags and and initialize a library of items, monsters, potions or spells. Then, you can have another text file provide parameters for level generation-- test it out. Create an interactive console that lets you add something to the library or choose the parameters for the next level to be generated. Scripting is just being able to pass information to a parser that modifies the application state accordingly.
After you're done reinventing the wheel, incorporate Lua into your program. You can shove SQL in there too for no-brainer serialization (though technically you can just store all of your data as Lua tables).
Why Lua? Because writing a parser is hard! Writing a parser with support for flow control is super hard! Lua is fast and easy... and very portable.
Oh, PS: Sandboxing in Lua is the equivalent of setting a flag.
* Game Rules include algorithms that govern how combat is handled, how AI select behaviors, what items do- etc. They do not include actual number-crunching algorithms (like searching the state tree).
Why? Easier to patch, update, localize, maintain, modify, balance, edit, serialize, network, implement visuals and create supplemental design tools for. Your game is no longer just the executable, but all of the assets, scripts, and data that surround it.
Why not? Fair amount of overhead. Complicates your program's architecture. Slower loading times and run-times.
How? For good experience, make your own parser! You don't need a formal scripting language. Just read lines from a text file and use that information in factory methods to set flags and and initialize a library of items, monsters, potions or spells. Then, you can have another text file provide parameters for level generation-- test it out. Create an interactive console that lets you add something to the library or choose the parameters for the next level to be generated. Scripting is just being able to pass information to a parser that modifies the application state accordingly.
After you're done reinventing the wheel, incorporate Lua into your program. You can shove SQL in there too for no-brainer serialization (though technically you can just store all of your data as Lua tables).
Why Lua? Because writing a parser is hard! Writing a parser with support for flow control is super hard! Lua is fast and easy... and very portable.
Oh, PS: Sandboxing in Lua is the equivalent of setting a flag.