bahahahaha eat those wordsssss! Man, having permanent proof that we’re idiots out there is very humbling ;)
The other day a friend of mine pointed out: on Simon Pegg’s show Spaced, his character said something like all “odd-numbered Star Trek movies suck”… guess who would later star in an odd-numbered Star Trek movie! ;)
I think the last thing we need is another freaking API.
What I think should be done is giving acess to low-level OS APIs, if the browser detects (somehow) that the application is safe.
Really the “cross platform” problem of fragmentation is already and always going to be there as long as we allow competition (and of course we should). I mean, what’s different than having to install Chrome or Firefox or IE or any of the other browsers which are just applications. I suppose maybe Windows 8 already has some of this as you can build “native” apps for the app store using HTML5.
Yeah, sure, we will always have fragmentation problems with browsers, but at least they try to implement the same API.
It wouldn’t bother me having to install a “game browser”, what would bother me would be having to switch between browsers because a certain game doesn’t supports the browser I’m using.
That’s what’s, for me, the biggest feature on Steam: Unification. All games I want are probably there.
Javacript is probably as fast as Python or Lua, or even faster in some cases.
But no scripting language is at par for hand optimized C or C++ code, in regards to performance.
I’m pretty sure Matt mentioned that some entities have more than one “view”, so, I think that wouldn’t make much sense. @richtaur@geoffb, can you clarify that?
It sounds like Djinn’s scenegraph doesn’t have much to do with the “industry definition” of this term, as it looks like it’s used more in 3D graphics.
But what does Djinn’s scenegraph do exactly, and why do you need it?
A scene graph is simply a way of organizing drawable objects in a scene. A 2D scene graph is a lot like the DOM, if you’re familiar with that. It’s basically a tree structure made up of nodes. Each node can have N children, which are also nodes and can have their own children. Again, much like the DOM. Think of the nodes in a scene graph as div elements in an HTML page. For the sake of argument, let’s say the root of the DOM is document.body. This element contains some number of child divs. Each of these divs have their own display properties, relative to the root. So, a div with style.left = 10 and style.right = 10 would be 10 pixels from the top and left of the parent. In turn, each of these divs can have any number of children with properties relative to their parent.
In Djinn, a View is similar to a div. When we talk about multiple Views per entity is just means that some entities have a root View with several children underneath. Our “Dolls” are a good example of this: each “part” (head, arm, leg, sword, etc) of a Doll is its own View, but they are all part of a root View which can be moved around the screen while the children maintain their relative positioning.
This tree structure is pretty powerful and has several advantages. One of the main advantages is that any View can be set to invisible which will cause the renderer to skip rendering of that View and any of its children. Another is that scaling and rotation effects on a View also affect its children.
The thing with PGC is that it never feels as good as hand-created content, and I think it never will
I’m up to the challenge!
Well, good luck then.
I’m sorry for being pessimist, but I think you’ll fail.
It’s totally possible to create algorithms which can create “decent levels”, but designing things isn’t just a programming matter, it’s a way deeper problem.
Computers just can’t design things. They can engineer, but designing requires something else, something like…
A human brain, you know? Watson is, as far as I know, the closest you can get to human intelligence.
Still, it mixed up browser cookies with “real” cookies, and, suddenly, Watson’s computer knowledge base was inflated with recipes.
Of course, using tiles makes it easier for a computer to “fake” level design, but humans can do way more than that, right?
Typing code has never been a time bottleneck, so there isn’t much of an advantage to writing ugly code.
Yeah, I know, but I’m not talking only about typing.
If typing code is that fast, shouldn’t it be faster to type a bunch of crappy code instead of spending time thinking about how to architect a system, and how to make it accept different types of input, and making it handle edge cases and all that stuff?
As we learn more about making games, I’ve noticed that @geoffb and I both want conflicting things: we want to move faster, but we also want more flexibility and abstraction (which takes time). When we hard-code things we are able to move quickly, but sometimes we move so fast past it that we don’t take the time to see if the system we’ve built is really the one we wanted.
Well, then you can just rewrite it.
Sure, it will take some time, but you’ve already saved timing hardcoding things instead of making generalized system, right?
A good example is AWL’s monster behavior script system. Right now you can only attach a single behavior to each entity because it was easy to do it that way. But now we’ve noticed that we’re writing lots of duplicate code for similar behaviors, so we’ll probably end up refactoring this bit.
Yeah, when Geoff said entities in Djinn can only have one behaviour I was like: “So, why are you using entity/component then?”
I think “the do-it-quick then rewrite-later-if-needed” is the best approach to all indies, not only HTML5 guys, because, according to Jonathan Blow, good enough for now is, on most cases, good enough for shipping.
Hey @geoffb, I was actually thinking about that car game thing…
Couldn’t you make something mario kart-ish?
I mean, make a game which is actually top-down, draw the road using mode 7 like techniques, draw car sprites and draw a skydome?
The rendering code would be a bit more complex, I guess, but it would be way easier to program gameplay stuff, as the game is actually top-down.
Yeah, that’s an interesting method, too. I do think it would simplify some aspects. However, the Out Run style approach has pretty simple gameplay as well. For the purposes of the game model, there are no turns in the road. Makes the AI pretty easy as they only have to move left and right to avoid obstacles in their path.
We shipped faster than someone else?! Never saw that coming ;)
Wowww I remember roads like that! (I grew up in Illinois.) I once was driving on an overpass, very slowly, and my car just suddenly did a 180 because it was so slick with ice. Luckily I didn’t touch the rail or anybody else’s car. Just kind of slowly turned around and kept on…
@Josue Unless you have specialized needs or a lot of time available, I don’t recommend writing your own middleware. You can save yourself months, perhaps a year, of time by spending $99 on a tool like ImpactJS.
Of course, if you are just writing an engine for fun, then have at it. You will certainly learn a lot.
I don’t know… I just feel like no game engine/framework matches my coding style and the way I like to organize my game systems.
Making a 2D framework is relatively simple, tho.
Oh, I didn’t mean making a 3D engine from scratch, I meant just gluing some libraries together. Ammo.js + Three.js + Howler.js + a dozen hundred lines of glue code = 3D game engine.
That’s a great idea, but I would like to hear about how to use sound in your game, from a design perspective, not how to implement it.
C’mon, using the audio API is easy as shit. Unless you’re talking about Webaudio API, I guess there’s no reason to discuss implementation further, everything you need W3Schools already has.