I drew some robots for an animation some years ago...

Very cool!  :handthumbsupR:

Lemon Demon... is that the guys behind Ultimate Showdown of Ultimate Destiny? That was very cool too!

Not everything fits the OO idiom.

Listen to the BorisTheBrave, for he is wise!

If you happen to be writing in a very object oriented language, often the best thing to do is to split the processing between more than one object (and hence more than one method).

For example to implement a throw interaction in a fighting game you might have a method on one character for performing the throw and a method on the opponent for getting thrown.

The most complex cases are often those where one object has all the data but it's another object that undergoes state change. So, for example, if I take a moose-shaped cookie cutter and press in into my rolled out cookie dough I get a moose shaped cookie. This can't be implemented entirely in the cookie class because it doesn't know what shape is being cut out of it. But nor can it be implemented entirely in the cutter class unless it directly manipulates the internal data of the cookie class (which is poor style because it breaks modularity).

Time to try hacking bitmap collision into box2D

The thing about physics engines is that the hard part really isn't applying the results of collision, it's working out which precise collision has taken place. To do that with bitmaps you need to make simplifying assumptions, because you don't have any data for surface normals.

Box2D is a general purpose engine and doesn't play nicely with simplifying assumptions. You may find you get some rather odd results.

Oh btw, if any of you know any good reference or litterature on fighting games, architecture, dev tricks, etc, i'll definitely be happy. Really.

Dunno about "literature", but there's always KOF if you want to look at a working system.

holding them up to professional practices makes no sense

Even in a professional context (I spent ten years writing operating system code and related stuff) more comments are not always an improvement.

What is absolutely vital is clarity. Looking at someone else's code I'm happiest when the code itself is neat and clear and functions and variables are sensibly named. A small number of well chosen comments can add to that clarity.

But the flipside is that if code is messy and overcomplicated and poorly structured and all that bad stuff then even very extensive commenting won't fix it. In fact it can even make things worse as it cuts down on the amount of code you can see on your screen(s) at once.

Back on the subject of actual code reviewing, it does indeed work well but it's a lot of work. I'd imagine most indie developers can't afford the time. Even in industry, code reviews quickly disappear when deadlines are close or money is short!

When I got into game development as a profession, I was shocked that my solutions to problems were not only valid but sometimes even the accepted "correct" ways of doing things.

Also, computing changes over time. Sometimes the received wisdom concerning how to do something is actually bad because things have changed since Donald Knuth wrote the algorithm in the 70s (or whatever).

I don't have anything to show for it, but I wrote a pretty kickass UDP-based network layer and client/server structure this week.

An impressive feat indeed!

