Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Oct 2011
Offline Last Active Apr 25 2013 09:56 PM

#4945986 How are you dealing with user input key bindings...

Posted by on 03 June 2012 - 08:25 PM

One of the simplest ways is to use a an intermediate format and then perform the switch on that. As a brief (and terrible) example:
// we assume your "game" keybinds are enumerations or static ints
// can be whatever
std::map<KeyBindings::KeyCode, int> keyMap = ...

// populate
keyMap[KeyBindings.Forward] = MyGameKeyActions.Backward;
keyMap[KeyBindings.A] = MyGameKeyActions.Left;
keyMap[KeyBindings.Enter] = MyGameKeyActions.Fire;
// ... etc. ...

// obtain the user key code from somewhere
KeyBindings::KeyCode keyCode = ....

// obtain the "true" bind from your map
if(keyMap[keyCode] != keyMap.end())
		case MyGameKeyActions.Backward:
		// etc.
// otherwise the bind doesn't map to anything
That way your internal logic never has to change, but the user is free to fiddle with the physical keys. You do have to do a value search each time you want to change something, but that's why it's simple and the user shouldn't be doing it too often to be a problem anyway.

#4944026 Rapid prototyping when making games

Posted by on 28 May 2012 - 08:25 AM

How can I save state after making changes?

Depends on what your game state is. As an example, if you were using Lua [to script] you could follow in Fable 3's footsteps and leverage Pluto (http://lua-users.org/wiki/PlutoLibrary) to, essentially, save your entire Lua "universe" to a flat file and be able to reload it on boot. There was an entire article written [by Fable's devs] on the subject but I cannot seem to find it amongst my bookmarks currently; I apologize.

The only thing I've really come up with is making every object serializable, and then saving the game as a whole in a file (kind of like saving a game like you normally would, but more verbose so things like menus and stuff can be reloaded if you're working on the menus, for example). Is that overkill?

No, that's the basic gist of what most "high level" language serialization libraries support; it's basic, works reasonably well for minimal effort, and is generally performant for small/medium loads. Just be careful and plan how you want to handle versioning.

Secondly, divide-and-conquer is an excellent strategy in situations like this. Per your example, why not save the "menu" (e.g. GUI) state in a separate file and ram the objects in another? This will be the case anyway if you use a dedicated GUI library (that likely comes with it's own designer + custom formats).

one reason I haven't gotten around to doing so yet is because I love my Visual Studio C++ debugger, and mixing C++ with a scripting language just doesn't sound fun to debug; but I'm going to get over that, don't worry)

Most of the popular languages have their own debuggers (and their own debug/error callbacks and symbols) you can use. It's true that debugging both can be somewhat aggravating, but the time (and convenience) you save from using a scripting language tends to be worth it. I was under the impression that Lua had a VS debugger plugin, but I don't know if that's still the case.

But in addition to that, are there any advices you have for rapid prototyping when developing a game (particularly when the primary language is C, C++, or any other non-dynamic language)? Any advices on clean/beautiful ways to integrate scripting languages (it's one thing to integrate a scripting language; it's another thing to do it well). Because I'd love to hear them.

As is mentioned in the link Teutonicus posted but I'd like to reiterate: network consoles are a beautiful, beautiful thing [when done right]. Since (obviously) the relationship between your game and your console is of the server/client persuasion, your console never needs to be "shut down" and can function as a mini-IDE if you need it to (save snippets, inject scripts, etc).

