Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 16 Jul 2004
Offline Last Active Jan 28 2015 11:51 AM

#5017511 Javascript / HTML5 best practices

Posted by smr on 04 January 2013 - 03:44 PM

First and foremost, since JavaScript is a programming language, the same general rules apply to writing efficient code:

  • Use the best algorithm for the task. Example, don't spend hours optimizing your bubble sort procedure when a quicksort will always be faster.
  • Use the features provided by the language's standard library, because they're probably written better than anything you'll create. Example, don't write your own quicksort. The standard library sort probably already does it.

Since javascript is a dynamic language, most of the same rules apply when optimizing:

  • Function calls to JavaScript are expensive. Calls to built-in functions may or may not be.
  • Dictionary references are expensive. Example: dictionary['thing']. If you need to access the same element more than once in a loop, assign it to a local variable before the loop then reference it with the variable.
  • Consider dictionary.thing to be equivalent to dictionary['thing'] as far as performance is concerned.
  • Functions are first class objects, and being first class objects they are no different than any other element in a dictionary on your objects: This line: "myobject.function()" can be considered the equivalent of "myobject['function']()" as far as efficiency goes. You can hoist this outside the loop too: 
    var myobject = new MyObject(whatever);
    var hoisted = myobject.function;
    for (var i = 0; i < 1000; ++i) {
        for (var j = 0; j < 1000; ++j) {
            hoisted(i, j);



  • "for (var i = 0; i < arrayLength; ++i)" is more efficient than "for (var i in array)" or even "for (var i = 0; i < array.length; ++i)" when the dictionary can be indexed sequentially.
  • Use built-in functions whenever possible, because they're often implemented in a low level language and compiled to machine code.
  • jsPerf is a great resource.
  • Don't optimize until you've profiled.
  • What is fast in Chrome might be slow in Safari, Firefox or Internet Explorer.

#5017288 Entity System

Posted by smr on 03 January 2013 - 05:00 PM

Right. Do what makes sense.


But I wonder what benefits there would be to implementing your UI elements as entities. I would think that UI elements are not a part of the game simulation, thus wouldn't be represented by entities within that simulation.


As far as your question about "traditional classes," component/entity systems /are/ traditional classes. They're just a specific way of organizing your relationships between classes. In my opinion if you implement OOP in the manner intended, most of your programs will tend to look like entity component systems in that you avoid deep hierarchies, keep classes small and single-purpose, etc.

#5016881 JRPG Dialouge/Chat System...

Posted by smr on 02 January 2013 - 04:48 PM

Here's how I store conversations a little Javascript RPG I was working on. It gets the job done, but it doesn't address your triggers issue:


    'start': {
        'text': "Hello! How are you today?",		
        'responses': [
            { 'text': 'Awesome!', 'next': 'great' },
            { 'text': 'None of your business!', 'next': 'rude' }
    'great': {
        'text': 'That's great! I'll be going now!', 'next': 'end' }
    'rude': {
        'text': 'I was just trying to be friendly. No reason to be a douche about it.',
        'next': 'end',
        'callback': function (conversation, self, other) { 
            self.updateHostility(other, hostility.HOSTILE);


Each conversation has a 'start' screen, which is the first dialog screen that will be displayed. Each screen has a set of possible responses, with each response indicating the 'next' screen when that response is selected. Additionally each screen has an optional callback that is invoked when the screen is shown. You may not have the ability to integrate scripts within your dialog definitions, but you could accomplish similar functionality without them:


'signal': 'set hostility hostile',

#5014814 What kind of optimization makes C++ faster than C#?

Posted by smr on 27 December 2012 - 01:43 PM

I think the most obvious answer here is that the .NET runtime itself is written in C++.
So you can just write code directly in C++, or you can write code in C# that uses stuff written in C++ under the hood.


I'm not really sure that's relevant. I could write a C++ compiler in python. Does that mean that the code generated by my compiler would be at least as slow as code running under python?

#5010723 NULL vs 0

Posted by smr on 14 December 2012 - 02:28 PM

Zero (0). Because what would Stroustrup do?

#5008290 jump table

Posted by smr on 07 December 2012 - 06:56 PM

I doubt it. If I were random, never. Theoretically this could be reduced by the optimizer if there were no random. The loop could be unrolled, from there it could eliminate looking the function pointers up because they are never changed, but I doubt it would go that far. Maybe if you made the array immutable. I'm no expert on the inner workings of code optimization though.

#5006816 Oldschool retro RPG - feedback and ideas needed

Posted by smr on 03 December 2012 - 04:49 PM

Looks great!

#5005138 IMGUI

Posted by smr on 28 November 2012 - 05:59 PM

Personally I think the immediate mode gui is not sufficiently simpler to implement over a retained mode gui. Their implementations are mostly identical, except that with an immediate mode gui you define your gui with more implementation. Why not take the additional small step to store the parameters of the gui in some structure? It's not that much additional work. From that point it's only another small step to be able to define your gui outside of code.

#5004621 PYTHON CARD GAME - objects, methods and design

Posted by smr on 27 November 2012 - 01:19 PM

In my opinion it's a good idea for your Hand and card implementations to know as little as possible (preferably nothing, if you can manage it) about the rules of the game. Hand should know only about how to receive and remove a card, fetch a card, maybe search for a particular type of card, and maybe some way to sort the cards (some players prefer to keep their cards sorted). Even sorting is a little tricky because different games may have different ways to sort cards. This can probably be accomplished by implementing some sort of "sorter" interface. You could create classes "MyGameHandSorter" or a "PokerHandSorter" or "BridgeHandSorter," for example. At that point you could either "MyGameHandSorter().sort(myHand)". You can even go through the trouble of formally declaring your interfaces, "class IHandSorter(object): ...class PokerHandSorter(IHandSorter)" but it's probably not necessary. Remember, python does duck typing.

As far as implementing every game rule as an object: It depends. Some rules are better left implemented directly into your Game class. Things like phases of a player turn, what can be done during the different phases, etc. might be better left in Game.

That being said, if you're making a game in the same genre as MtG, each card could have its own set of special rules associated with it. You should spend some time trying to classify these rules down into as many "rule types" as you can. From there, find a way to represent the data that is associated with these rule types. That data will be held in your Card implementation for the game, either directly in the card or attached to the card through some sort of CardProperties member on Card or something. I'd probably just stick them in Card. With MtG there are always exceptions, and these will have to be handled in your Game.playCard implementation. I wouldn't put them on Card, personally. Cards should just be data. This way you don't risk having to rewrite individual card implementations if you decide to create some specialized version of your game.

In fact, you probably won't be implementing a "playCard" method on game. You'll more likely be implementing what we call the command pattern. The player will build commands indicating what she would like to do, then dispatch those to the implementation of Game. The reason you have to do this is because in games like MtG, the opposing player has an opportunity to interrupt your action. You cannot immediately resolve a healing spell, for example, because the opposing player might cast an interrupt to prevent the spell. Another player might interrupt that spell somehow, or perform some other action (maybe even eliminate the player with an instant damage spell!) that affects the outcome. All these commands will need to be collected from all the players, then resolved by Game in the proper order and the outcome will need to change the state of the game, cards, and players. And finally those outcomes will need to be presented to the players.

I bet you thought you were picking an easy game coding project, didn't you?

#5004237 PYTHON CARD GAME - objects, methods and design

Posted by smr on 26 November 2012 - 11:21 AM

The problem is because you're passing card into the .pop method. .pop expects to receive the number of items off the stack you want to take. It seems to me like you're expecting it to put a reference to the card being popped into "card." I think you're trying to take a card from your hand, then place that card into the ally zone:

[source lang="python"]def playCard(self, card): if card.type == "ally" and card in self.cards: self.cards.remove(card) player.putInZone(card.type, card)# to use this:hand.playCard(hand.cards[0])[/source]

You might want to think about reorganizing a bit. Your Hand object is directly referencing allyZone, which tightly couples them together. Hand will not work if you decide to rename allyZone later, or want to use it separately from allyZone.

A better solution might be to handle this logic outside, in something like a Game class that knows the rules of how cards are taken from a hand and put into play:

[source lang="python"]def SomeGame: def __init__(self): self.graveyard = []; self.deck = self.initializeDeck() def playCardFromHand(self, player, card): if player.hand.hasCard(card) and self.playCard(player, card): player.hand.removeCard(card) def playCard(self, player, card): if not self.canPlayCard(player, card): return False if card.type == "ally" and card in self.cards: player.putInZone(card.type, card) return True[/source]

This would enable you to write different implementations of the Game object to have different rules, and also could help insulate some classes from changes in other classes.

For whatever reason I can't get the spacing to be consistent between edits.

#4966998 Best language to make 2d games

Posted by smr on 07 August 2012 - 07:11 AM

If your goal is to create a game, I would suggest you try Unity. Games written with Unity can be run on Windows, Mac, Android and iOS. Lots of developers are using it with great success.

#4965309 From java to c#

Posted by smr on 01 August 2012 - 03:29 PM

There are some efforts to develop a .NET runtime for Android, but the reality is that there is very little reason to bother with it. Java and C# are so similar that any minor benefit you get with the arguably nicer C# would be overshadowed by the burden of trying to work with a non-google supported platform.

The only good reason as I see it to use C# on Android would be to reuse a large amount of C# code that porting would not be possible or cost effective. In reality I don't see this ever actually happening because any code base large enough to not be candidate for porting probably wouldn't be well supported by the Android C# runtime anyway.

#4962296 Easy programming language

Posted by smr on 23 July 2012 - 10:48 AM

OK folks, I need to know what progam is the easiest to learn but still powerful enough to brimg out a top notch game.

Also the intended platform makes a difference. Are you targeting iOS? Then you probably want to use ObjectiveC. Android? Then you'll want to learn Java. Windows PC? Your options are pretty much wide open but some popular choices would be C#, C++ or C.

#4959689 Does any interest in the Go language still exist?

Posted by smr on 16 July 2012 - 01:19 PM

I have more than a passing interest in it, but I am not really going to play with it until there is a decent set of tools and a working debugger. Goclipse is a work in progress, and when it's most stable I'll probably toy around with Go.

#4952898 Java vs Python

Posted by smr on 25 June 2012 - 10:56 PM

Ever response in this thread has been, pretty obviously, biased

I'm not sure that's fair. While I said it is difficult to manage a large python application, that's my subjective opinion that I have formed after writing large python applications. As a language I am a big fan and I use it as often as it makes sense. Python is an awesome tool well suited to writing games as well as tools and in-app scripting. But I'd be a zealot if I ignored its weaknesses, the largest one being that is difficult to manage breaking changes in a large python application because there is no help from the compiler which in Java would be making sanity checks for you.