(Particularly if it isn't immensely buggy and doesn't fold when more than half a dozen clients connect. Like most of 'em do.)

Excuse me asking a hopelessly basic question, but what is RTTI actually for?

I'm finding it hard to imagine a situation where I'd want to cast something to a type not known at compile time. Because the code immediately following the cast is presumably written to expect various fixed types anyway.

I suppose multiple inheritance is an exception because of horrendous problems with "this" (I never use C++ though, so I'm only saying that based on other people's horror stories). Are there any single inheritance cases that actually achieve something worthwhile?

Come to think of it though, maybe it's just that the higher speed causes them to appear and disappear faster, resulting in a slowdown

Aha! Yes, that sounds very plausible.

Also suggests that your creation/destruction code could be slightly optimised. For example, push "destroyed" bullets onto a stack and just pop one when you need a new bullet.

[s]

If I use bitmapdata and copypixel to display them

This is already about as fast as you'll manage. Copypixels is very efficient.

In special cases you can go faster by making sure you're not using an alpha map or alpha merging, but I expect you already knew that.

Also, making them go anything faster than about 5 pixels per frame really, really slows the whole thing down.

I'm slightly confused by this. I'd normally move bullets by adjusting their coordinates. How does the size of the adjustment make any difference? This is worth looking into - you may have weird delays creeping in here.

Another area besides graphics which is worth looking into is replacing Numbers with ints. Doesn't always make a significant difference, but can be worthwhile if your maths:pixel ratio is high.

My current (AS3) game drops below 60fps with about 600 images on screen, though that's pre-optimisation so I expect I'll be able to get it faster.

The big problem is trying to work out what's the minimum spec I can support. The above is on my 2.4GHz machine with 1GB RAM, but I can't assume everyone has something that shiny.

I've had a lot of fun with Dinowaurs, but one aspect of the game's design I do find troubling is how quickly a destroyed village can be rebuilt.

In the vast majority of my matches (all but one and I've played about 16) whichever player destroys the enemy's forward village first will win. This is because it's much too easy for the dino that does this to immediately rebuild the village and heal up all the damage taken in the fight. The cheaper equipment available to the opponent helps them a lot in defending their second village (as Valter says that can be really tough to take), but they have almost no way to ever regain enough momentum to take the first village back because of the way it acts as a healing and rearming station for the enemy as well as giving them more income.

Documentation - Needs more stressing. For the length of any interview, it's almost your favourite thing in the world. Right behind the thought of having the opportunity to work for such an exciting company.

Be a little careful of this. If you're being interviewed by a technical person this kind of thing will likely set of alarms concerning your honesty level in the interview.

@increpare> Good luck with the interview.

I'd love to paste in the output...but this forum won't let me 

If it's fairly short you could always post it as an image.

Good stuff! Far too many 'counts of things' are stored in ints, even though you can't have a negative number of whatever thing is being counted.

Equally, one could argue that storing a count of something as an unsigned int is crazy if you can't have more than 2147483647 of them!

Depends a bit what you mean by "framework". I'd probably use either Python or Java for a project like this, depending on how large and complex its codebase is going to be and how many players you need to support. But I'm not sure they're "frameworks" as such.

Have you used CGI before? (Apologies if that sounds incredibly patronising, but for all I know you could be anyone from an ambitious ten year old to an industry veteran!) The basic principles are the same for an application of any size. If CGI won't do the job the only place to go is sockets. That will be a lot harder to get right, so avoid if you can.

The thing about design patterns is that one often comes across code or even entire projects where the programmer has made a huge mess and a design pattern would have improved matters enormously.

At the other end of the scale, there are programmers who are simply brilliant and devising ingenious code structures which save them work and make everything wonderfully robust.

Somewhere in the middle is me (and likely most other moderately experienced programmers), capable of coming up with basically non-stupid designs, but unlikely to find the best possible way to do every project first time.

Reading about and talking about design patterns is useful not so much because they're the perfect way to do things as because they have some chance of saving you from bad ways of doing things. (And in particular, from unstructured mess!)

I'm kinda wondering wtf is going on.

At first glance you do not appear to have defined the property "nail" prior to using it.

I would never say that about other people's setups, though sometimes I think it. we all prefer things a certain way, it's as simple as that.

You're right that the other guy was being an @sshat there, but I don't think the issue is quite as simple as you make out.

From my perspective the problem is that programming is an extremely rational discipline. So as a programmer, when you see someone doing something you know to be suboptimal it's a constant irritant. And if that person is another programmer it just makes no sense that they'd be stupid enough not to fix the problem.

In fact, though, this sort of thing can be an advantage in a corporate environment if handled well. Instead of flaming someone for their choice of editor or tab style or whatever, ask them to actively advocate it to you. "I like it," isn't useful. Tell me why you like it.

And then you need to set your ego aside and accept when the other guy's choices are good enough that you should be adopting them. Or maybe just accepting them as equally valid. (In the case of your example, I suspect Mr @sshat might have some trouble admitting he was wrong, unfortunately.)

For example: for a long time I couldn't understand why anyone would use vi in preference to emacs. Then one day I got to talk to a friendly vi user about it and it turns out that the main difference besides familiarity is touch typing. My typing is OK - and I can touch type a little - but this guy was really fast. For him, vi worked far better because he could keep his hands in position whilst using commands and moving the cursor around.

But when I ask someone why they use (say) pico as their editor of choice and they respond "because I'm comfortable with it", that still makes me sad. Because sure, it's rational to some extent, but if they're going to spend their life programming they should make the effort to become "comfortable" with something decently powerful. "I don't need any other features!" they argue. And then the following day I find them writing method stubs based on an API document by hand... they're simply not aware of the wasted effort.

But even if there is a good way of embedding them all easily, you're still going to have to instantiate them all individually

Ah, no, that's actually not the case (fortunately!).

Actionscript is a proper object-oriented language, so you can create an instance of a class using only its classname. This means that if your classes corresponding to your images have algorithmically deduceable names then they can be easily auto-instantiated. So if the player is in room 1 then the class RoomBackground1 containing roombackground1.jpg can be automatically instantiated and added to the stage.

and you can have access to anything you put in the library once you 'export [it] for actionscript'

Ah, sadly this is the same mechanism we've already been discussing... which doesn't help because the export process is manual. Thanks for explaining, though.