However, the biggest boon by far - and what I would say is one of the keys to prototyping (and is even mentioned by Hodge in his post, albeit indirectly) - is that you don't have to write [the console] in C++. C++ is nice a language for some things, but for a lot of others (e.g. GUIs) it's just a tremendous pain. With the advent of .Net and the JVM, scripting languages are now first-class citizens in their ability to seamlessly integrate with their "hosts" (C# and Java, respectively) and their associated libraries - use them.

As for "beautiful integration" between C++ and scripting languages ... most people's idea of that consists of using C++ as little as strictly necessary. If you're looking to boost your productivity for prototyping, porting (or "binding") your personal libraries to your language of choice can be immensely helpful (typically as a DLL extension). Just be aware that a lot of the binding libraries (such as Luabind and Boost::Python) work very well but you'll never get the kind of first-class experience you'll find elsewhere (there's no drop-in and "oh hey my language magically understands C++"). I don't say that to deter you, but it's just a fact that you need more time (than, say, in C# or Java) to see returns on your scripting investment. If you're looking for a "quick fix" to your scripting needs odds are you'll be very disappointed.

That said, if you're willing to put in the effort scripting can be very rewarding.

TLDR: Moar scripting, less C++. Also, no handwritten XML - your time is valuable, don't waste it closing tags.

#4939051 How to use classes in .jar?

Posted by on 10 May 2012 - 11:17 AM

Just throws how to use java (list of command line options) and in the end postgresql-9.1-902.jdbc4.jar: Command not found.

Ashaman's answer is indeed correct but with a minor punctuational twist - on Windows, classpath paths are separated by a semi-colon but on Linux you need a full colon, e.g.:

java -classpath .:postogresql-9.1-902.jdbc4.jar Main

I downloaded the Postogre JDBC library and compiled it against your Main, so it should work fine.

#4936105 Luabind inside a Shared Library

Posted by on 30 April 2012 - 09:37 AM

So, I've got Luabind et. al. setup properly and I'm trying to use it to fuel a binary extension module for Lua (i.e. a module for Lua written in C/C++). Unfortunately, it's been a long time since I've done anything C++ related and, frankly, I'm failing miserably. I've managed to get the following basic example running:

// helloworld.cpp
#include <iostream>
#include <luabind>

void greet()
	std::cout << "hello world!\n";

// int luaopen_[libname] is the entry point
extern "C" int luaopen_libhelloworld(luaState* L)
	using namespace luabind;


		def("greet", &greet),

	return 0;
The above, when compiled into a .so, works as expected.

require 'libhelloworld'
-- prints "hello world!"
Unfortunately, chaos sets in when I attempt to bind a simple class, e.g.:
class Test
		void say() { std::cout << "Inside a class!" << std::endl; }

		def("greet", &greet),
	   	 .def("say", &Test::say)
at which point the undefined symbols start flying as I try to load the library in Lua. Specifically:
  • ./libhelloworld.so: undefined symbol: _ZN4TestC1Ev
The literature on Lua binary modules appears to be archaic and almost every example I've come across is either in pure C or C-like C++ (e.g. the working example above). I realize the error is most likely caused by name mangling but I'm not sure how to resolve it. I investigated exporting symbols with GCC by using __attribute__((__visibility__("default"))), but that doesn't appear to have any effect. Some sparse documentation recommended appending -WI -E to the GCC arg list and that doesn't appear to have done much either (-E is just a preprocessor pass?).

The only other valid example I can find is the Ogre bindings to Lua (using Luabind) which doesn't use an entry point at all as far as I can tell. Unfortunately, I'm not entirely clear how they got away with that since anytime I try Lua - surprise - whines about not having a valid entry point.

I realize this should probably be elsewhere (like on the mailing list) but I was kind of hoping my problem was either obvious or a Luabind guru was somewhere nearby. Any help would be greatly appreciated.

EDIT: SOLVED. I forgot to define the constructor. *hangs head in shame* My apologies folks, this is precisely why sleep is important.

#4935612 Aesthetics... A pain in the butt.

Posted by on 28 April 2012 - 10:11 AM

It doesn't expand to a valid image link. Here's the picture, I uploaded it to my Photobucket:

Posted Image

My only advice would be to finish your project, or have a decent demo, before worrying aout such things. There's no need to give up on your dreams, but you do need to prioritize and come up with some workarounds for what you percieve as your weaknesses. Pillage Google for public domain/royalty free images and work 'em over for your backgrounds, they make great placeholders.

#4935544 Extend Java app with scripting and configuration

Posted by on 28 April 2012 - 02:51 AM

My question is, I want to hear your advice on how to do scripting, or which script language to use in Java?

Unlike C/C++, Java - and .Net - is less of a language and more of a platform via the JVM. Thus, there are an extremely large number of JVM languages that can interpolate with Java sans any explicit binding.

Lua, Perl, and Javascript are most prefered. Python is OK. Any other simple scripts that only require 10 minutes to learn are also OK but not prefered. The tool only needs one scripting language, not all the scripts mentioned above.

As far as I am aware, both Lua (LuaJ, et. al) and Perl (JPL) have bindings but aren't overly popular (I've never used either myself nor have I seen any questions regarding them). Rhino is the Javascript implementation in Java (and it is quite fast) and Jython is the Python version.

The script can handle and modify Java objects.

Most of them do it natively (e.g. there are no explicit bindings) courtesy of the JVM. As a side effect, they also have access to all of Java's libraries.

Java only. No need native executable. This is negotiatable but I highly prefer this point.

Most of them are fully implemented in Java or have the natives buried in an archive and you never need to mess with it.

Easy to integrate to my tool. I don't want to spend one day on compiling the script binding library.

That's more of a design problem as "easy to integrate" depends on your tool. That said, working with scripting languages in .Net or Java is nothing like dealing with the same in C/C++.

Native regular expression support in the script. Not a must but a hope

A lot of them do, and the ones that don't can simply piggy-back Java's implementation if need be.

I googled and found several candidates, but I'm not sure which one is best.

"Best" is relative to your project's needs. If you're looking for simple, then Rhino is an excellent choice (just make sure you download Mozilla's SDK and avoid the butchered abomination included in the Java distribution) as it provides a nice balance of speed and flexibility. If you want something more substantial then JRuby or any of the other myriad of OO oriented languages might be appropriate. For raw speed Scala or Groovy++ (not dynamic Groovy) is as fast as they come.

The nice thing about platforms like .Net and Java is that your scripting language choice is more about personal preference and less about which language's bindings will include the least amount of suffering in order to get operational. Download the archives, plop them on your classpath, and be productive.

#4932346 Standardizing Frame Rates and Handling Objects

Posted by on 17 April 2012 - 08:36 PM

So my first question is: How would I rewrite, or create a new, paint method that I can have executed immediately?

Use a BufferStrategy. It allows you to "blit" to an off-screen image like you would normally using an API like SDL and doesn't restrict you with Swing's obnoxious threading issues with regards to paint() and repaint(). That is, you can flip() your buffer whenever you like, thus controling the rendering speed yourself (for the most part, but it is an improvement since Swing tends to ignore repaint() requests at random). Furthermore, the surface is almost guaranteed to be hardware accelerated and Java will handle all the details for you. Here's a simple example: http://gpsnippets.bl...gy-in-java.html

Would it be a bad idea to put all the ArrayLists inside a Vector so that I can just loop through the vector and then each ArrayList so that I don't have to call them by name?

First, a Vector is just a synchronized ArrayList so there's not any particular need to use them. If you're having synchronization issues, I'd look at an alternate strategy (synch blocks, copy-on-write, etc.) instead to avoid any potential overhead.

Second, to answer your specific question - not really. I mean, it's not ideal or anything but you aren't going to fail miserably if you do it until you start generating a lot of objects. If it works well enough for you, more power to you.

That said, if you are having issues or want something that's a bit more scalable, I'd look into an alternate partioning scheme such as a basic quadtree or similar. The key issue is that most of those objects don't move - things like doors and static platforms don't actually change their positions. You can track an offset into your level and compute the "drawing" coordinates from that without needing to store those objects, drastically cutting down the objects you need to iterate over on a per-frame basis.

#4930449 Outside the box - different professions that would work within an MMO

Posted by on 11 April 2012 - 07:33 PM

I apologize, I meant to reply sooner but have been ill the past few days.


I wish you both well in your game/project - they both sound fun

Thank you, and likewise to you and yours should you also have something in the works.

In similar fashion to the previous idea jeffereytitan proposed of an arcane language you could implement a very basic programming like structure that the player unravels to make full use of the robotic possibilities. I must admit my mind is a bit aghast at thinking about the technical aspects in terms of design but I am probably overthinking it without study.

To be perfectly honest, I gave it a great deal of thought and simply couldn't come up with a mechanism to make it fun for non-programmers.

To programmers, the draw is obvious. In that case, a special API backed by a scripting language of some kind - say, Lua or Python or Ruby - rammed into a sandbox would suffice. You can get a lot of mileage out of a simple MVC framework, command queue, and state machine.

For everyone else, however, I was at a loss for what they might find interesting. The problem, it seemed to me, was that compared to a system such as the "arcane language" suggested above, robots aren't malleable or changeable in any kind of theoretical way. They're physical entities whose structure doesn't change on its own accord. A robot with treads and a sonar gismo will never start spewing flames or be able to swim, unless the player manually switched out the parts to make that happen. Furthermore, these robots aren't supposed to be capable of higher-order intelligence; they're just function monkeys. Thus, the "language" is simply a subset of verbs that a robot may potentially do, essentially making it a poor man's LOGO.

Now, keep in mind it's still not a bad idea. With some work and perseverance you can probably do some interesting things. However, the core issue in my mind was this: what part of this language's functionality cannot be represented by a UI? And the answer, frankly, is none. Not only that, but a well-constructed UI would likely be much easier to use and much faster to prototype various behaviors with; after all, a move() command - and thus the player - needs to be concerned with distance markers and measurements, but with a UI the player can just click where they want the robot to go instead.

Lastly, you might ask, "Kyan, the inspiration for the UI concept obviously came from Bethesda's AI dev kits" - and you would be right, hah - "so why couldn't you do what they did and sort of combine the two? Like, make a robot's reactions scripted but provide a UI to accelerate mundane activities? Obviously, you'd also refrain from plaguing the world with yet another terrible scripting language and read a book about Q&A instead."

The honest answer is that while my project seeks to make, and keep, crafting relevant it isn't really the focus. Designing a UI to be compatible for scripting by complete beginners and experts alike - things such as help pages and "useful" tooltips and intellisense - simply wouldn't be worth the effort. If I was designing for an MMO or some kind of crafting-specific game, however, I'd give the idea some serious consideration. I think, in that case, the ability to "share" various robot scripts would be mandatory and perhaps be immediately available upon part examination.

Anyway, this thread has some interesting ideas. I wasn't aware people were so passionate about crafting in general.

#4930423 Spell Systems with Depth

Posted by on 11 April 2012 - 06:33 PM

In my game I am creating a complex spell system. The grammar is a little different. You have this:

Base word, standard mana cost, damage type, damage
Type word, projectile, touch, target
Effect word, single target, aoe, multiple target
Mana word, modifies mana cost

Various other modifiers. You can mix damage types and various other things to make new damage types.

Aye, I plan to do something similar albeit purely UI driven from the player's PoV.

Yeah, minions are cool. Posted Image I think we just need to make sure that people can't create infinite minions!

First, I think [this] system is pretty interesting.

That said, my primarily concern is how you denote specific gameplay limitations vs. player-induced error. I'm uncomfortable with the idea of being new to a given function - such as, say, binding and/or raising minions - and, in my attempt to do so for the first time, run into a gameplay limitation despite the entire spell being intrinsically correct. As a cheap example, I have enough "energy" to summon a Mordor-sized army but, obviously, that would be unhealthy for the game so it is forbidden. What happens?

In a more general sense, I see the "error" side of the system being almost - almost! - as important as the successful, magic casting portion. I like that you see the wisdom in a percentage based success/failure system; that is, a player can potentially get some portion of a spell right and still technically have screwed it up. Progression indicators are important to keep players from getting easily frustrated and quitting. For this reason, I would shy away from using total - especially totally catastrophic - errors too liberally.

Lastly, a pregunta: have you thought about what gameplay elements (if there are any?) that will drive the error system after a player has learned a specific spell? It seems like once a player aquires a certain spell and manages to execute it correctly, there's no longer a particularly large chance they'll screw it up. Furthermore, with a generalized grammatical structure there doesn't seem to be a lot of learning once the basics are down. That's totally fine if your focus is exploration, but it seems like that marginalizes the error system (unless the error system is purely for amusement value, which is still a pretty cool idea).

Also, spells like this are the devil:

Summon external power (from nearby lava).

Target enemy by life force.

Send all energy.

Automatic power scaling (which is what send all energy correlates to) completely undermines your selective-energy system. Furthermore, "write once, fail run anywhere" type spells also undermine your grammatical concept (if they all take the same form, where's the grammatical exploration?).

As a random idea, you might consider introducing "action words" that are specific to each damage type and help shape what the spell actually does. That way you can add customization without needing to redo your grammatical structure. For instance, there is so much more than "burn" that you can do with heat: we visualize "heat" as a roaring flame but you can also use it to sear - concentrate heat on a specific series of points - or gently warm - spread a wave of heat over a wide surface area. Similarly, you can do a variety of things with water - from bludgeoning people with ice cubes (solid water) to smothering them with a bubble of pure H2O.

Brief, dubious examples:

# concentrate heat to create a mental lightsaber
# actual damage/effect depends on how much energy was expended

Summon external power (from nearby lava).

Target enemy by life force.


Send all energy.


# bludgeon something with ice cubes

# how many were created and how much they hurt depends on energy expended

Summon internal power.

Transform energy to water.



Target enemy by life force.

Send all energy.

Even with a small subset of words, you can potentially generate a lot of effects if you let the order matter. For instance, moving the "Freeze, Shatter" to after the energy has been sent could potentially denote an enemy that was frozen solid and then broken into many pieces (which sounds absolutely painful).

Anyway, I really like the original concept. Nice job.

#4929853 Outside the box - different professions that would work within an MMO

Posted by on 10 April 2012 - 04:30 AM

First, compositional gameplay is something that I have a rather rabid obsession with, so I can't help but approve of the initial example. There are a number of pitfalls, however, which I shan't go into but which JBadams' list goes a good distance toward preventing.

Secondly, I suppose (because I'm not certain if the idea is any good) I'll share my "pet" profession for a project I'm working on. It's a space-based RPG so I apologize if you wanted medieval only ideas. Anyway, the basis is [surprise!] building robots and is, unsurprisingly, called Robotics. I initally drew up plans for a complex scheme involving custom robots, user-created paths, and an obscenely unfortunate UI for directing robot behavior and then realized that only people with Ph.D.s in inanity could possibly find that interesting, so I scaled it back a bit and looked at what I really wanted. To use JBadam's list, I ended up with:
  • A profession must be useful.
  • Robots are useful as they are essentially free party members that can perform specific, albeit limited, functions. The key point of robots that I really wanted to emphasize is that they are expendable, thus the need to keep producing them. Being able to produce robots "in the wild" - as well as salvage various new parts for them - is a potentially excellent skill to have in a dubious situation.
  • In accordance with this, most robots take the form of "glass cannons" - they don't have a lot of hp. This prevents them from becoming a nuisance and removes the temptation to let robots play the game for the player.
  • It bears worth noting that my game is based around functionality differences. Thus, there's no direct "upgrades" for various attachments: it is concievable that a robot with a shotgun is more useful than one with a machine gun in certain circumstances.
[*]A profession should present players with some form of meaningful choice.
  • A core part of the "Robotics" profession is outfitting various robots with different tools. The term "robot" is a bit misleading: as described below, only vehicular machines are capable of movement, all the others are required to be mounted on a vehicle in order to change position. To expand upon that slightly, robots that aren't attached have two basic functions:
  • Vehicular robots without a top attachment are allowed to carry a single item from the player's inventory to some destination or perform vehicle-specific actions (like bulldozing, etc.).
  • All other robots are allowed to be set up as stationary platforms, either on the ground or on a wall.

Some carry weapons and are merciless fighters, some understand only the concept of plowing through walls, while others use sensors to find hidden enemies. Ideally, robots would be able to use most of the items that players can obtain, in addition to having access to various unique forms of sensing and movement.

  • An interesting profession should ideally offer different gameplay.
  • This one is a little hazy, if only because I don't believe that the player should be able to directly control the robots. The basic premise is that they are largely "fire and forget". You can give them rudimentary (emphasis mine) commands: patrol here, open fire, stay put, etc. and for the most part the idea is that they play a purely supportive role - they're not going to win many battles for you single-handedly (their power curve is intentionally limited) but they are, essentially, extra, expendable party members that can perform odd jobs you cannot or merely the ones don't want to do.
  • The point of the profession, honestly, is less about how you build robots and more about how you use them. If you're building a computer for gaming as opposed to, say, desktop-only work, you simply purchase more expensive/slightly different hardware; the basic process of construction, however, is the same. Thus, the "robots" created by the profession are utility robots - you don't get to make CP3O, that sounds rather involved. For now, anyway.
[/list]I completely twisted the idea of parallel computing in my quest for ease of use and created a simple concept based on the idea of multiple robots working in tandem. You essentially have a "robot core" which is, more or less, a processor that can recieve certain instructions (all of which are premade and presented via UI). As stated previously, the actual instructions you can give a given "robot" is dictated by the attachment you place upon it. So, a "robot core" that is given a missle launcher is able to understand all basic "weapon" commands in addition to, as an example, the command to "mercilessly carpet bomb" something.

As also stated previously, for a "fully functional" (movement + some activity) you need at least two robot cores: one to control movement and the other to do whatever you want. At the moment, my idea is that the maximum number of "cores" you can have is limited to 2-3 or so - after all, I want robots to be expendable and making "super robots" doesn't make a lot of sense with this goal in mind.

Standard Kyan-quality diagram to further muddle the issue:

Posted Image

For skill usage, it seemed to make little sense to impose arbitrary restrictions based on skill level. I felt a more practical metric was price - after all, newbies to a given hobby are never allowed near expensive equipment for fear they'll accidentally damage it. Thus, a given skill level allows you to use and apply attachments that fall below a specific price range. This naturally deliniates basic parts from specific, rare attachments since rare quality implies special attention and custom work is always more expensive.

Lastly, continuing with the idea of "choice" and "composition", any robot that hasn't been blown to pieces can be retrieved and all retrieved robots - or robots that currently reside in the player's inventory - can be decomposed into their subsequent "robot" parts. This lets you replace ineffective robots on the fly, provided you can do so in a safe manner. It's important to note, however, that you can't decompose them further into their basic parts - e.g. the robot core and whatever item you used to determine functionality.

I apologize for the length of this, I got a bit carried away.

Keeping in mind the general guidelines as posted by JBadams I am still very much interested in other profession possibilites or even working "classic/traditional" professions in such a way as to bring them inline with the theme of this thread.

*rubs eyes tiredly* Oi, I totally missed that edit and mildly misread the title when I started writing this, my apologies. *ponder* For an MMO, introducing limits per-person (to prevent turtling and/or abuse and reinforce expendability) and increasing variation (e.g. dividing generalized functions into specifics, such as "radar" into "track hostiles" or something) would work fine. Expanding the command system to include "meta" commands (e.g. certain combinations open up additional command options) for player's to find would introduce further activities for robots to execute. I suppose that takes things a little too far, as it essentially turns it into a mechanical variation of "monster breeding", but it's still a thought.

The ability to "decompose" robots can make for some interesting trading scenarios.

Furthermore, adding controllability to certain robots would probably be fun. I'm reminded of the aerial battles I had in WoW courtesy of Christmas presents and the races using the-racer-control-thing-whose-name-currently-escapes-me. Anyway, the point is that controlling robots can add a lot of fun, albeit generally not a lot of pure gameplay.

The original design was for a single player game but compositional professions are easy to expand; in this case, simply adding additional parts for the robots to the game would suffice. On the whole, compositional systems tend to be quite similar. The key concept is to ensure that the components that are added have a viable reason to be in the game. Part of the reason I was/am so obsessed with keeping the price down is to reduce the opportunity cost of less-than-optimal combinations. Furthermore, it's important to introduce actions that are robot-only.

Anyway, I figured I'd just throw that out there.

#4929740 Feasibility of implementing Line Of Sight gameplay in multi-player turn based...

Posted by on 09 April 2012 - 08:53 PM

I have also done some experiments and observations on this idea and the results is kinda divided.

If I may ask, what results were these?

Secondly, I have no technical advice. However, I think that instantaneous chat would actually make your game extremely enjoyable, I don't honestly see a reason to fear this. Some thoughts off the top of my head that may or may not be applicable:
  • Most people are terrible at giving accurate directions and passing on information.
  • Most people are also terrible at coordinating together. Games that implement such activities - like those with "raids", etc. - wouldn't be nearly so maddening if coordination alone didn't account for the majority of the difficulty.
  • Accurate observation is all about reference points. Good camoflauge works because the reference points for object differentiation are blurred or eliminated completely. Similarly, people get lost in the modern age with perfectly operational GPSes because they lose their geographic reference points and become confused. The easiest way to make information passing between parties difficult is to provide distinct views of a given situation with differing reference points. Separation such as you have gives you a significant amount of this built in; you just need to keep your views from being standardized.

Overall commanders will have all their sub-units' information have depending on the overall commander's staff ability. (Still thinking this one through but not related to my question)

Frankly, given that this is a computer game - and the entire point of commanders is to command the battlefield from the back - giving them all the information makes sense. However, you can preserve communication/observation errors from the frontlines - e.g. over Skype or whatever - by delaying the update of their information until after a given player's turn has been made or performing an update on a round-by-round basis. This allows commanders with good teams to prevail since, presumably, their teammates/members at the front are much better at discerning accurate information and acting appropriately than their opponents.

#4928537 Reading from a File [Java]

Posted by on 05 April 2012 - 11:34 AM

The issue here isn't obtaining the tokens, it is associating the tokens with their respective classes. Since each class is potentially different you need to deal with each on a case-by-case basis. Thus, as an extremely simple example, you'd want to do something like:
final Scanner read = new Scanner(new File("inventory.txt"));
String temp[];

while (read.hasNext()) {
	// whitespace is irrelevant
	temp = read.next().split("[ ]+");

	// first should always be the class name ...
	if(temp[0].equals("Sword") {
		// generally you'd want this in a try/catch block of some kind
		final int number0 = Integer.parseInt(temp[1]);

		// create your object, etc.
	else if(temp[0].equals("Shield")){ ... }
	// etc
You'll need to do these even if you leverage Scanner's regex capabilities, since you have no way of generically creating classes with correctly numbered and typed arguments on the fly. If you included the class name as the identifier you could potentially use reflection, although that is something of a dubious solution here.

If your items are implemented as simple POJOs I would use object serialization with ObjectInputStream instead.

To state the obvious, using a well-known format such as JSON or XML frees you from the ardous task of parsing the file directly, which may be helpful if you find yourself generating a lot of files with variable syntax.

Other than that, an easier method is to separate the file I/O from the object creation - read your data into a table (or Map) of some kind and create your objects only when you need them. Use some kind of ID system so you can query for specific item properties. That way, you don't have to neurotically parse the file on a token-by-token basis.

stringtokenizer is deprecated and you should use the split method of the String class instead.

While not the case here, StringTokenizer still has its uses in select circumstances.

#4927263 Video Game Architecture

Posted by on 01 April 2012 - 02:23 PM

I could go on here, hopefully I made my point.

Not really. Honestly, reading comprehension and some common sense go a long way. No, it's not a standard UML diagram but the entire thing is pretty self-explanatory at a glance. To name a few:
  • Items with "library" in their names are obviously not classes. They're libraries, most likely similar to those YogurtEmperor describes in his post(s) above.
  • Items with names like "threads" and "OpenGL (PC/Mac)" are features, not data. Features are grouped around the libraries they reside in.
  • The arrows are obviously dependencies. The controller system depends on the input system to tell it what the user has done. The utility library is potentially used by everything as befits something called a "utility library".
  • Base services are directly linked with the hardware - they deal with the services the hardware is expected to provide as opposed to an architectural view of a "service".
  • String importing is for internationalization.
  • Resource packaging is for packaging resources at release. Most people do not bother to fully package test or trial assets.
  • Red vs. green arrows most likely denote external dependencies, which is fitting given where they reside.
  • Sound sources denote the entry point for the scene graph to manage sound. There are plenty of scenegraphs/game engines that utilize sound in the graph itself (usually as a leaf or a separate node), kindly explain the technical reasons why this is unwise.
The entire diagram is an overview, far more detailed than you'd find in a number of well-published books. I'm completely lost what precisely you find objectionable.

Furthermore, "because I do it differently, neener neener" is never an acceptable refutation. This is a technical forum, use technical arguments. Looking at the screenshots of their project, C4 appears to have done quite well for themselves - I would think the OP would be very pleased to emulate those results even if it meant using an, apparently, "incorrect" diagram.

It is a nice project, slandering them without reason is uncalled for.

I am a busy man

So is everyone else, what is your point?

#4892981 Where spells can mean chemistry

Posted by on 11 December 2011 - 09:45 PM

Absolutely. Compositional based magic systems (whether you do it with atoms or actions or what-have-you) are incredibly immersive and interesting. On a side-note, I keeping meaning to write a post about something similar but keep getting sidetracked.

As for the issue of storage, it depends on what exactly you're looking to do. Frankly, for the most part I don't see much of an issue, especially if your system simply boils to:

Ea + Eb + Ec + ... + En = Spell

which means that your game actually only revolves around the end-products. End products contain all the functionality and, realistically, the elements usually only figure in as static numeric multipliers. So, technically, they're the only ones you need to store and can do some petty optimizations to "work backward" to get the formulas you need to produce them. Hashes, special ids, whatever. The end result is that your "elements" are nothing more than GUI fodder.

Of course, if you're looking at wholesale spell creation I guarantee you'll run out of valid spell ideas (e.g. ones you can balance) long before you hit any kind of computational roadblock.

A more interesting system is one where each element plays some role in altering the functionality of the spell in question. For instance, let Fire "light objects on fire" (duh!), Lightning "fry the target with electricity", and Chaos (X-Men to the rescue!) "make things really confused". For added craziness, let's say that the position of each element affects their overall contribution. So you'd get something like:

Fire + Lightning + Chaos = Target is on fire, electrocuted, and confused ... with emphasis given to being on fire.
Lightning + Fire + Chaos = Target is electrocuted, on fire, and confused ... with emphasis given to being a living lightning rod.
Chaos + Lightning + Fire = Target is confused, electrocuted, and on fire ... with emphasis on being confused to the point of not being aware that they are also on fire (and electrocuted).

which presents a more complex combinational problem. In this pattern, each element represents some kind of functionality. I find this more interesting because the spells are defined by the elements, not the other way around. As such, you need to traverse each element's combination path and apply each effect separately. The result of a path from A -> B != that same path from B -> A which is not true in the original example because the elements don't actually impact the end product in any meaningful way, even if order matters.

That said, aside from the obvious balance issues, I imagine the main "strain" on a console with any such system would be presentation. Consoles are terrible at choice selection and while you can sidestep the creation issue by being obtuse ("You should take your time at the Alchemy Lab painfully selecting each element by controller/hand and combining them intelligently!") you'd need an extremely fluid and intuitive system to allow for the player to quickly choose from the huge assortment of possible "spells" (or whatever you'd like to call them) that would be the result.

Another possible solution, since you did not specify game play, is to do something similar to Magicka (XNA) and abuse the possibilities of multiplayer; thereby cutting a given player's total spell choices without losing gameplay as the magic components are added interactions via players.

#4890544 Hotkeys

Posted by on 04 December 2011 - 06:37 PM

How do these sound? do other games implement anything like this? whats the general preference on hotkeys?

Keyboard users expect to be allowed to use the primary advantage of their chosen implement of gaming - lots of configurable bindings. As such, you can expect your users (whether you wish it or not) to be looking to rebind several of your keys to assist their playstyle. A lot of people are likely going to want to rebind the keys above 5 to something closer to WASD for convenience, as an example, if such is used to move.

Essentially, you shouldn't be looking to provide a set of keybinds based upon physical location except only as a starting guide to assist newbies. Keyboards aren't controllers, so you should first decide how many bindings you want there to actually be.

The most prevalent method of key binding involves utilizing the modifier keys to alter the bind and thus cleanly apply multiple functionality to a single key. Using just a standard keyboard of 104 keys and the "big three" modifiers (Alt, Control, and Shift) gives you around 312 possible bindings (the actual number will vary depending on the API you're using) without combination (e.g. [Control] + [Shift] + [key] or [modifier] + [key] + [key]). Obviously, the true number of "usable" keys is generally a bit lower but you are still left with an extremely large number of potential key combinations to choose from. Out of this can arise a variety of "priority" schemes for certain actions. Spells use Shift, "Important Actions" use Control, etc. It's really up to you how to organize them.

Your biggest problem, in a game that uses a multitude of binds, is cleanly mirroring said binds in the game's GUI (both in terms of feedback from engaging a key bind and the actual function the bind is linked to) and providing the means for the user to quickly alter them as needed.