Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Core HTML5 Canvas

samzenpus posted about a year ago | from the read-all-about-it dept.

Books 72

eldavojohn writes "Core HTML5 Canvas is a book that focuses on illuminating HTML5 game development for beginning and intermediate developers. While HTML and JavaScript have long been a decent platform for displaying text and images, Geary provides a great programming learning experience that facilitates the canvas element in HTML5. In addition, smatterings of physics engines, performance analysis and mobile platform development give the reader nods to deeper topics in game development." Read below for the rest of eldavojohn's review.This book is written with a small introduction to HTML and JavaScript. While Geary does a decent job of describing some of those foundational skill sets, I fear that a completely novice developer might have a hard time getting to the level required for this text. With that in mind, I would recommend this book for people who already have at least a little bit of HTML and JavaScript development in their background. This book may also be useful to veteran developers of an unrelated language who can spot software patterns easily and aren't afraid to pick up JavaScript along the way. You can read all of Chapter One of the book here if you want to get a feeling for the writing. Geary also has sample chapters available on his site for the book, corehtml5canvas.com and maintains the code examples on Github. If you already write games, this book is likely too remedial for you (especially the explanations of sprites and collision detection) and the most useful parts would be Geary's explanation of how to produce traditional game elements with the modern HTML5 standards.

I have very few negative things to say about this text – many of which may be attributed to personal preferences. This book is code heavy. It starts off with a sweet spot ratio for me. I found I spent about twenty to thirty percent of my time scanning over HTML and JavaScript snippets inserted occasionally into passages. However, by the last chapters, I found myself poring over lengthier and lengthier listings that made me feel like I was spending sixty to seventy percent of my time analyzing the JavaScript code. To be fair, the author does do a good job of simply referencing back to concepts learned in other chapters but I wouldn't mind a re-explanation of those topics or a more in depth analysis of how those concepts interoperate. I also feel that it is risky to put so much code into print as that greatly impacts the shelf life of an unchanging book. The book itself warns on page 51 that toBlob() was a new specification added to HTML5 between writing the book and the book being published. I feel like this would warrant much more English explaining what you're accomplishing and why so that the book does not age as much from being tightly coupled to a snapshot of the specifications.

The code listings in this book are wonderfully colored to indicate quickly to the eye what part of the JavaScript language each piece is. I'm not sure how many copies suffer from this but my book happened to have a problem on some of the pages whereby the comprising colors did not line up. Here is a good example and a bad example just a few pages apart.

This was infrequent but quite distracting as the code became more and more predominant. Lastly, Geary briefly introduces the reader to amazing performance tools (jsPerf in Chapter 1 and again Browserscope in Chapter 4) early on and demonstrates how to effectively exercise it on small pieces of JavaScript. In the particular example he shows how subtle differences in handling image data can affect the performance inside different browsers (even different versions of the same browser as I'm sure the JavaScript engines are repeatedly tweaked). Since games are always resource intensive, I wondered why the author didn't take these examples to the next level and show the reader how to write unit tests (not really covered in the book). That way each of these functions could be extracted to a common interface where it would be selectively chosen based on browser identification. While this might be unnecessary for images, it would be a nod toward addressing the long pole in the tent when you look to squeeze cycles out of your code. Oddly, as more concepts are established and combined, these performance exercises disappear. I understand this book was an introduction to these side quests with a focus on game development but this was one logical step I wish had been taken further (especially in Chapter 9: The Ungame).

About a year ago, I started a hobby project to develop a framework for playing cards in the browser on all platforms. The canvas element would be the obvious tool of choice for accomplishing this goal. Unfortunately I began development using a very HTML4 attitude with (what I now recognize) was laughable resource management. This book really helped me further along in getting that hobby project to a more useable state.

The first chapter of the book introduces the reader to the basics of HTML5 and the canvas element. The author covers things like using clientX and clientY for mouse events instead of x and y. A simple clock is built and shows how to correctly use the basic drawing parts of the HTML5 specification. For readers unfamiliar with graphics applications, a lot of ground is covered on how you programmatically start by constructing an invisible path that will not be visually rendered until stroke() or fill() is called. The chapter also covers the basic event/listener paradigm employed by almost anything accepting user input. Geary explains how to properly save and restore the surface instead of trying to graphically undo what was just done.

An important theme through this book is how to use HTML elements alongside a canvas. This was one of the first follies of my "everything goes in canvas" attitude. If you want a control box in your application, don't reinvent the partially transparent box with paths and fills followed by mouse event handling over your canvas (actually covered in Chapter 10) – simply use an HTML div and CSS to position it over your canvas. Geary shows how to do this and would have saved me a lot of time. Geary discusses and shows how to manage off-screen canvases (invisible canvases) in the browser which comes in mighty handy when boosting performance in HTML5. The final parts of Chapter One focus on remedial math and how to correctly handle units of measure when working in the browser.

Chapter Two shows the reader how to build a rudimentary paint application with basic capabilities. It does a great job of showing how to expand on the basic functions provided by HTML5 and covers a little bit of the logic behind the behavior. Geary goes so far as to show the reader how to extend some of the core components of HTML5 like CanvasRenderingContext2D with an additional function. He also cautions that this can lead to pitfalls in JavaScript. This chapter does an excellent job of exploiting and enumerating core drawing functionality to achieve the next level in using these lines and objects for a desired user effect. Prior to reading this chapter, I hadn't viewed clip() in the correct light and Geary demonstrates the beginnings of its importance in building graphics. In Chapter Three, text gets the same extensive treatment that the basic drawing elements did in Chapter Two. In reading this chapter, it became apparent hat HTML5 has a lot of tips and tricks (perhaps that comes with the territory of what it's trying to achieve) like you have to replace the entire canvas to erase text. Being a novice, I'm not sure if the author covered all of such things but I was certainly appreciative for those included.

Chapter Four was an eye opener on images, video and their manipulation in canvas. The first revelation was that drawImage() can also render another canvas or even a video frame into the current canvas. The API name was not indicative to me but after reading this chapter, it became apparent that if I sat down and created a layout of my game's surface, I could render groups of images into one off-screen canvas and then continually insert that canvas into view with drawImage(). This saved me from considerable rerendering calls. The author also included some drag and drop sugar in this chapter. The book helped me understand that sometimes there are both legacy calls to old ways of doing things and also multiple new ways to accomplish the same goal. When you're trying to develop something as heavy as a game, there are a lot of pitfalls.

Chapter Five concentrates on animations in HTML5 and first and foremost identifies a problem I had struggled with in writing a game: don't use setInterval() or setTimeout() for animations. These are imprecise and instead the book guides the reader with instructions on letting the browser select the frame rate. Being a novice, the underlying concepts of requestAnimationFrame() had eluded me prior to reading this book. Geary's treatment of discussing each browser's nuances with this method may someday be dated text but helped me understand why the API call is so vital. It also helps you build workarounds for each browser if you need them. Blitting was also a new concept to me as was the tactic of double buffering (which the browser already does to canvas). This chapter is heavy on the hidden caveats to animation in the browser and builds on these to implement parallax and a stopwatch. The end of this chapter has a number of particularly useful "best practices" that I now see as crucial in HTML5 game development.

Chapter Six details sprites and sprite sheets. Here the author gives us a brief introduction to design patterns (notably Strategy, Command and Flyweight) but it's curious that this isn't persisted throughout the text. This chapter covers painters in good detail and again how to implement motion and timed animation via sprites with requestNextAnimationFrame(). This chapter does a great job of showing how to quickly animate a spritesheet.

Chapter Seven gives the user a brief introduction to implementing simple physics in a game engine like gravity and friction. It's actually just enough to move forward with the upcoming games but the most useful section of this chapter to me was how to warp time. While this motion looks intuitive, it was refreshing to see the math behind ease-in or ease-out effects. These simple touches look beautiful in canvas applications and critical, of course, in modeling realistic motion.

Naturally the next thing needed for a game is collision detection and Chapter Eight scratches the surface just enough to build our simple games. A lot of fundamental concepts are discussed like collision detection before or after the collision happens. Geary does a nice job of biting off just enough to chew from the strategies of ray casting, the separating axis theorem (SAT) and minimum translation vector algorithms for detecting collisions. Being a novice to collision detection, SAT was a new concept to me and I enjoyed Geary's illustrations of the lines perpendicular to the normal vectors on polygons. This chapter did a great job of visualizing what the code was achieving. The last thing this chapter tackles is how to react or bounce off during a collision. It provided enough for the games but it seemed like an afterthought to collision detection. Isn't there a possibility of spin on the object that could influence a bounce? These sort of questions didn't appear in the text.

And Chapter Nine gets to the main focus of this book: writing the actual game with all our prior accumulated knowledge. Geary calls this light game engine "the ungame" and adds things like multitrack sound, keyboard event handling and how to implement a heads-up display to our repertoire. This chapter is very code heavy and it confuses me why Geary prints comments inlined in the code when he has a full book format to publish his words in. The ungame was called as such because it put together a lot of elements of the game but it was still sort of missing the basic play elements. Geary then starts in on implementing a pinball game. It may sound overly complicated for a learning text but as each piece of the puzzle is broken down, the author manages to describe and explain it fairly concisely. While this section could use more description, it is basically just bringing together and applying our prior concepts like emulating physics and implementing realistic motion. The pinball board is merely polygons and our code there to detect collisions with the circle that is the ball. It was surprisingly how quickly a pinball game came together.

Chapter Ten takes a look at making custom controls (as mentioned earlier about trying to use HTML when possible). From progress bars to image panners, this chapter was interesting and I really enjoyed the way the author showed how to componentize and reuse these controls and their parts. There's really not a lot to say about this chapter, as you may imagine a lot of already covered components are implemented in achieving these controls and effects.

Geary recognizes HTML5's alluring potential of being a common platform for developing applications and games across desktops and mobile devices. In the final chapter of the book, he covers briefly the ins and outs of developing for mobile — hopefully without having to force your users to a completely different experience. I did not realize that native looking apps could be achieved on mobile devices with HTML5 but even with that trick up its sleeve, it's hard to imagine it becoming the de facto standard for all applications. Geary appears to be hopeful and does a good job of getting the developer thinking about the viewport and how the components of their canvas are going to be viewed from each device. Most importantly, it's discussed how to handle different kinds of input or even display a touch keyboard above your game for alphabetic input.

This was a delightful book that will help readers understand the finer points of developing games in HTML5's canvas element. While it doesn't get you to the point of developing three dimensional blockbuster games inside the browser, it does bite off a very manageable chunk for most readers. And, if you're a developer looking to get into HTML5 game design, I heavily recommend this text as an introduction.

You can purchase Core HTML5 Canvas from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

72 comments

Sorry! There are no comments related to the filter you selected.

Another Excellent Review (2)

Tenebrousedge (1226584) | about a year ago | (#43964927)

I have a very clear idea of what this book is about and what it covers, and in what level of detail. It does indeed seem like a good introduction to the subject. Thank you for writing this, and of course for your other reviews.

Re:Another Excellent Review (2)

K. S. Kyosuke (729550) | about a year ago | (#43965047)

Did you use a natural language generator to write that? (Serious question, I've seen a few texts like this and I'm wondering...)

Re:Another Excellent Review (-1)

Anonymous Coward | about a year ago | (#43965265)

That is a very informative post, most interresting to read. It shows a great deal of knowledge on the subject and I will be sure to use what I've learned on my blog wkeosdikrm.kdixmnaiqer.com for future reference.

Re:Another Excellent Review (2)

Tenebrousedge (1226584) | about a year ago | (#43965459)

Ouch. No, I haven't got much into NL programming. I think those kind of comments are copy/pasted though. Mine was just congratulatory and vapid.

Re:Another Excellent Review (1)

Steve_Ussler (2941703) | about a year ago | (#43965673)

Aside from the grammar and few spelling errors...agreed

Re:Another Excellent Review (0)

Anonymous Coward | about a year ago | (#43966181)

Grab it here [thepiratebay.sx]

Enough with the toy languages (-1, Flamebait)

The Cat (19816) | about a year ago | (#43964929)

It's time for people to stop with this pretending to write computer games nonsense.

HTML5 is not a suitable development environment. Javascript is not a suitable development environment. Your web browser is not a suitable development environment. HTML5 is vaporware. HTML is designed to display TEXT.

Please re-read those sentences until you get it through your head. If you want to write a computer game, start with a real programming language:

1. C
2. C++

I recommend C so you don't get distracted by all the horse**** theory around OOP.

If you need a graphics engine, fine. Get one. Then code the game in a real development environment on a real computer (not a fiddly mobile device) on the metal. It will be hard, but the results will be worth it. If you can't bring yourself to do this, then you have no business programming or writing computer games.

P.S. I'm not interested in Javascript DOOM or whatever the "gew-gaw of the week" is, and I've been programming computers for 37 years, so I'm not interested in your tech credentials either. Either code the game or don't code the game, but knock it off with this artificial development nonsense.

That is all.

Re:Enough with the toy languages (0)

Anonymous Coward | about a year ago | (#43964985)

You sound like an old fart. Oh wait...

Re:Enough with the toy languages (0)

Anonymous Coward | about a year ago | (#43965005)

You just sound bitter and old..

Re:Enough with the toy languages (2)

H0p313ss (811249) | about a year ago | (#43965027)

You just sound bitter and old..

... and right.

Didn't I warn you about the lawn already?

Re:Enough with the toy languages (2)

HaZardman27 (1521119) | about a year ago | (#43965089)

How is he right? "Game" does not have to mean cutting-edge, state-of-the-art 3D graphics with massively multiplayer mechanics. If you are making a simple 2D card game, how much advantage are you really getting from writing the game in C, spending a lot more time writing it, and then building it for each platform you'd like to distribute to? For simple games, HTML5 and JS allow you to write it quickly and easily distribute to many platforms. Sounds like you are just as bitter and old as the GGP.

You missed one (1, Insightful)

Anonymous Coward | about a year ago | (#43965043)

Bitter and old? Possibly. Correct? Absolutely.

Re:You missed one (0)

Anonymous Coward | about a year ago | (#43965197)

There is no "correct" lanaguage to program anything in.

Re:You missed one (1)

lister king of smeg (2481612) | about a year ago | (#43965709)

There is no "correct" lanaguage to program anything in.

no but their in most assuredly are wrong ones. if you dont agree then go write everything in the Brainfuck [wikipedia.org] programing language

Re:Enough with the toy languages (2)

HaZardman27 (1521119) | about a year ago | (#43965031)

For 2D games with simple mechanics, you don't need the performance of a fine-tuned engine written in C or C++ and natively compiled. Writing your game logic in JavaScript and rendering to an HTML5 Canvas is an easy way to distribute a simple game to many platforms.

Re:Enough with the toy languages (1)

K. S. Kyosuke (729550) | about a year ago | (#43965083)

Gamerizon's QuantZ (a logical 3D game) is written in Scheme. I don't think anyone can actually tell.

Re:Enough with the toy languages (2)

H0p313ss (811249) | about a year ago | (#43965039)

While I agree with about 90%, it does depend on how you define "game".

Given that you can get better framerates doing OpenGL in Java now than you could 15 years ago in C, it's really not that simple.

Enough with the toy languages like C & C++ (5, Insightful)

eldavojohn (898314) | about a year ago | (#43965071)

It's time for people to stop with this pretending to write computer games nonsense.

HTML5 is not a suitable development environment. Javascript is not a suitable development environment. Your web browser is not a suitable development environment. HTML5 is vaporware. HTML is designed to display TEXT.

Please re-read those sentences until you get it through your head. If you want to write a computer game, start with a real programming language:

1. C 2. C++

I recommend C so you don't get distracted by all the horse**** theory around OOP.

If you need a graphics engine, fine. Get one. Then code the game in a real development environment on a real computer (not a fiddly mobile device) on the metal. It will be hard, but the results will be worth it. If you can't bring yourself to do this, then you have no business programming or writing computer games.

P.S. I'm not interested in Javascript DOOM or whatever the "gew-gaw of the week" is, and I've been programming computers for 37 years, so I'm not interested in your tech credentials either. Either code the game or don't code the game, but knock it off with this artificial development nonsense.

That is all.

It's time for people to stop with this pretending to write computer games nonsense.

C/C++ is not a suitable development environment. VI is not a suitable development environment. Emacs is not a suitable development environment. C++14 is vaporware. C++ is designed to focus on OBJECTS, not GAMES.

Please re-read those sentences until you get it through your head. If you want to write a computer game, start with a real instruction set:

1. ARM (ARMv7 not ARMv8)
2. x86-64

I recommend ARM so you don't get distracted by all the horse**** bloat around CISC.

If you need a punch card reader, fine. Get one. Then code the game on a real ENIAC (not a fiddly PC) in the vacuum tubes. It will be hard, but the results will be worth it. If you can't bring yourself to do this, then you have no business programming or writing computer games.

P.S. I'm not interested in C++ OOP or whatever "Stroustrup's latest fly-by-night language" is, and I've been programming computers for 1,337 years, so I'm not interested in your tech credentials either. Either code the game or don't code the game, but knock it off with this artificial C/C++ development nonsense.

That is all.

Re:Enough with the toy languages like C & C++ (0)

etash (1907284) | about a year ago | (#43965251)

MOD THIS UP. proper answer for elitist morons coming from the stone age trying to sell their rusted selves and presenting themselves as be-all and end-all of computer literacy.

Re:Enough with the toy languages like C & C++ (1)

Nadaka (224565) | about a year ago | (#43965911)

Game dev requires good tools and performance, and those are sorely lacking in js. JS is a total nightmare to code anything serious in.

C or C++ isn't necessary, but c# or java make a much better environment than the web browser and js.

Re:Enough with the toy languages like C & C++ (0)

Anonymous Coward | about a year ago | (#43967295)

JS is a total nightmare to code anything serious in.

If you really believe this, you don't know how to use it, and probably shouldn't be commenting.

Re:Enough with the toy languages like C & C++ (1)

Nadaka (224565) | about a year ago | (#43967517)

By serious, I mean hundreds of thousands or millions of lines of code.

Re:Enough with the toy languages like C & C++ (1)

tofarr (2467788) | about a year ago | (#43971059)

This is being done every day (I have worked with GIS applications with that level of complexity, and many of the in browser games have that level of complexity too.). Granted, the environment has its flaws, but for the most part performance is good enough (it could be better - especially on older versions of IE.), and you generally have nowhere near the same amount of deployment problems as with C++ application or java applet. As always, choose the right tool for the right job - If you are part of a team creating a AAA title where you need cutting edge graphics an performance - then javascript is probably not what you should be using for your games engine. But with the right tools and discipline it can be used to very rapidly create UIs and logic for systems where this is not the primary concern

Re:Enough with the toy languages like C & C++ (1)

Nadaka (224565) | about a year ago | (#43973463)

I know its being done. I am doing it (a big part of my current work is an extJS web app.. There are no good JS development environments and debuggers. And without static typing you really don't know for sure what an object is or does when it is passed to you. You can assume, and you can test, but that isn't the same as knowing.

And yes it really is a nightmare.

Re:Enough with the toy languages like C & C++ (1)

CadentOrange (2429626) | about a year ago | (#43971301)

Why do you need millions of lines of code? This is an honest question.

Not every game is a triple-A title that costs millions of dollars to develop. Indie studios are becoming increasingly popular and are producing games that are unique and interesting. For a concrete example, check out the Humble Indie bundles or InXile's Wasteland 2 and Torment. The latter 2 are looking very promising and they are developed using Unity.

Performance isn't as critical as it used to be. Modern tools allow smaller dev teams to achieve more and target a wider audience, and that is a very good thing.

Re:Enough with the toy languages like C & C++ (1)

Nadaka (224565) | about a year ago | (#43973399)

Well, I am only a amateur game programmer, never had a game run more than 10kloc, but that is generally with procedural generation of terrain and no 3d. My professional programming is in logistics and reporting services for the DoD, where our requirements documents literally take up a stack of paper more than 4 feet tall in fine print. We used to have a ER diagram to reference, it took up one of our office walls, it has since then grown, I think we would need to use the ceiling for it now.

Re:Enough with the toy languages like C & C++ (0)

Anonymous Coward | about a year ago | (#43975093)

I understand what you're saying, and I have no objection to seeing games run in the browser, but it is a little disheartening to watch a game that wouldn't have taxed a NES lag on my x86 PC that's only a few years old. Granted, this seems to be more of a flash problem...

Re:Enough with the toy languages like C & C++ (1)

K. S. Kyosuke (729550) | about a year ago | (#43965471)

C++ is designed to focus on OBJECTS, not GAMES.

I view C++ as designed to be completely unfocused. (Although I'd perhaps note that Alexander Stepanov's theory of programming might have had some say in the design of its generic programming features.)

P.S. I'm not interested in C++ OOP or whatever "Stroustrup's latest fly-by-night language" is, and I've been programming computers for 1,337 years, so I'm not interested in your tech credentials either.

Mr. Al-Khwarizmi, is that you?

Re:Enough with the toy languages like C & C++ (1)

lagi (303346) | about a year ago | (#43966857)

C++ is designed to focus on OBJECTS, not GAMES.

I view C++ as designed to be completely unfocused. (Although I'd perhaps note that Alexander Stepanov's theory of programming might have had some say in the design of its generic programming features.)

P.S. I'm not interested in C++ OOP or whatever "Stroustrup's latest fly-by-night language" is, and I've been programming computers for 1,337 years, so I'm not interested in your tech credentials either.

While i kind of understand eldavojohn's point of view, C is indeed the one and only answer for some kind of tasks and some kind of games and game components. I cannot agree with him, Mr. Stroustrup created a wonderful abstract computer language, we are (developers) the ones who misunderstood it (completely it seems). C++11 is not C++98.

C++ is well suited for game development, because it gives you the abstraction level and speed computer games require.

ECMAScript implementations are used for game scripting (UnityScript), and with technology like emscripten you get the power of C++ compiled into JavaScript, what more can a game developer ask for really? for all of it to run in your browser maybe?

Re:Enough with the toy languages like C & C++ (1)

K. S. Kyosuke (729550) | about a year ago | (#43970983)

C is indeed the one and only answer for some kind of tasks and some kind of games and game components.

So you couldn't write these components in, say, Modula-2 or Modula-3? To me it seems that C is actually a member of a (large) class of languages that sport an intersection of features desirable for "some kind of tasks and some kind of games and game components". That doesn't mean that some of these features couldn't (or even shouldn't) be dropped without causing much harm, and even more importantly, it doesn't mean that within this class of languages, there are no better alternatives. To claim that "C is the one and only answer" is fallacy. That can be easily demonstrated, for example, by showing that C-with-true-modules would be a better answer. Or C-with-true-modules-and-uniqueness-typing. And so on.

C++ is well suited for game development, because it gives you the abstraction level and speed computer games require.

You're not very demanding if you claim that C++ gives you "abstraction levels" of any kind. But then again, historically, game programmers have never been suckers for abstraction levels. They were using assembly instead of Forth in the 1980's, C instead of C++ in the 1990's; these days, I guess they're using whatever in C++ gives them the best speed and skip the rest.

ECMAScript implementations are used for game scripting (UnityScript), and with technology like emscripten you get the power of C++ compiled into JavaScript, what more can a game developer ask for really? for all of it to run in your browser maybe?

A saner browser language could never hurt. But I'm afraid that the instant compilation requirement for browser scripting languages severely restricts the options. :/ Look at what Stalin can do with Scheme code - very nifty but totally unusable in a browser (I have an idea how such things could be sped up but I guess that most people would consider it insane.)

Re:Enough with the toy languages like C & C++ (1)

lagi (303346) | about a year ago | (#43972569)

C++ is well suited for game development, because it gives you the abstraction level and speed computer games require.

You're not very demanding if you claim that C++ gives you "abstraction levels" of any kind. But then again, historically, game programmers have never been suckers for abstraction levels. They were using assembly instead of Forth in the 1980's, C instead of C++ in the 1990's; these days, I guess they're using whatever in C++ gives them the best speed and skip the rest.

When i said abstraction level i was talking about programming language abstraction (operators, keywords, types), not on the class/object level, from the language point of view C++ is very abstract. language abstraction leads to class abstraction and other abstractions. In fact C++ is defined as "A light-weight abstraction programming language" [stroustrup.com] (Bjarne's 2012 Keynote). Developers should start listening to what he has to say, he's very smart dude.

I'm actually not professional game developer, just an armature one trying to learn and explorer my way to the professional level and create my own games. I am developing web-based client and server software for 15 years, so what can i say ... technologies like emscripten just look the answer i was looking for for my needs, desire and long term development.

If you wish people will be able playing your game even in a 100 years or more, you better build them with C or C++.

Re:Enough with the toy languages like C & C++ (1)

brantondaveperson (1023687) | about a year ago | (#43968715)

I view C++ as designed to be completely unfocused.

That's because it's a general-purpose programming language. In what way would it be focussed exactly?

Re:Enough with the toy languages like C & C++ (1)

K. S. Kyosuke (729550) | about a year ago | (#43971005)

That's because it's a general-purpose programming language.

No, it's not. Lisp is a general purpose language (partly because it's actually a metalanguage, even accomodating different evaluation models when the user requires). C++ is a semi-general-purpose language (pretends being general purpose but requires to be mutilated and molested into shape in many domains). C, for that matter, is not a general purpose language at all, it's a bit-twiddling language.

I love you. (-1)

Anonymous Coward | about a year ago | (#43965087)

I recommend C so you don't get distracted by all the horse**** theory around OOP.

If my wife was 10 years younger, I'd ask you to fuck her so I could have your baby.

Re:I love you. (1)

K. S. Kyosuke (729550) | about a year ago | (#43965497)

If your mother were 12 years younger, you could ask him to fuck her so that you could be his baby!

Re:Enough with the toy languages (0)

Anonymous Coward | about a year ago | (#43965097)

Speaketh someone who's likely never programmed any complex modern game.

Its not one language anymore pal, sorry. Its C++, its C, its Python, it's lua, and yes its Javascript & HTML inside the game. Holy moly save us from abstraction lords of assembly!

Lord of COBOL save us!

Re:Enough with the toy languages (0)

Anonymous Coward | about a year ago | (#43965101)

Hey old timer, I have a message for you: Computers are fast now.

Re:Enough with the toy languages (1)

jc42 (318812) | about a year ago | (#43968781)

Hey old timer, I have a message for you: Computers are fast now.

Not really. Yeah, the hardware guys have done a great job of making their part of the stack smaller and faster as the years have flown by. But the software guys have done an even better job of erasing the hardware speed increases by more than matching each with memory- and cpu-consuming bloat.

Much of this is due to the attitude that "We don't need to be efficient any more, because the hardware is so fast and there's so much memory available." There is no processor so fast or memory so large that programmers with contempt for efficient design can't easily saturate both of them, and then complain that the machine is just too slow and there's not nearly enough memory.

And as long as management continues to rate software developers by lines-of-code (the only software thing that they seem to know how to measure), this isn't going to change. Increasing the line (or char) count of my code is always trivial. In fact, I have perl scripts to do the job for me, for many of the common programming languages. ;-)

(I have fond memories of one project in which I rewrote a few core routines to be about half their original size, producing roughly a 10x speed improvement. It became clear that the management considered my "contribution" to have a negative measure. I'd decreased the code base. I found a new job. ;-)

Re:Enough with the toy languages (0)

Anonymous Coward | about a year ago | (#43970651)

Not really. Yeah, the hardware guys have done a great job of making their part of the stack smaller and faster as the years have flown by. But the software guys have done an even better job of erasing the hardware speed increases by more than matching each with memory- and cpu-consuming bloat.

Yeah really. Computers do a lot more than they used to, even with the bloat. And a lot of times, the CPU is just sitting there, wasting cycles.

Much of this is due to the attitude that "We don't need to be efficient any more, because the hardware is so fast and there's so much memory available." There is no processor so fast or memory so large that programmers with contempt for efficient design can't easily saturate both of them, and then complain that the machine is just too slow and there's not nearly enough memory.

It all depends on the task. A majority of the time, the programmer's time is more valuable than making a piece of code efficient.

Re:Enough with the toy languages (1)

jc42 (318812) | about a year ago | (#43972035)

It all depends on the task.

Of course, but putting it that way wouldn't be as funny. ;-)

Actually, in one of my recent jobs, I spent a day or so going through an app's use of malloc(), which was used a lot to save data structures for a short time, then free() them. I replaced these calls with calls to a pair of routines that "freed" a chunk by putting it on a list of similar-sized chunks, to be re-used later. The result was a program that was maybe 5% bigger in most runs, but ran between 4 a 5 times faster. This reduced the task from typically a day or so down to a few hours. The client was very happy with the result. Sometimes it's worth paying a (competent ;-) programmer to do things like this. And sometimes it' not worth it.

(Yes, the program had been spending up to 80% of its time inside the malloc() and free() routines. They are a lot cruftier and slower than most people would guess. ;-)

One advantage of the increases in speed and memory is that you can use the practical approach of writing quick-and-dirty prototypes. If it's "good enough" and not used much, you might as well leave it that way. If it's used a lot, you can study the code, and find ways of optimizing it.

But that's not nearly as funny as observing that the study and optimization part is rarely done, with results that most of us old-timers know well: It seems like the modern super-fast machines take as long to do most tasks as they old, slow machines did 20 or 30 years ago. The only real change is often just the flashy graphics surrounding the output (and lots of unused white space on the screen).

OTOH, I did just look at the local weather radar images on my laptop, and checked with google traffic for congested areas. Couldn't do those things 20 years ago.

Re:Enough with the toy languages (1)

Anonymous Coward | about a year ago | (#43965129)

Game written using C++:
Requires a super computer to run with a specific set of hardware
Requires a team of 15 highly skilled developers
Requires at least a year a 10 million bucks
Has super fancy pants performance and graphics which only impresses elitist snob nerds.
Has to sell for $50 just to even try to break even.
Only purchased by nerds living in their mom's basements.

Game written using Javascript/HTML5
Requires a modern web browser on pretty much any hardware
Requires 1 amateur developer with a decent vision
Requires enough to feed a single developer
Has simple, well-defined graphics that a 3 year old will get
Can sell for $0.99 or be fully ad-funded and still profit
Potentially purchased by millions of normal people, not just uber-nerds.

It looks like someone is just plain bitter about the changed landscape of the computer game world.

Re:Enough with the toy languages (0)

Anonymous Coward | about a year ago | (#43965199)

Only purchased by nerds living in their mom's basements.

Whilst I agree with your point wholeheartedly, this line was just plain unnecessary. Ad hominem attacks do nothing for your credibility.

Re:Enough with the toy languages (1)

K. S. Kyosuke (729550) | about a year ago | (#43965597)

Mostly agreed, although I'd make exception in case of The Elder Scrolls series. Just like you wouldn't probably try to film LoTR as an indie film on Kickstarter.

Re:Enough with the toy languages (1)

Oligonicella (659917) | about a year ago | (#43972493)

You sir, are mistaken. People with the former attitude would indeed think a cheaply made, low quality production of LoTR would be preferable to a studio produced one simply *because* it was done with cheap tools. Hell, that view has been argued here on /.

Re:Enough with the toy languages (1)

K. S. Kyosuke (729550) | about a year ago | (#43975493)

People with the former attitude would indeed think a cheaply made, low quality production of LoTR would be preferable to a studio produced one simply *because* it was done with cheap tools.

I hope I made it obvious that this is *not* my point of view. If that was clear to you, it means that the rest of your comment is incomprehensible to me.

Re:Enough with the toy languages (1)

lister king of smeg (2481612) | about a year ago | (#43965857)

C++ does not require a super computer and will usually have perform better than you html game. in fact the delvik java vm is written in c++ and runs most of the smart phones on the market.

oh and c++ is portable you just have to use libraries that are available on multiple architectures and os's. just cross compile.

I agree with your premise (1)

Anonymous Coward | about a year ago | (#43965145)

But shouldn't it be about how fun/intriguing the game is and not what language it's written in?

I do agree with your sentiments of there's a place for everything though, and the web browser has ways to go if you are trying to put a league of legends, world of warcraft, or COD in the browser.

Re:I agree with your premise (2)

HaZardman27 (1521119) | about a year ago | (#43965887)

the web browser has ways to go if you are trying to put a league of legends, world of warcraft, or COD in the browser.

I would argue that "ways to go" has been getting much shorter [mozilla.org] .

Re:I agree with your premise (1)

Benaiah (851593) | about a year ago | (#43969199)

Ironically "which is written in C++ and OpenGL, and compiles it using Emscripten into JavaScript and WebGL"
So why bother writing games in Javascript when you can use traditional methods and compile to js and arguably achieve better results?

Re:I agree with your premise (1)

HaZardman27 (1521119) | about a year ago | (#43976983)

Because, once again, not every game has to have 3D graphics with realtime lighting and shading effects.

Re:I agree with your premise (1)

CadentOrange (2429626) | about a year ago | (#43971325)

But shouldn't it be about how fun/intriguing the game is and not what language it's written in?

I do agree with your sentiments of there's a place for everything though, and the web browser has ways to go if you are trying to put a league of legends, world of warcraft, or COD in the browser.

League of Legends (LoL) and World of Warcraft (WoW) are hardly taxing on hardware. The WoW engine is almost 10 years old and LoL runs without a hitch on integrated graphics (nVidia 320m on my 2010 Macbook). Performance in games isn't as critical as it used to be.

Re:Enough with the toy languages (0)

Anonymous Coward | about a year ago | (#43965171)

This sentiment is exactly why there is age discrimination against software developers. People can't adapt to updates and new technologies, and get stuck in the past.

Re:Enough with the toy languages (0)

Anonymous Coward | about a year ago | (#43966353)

This! And somewhere, there is an assembly programmer sneering at you for even using C.

Re:Enough with the toy languages (1)

fredrated (639554) | about a year ago | (#43965185)

I did my first programming on punch cards and you sound like someone that wants us to keep programming in assembler, lots 'o luck with that.

Re:Enough with the toy languages (1)

Anonymous Coward | about a year ago | (#43965283)

Dude. Did you forget to take your medication? Geeze. Talk about "get off my lawn." It's the year 2013, not 1995. I don't understand your rationale of harder == better, either.

Do you think every system of a game is written in C or C++? If you do, think again.

Not everyone programs to the metal. Nor should they have to. Not every game needs to be a AAA title developed with a cutting edge game engine or advanced graphics sub systems. Using a language such as Javascript and the canvas allows developers to explore and discover without the overhead of jumping through the many hoops (memory management, etc.) associated with C and C++. Many of the concepts they learn can be applied later on if and when they choose to use something more low level.

You seriously need to relax man, it's almost like you got some kind of chip on your shoulder! Just because you have been programming computers for 37 years does not make you an expert on every subject. Not everyone is you.

Re:Enough with the toy languages (2)

mwvdlee (775178) | about a year ago | (#43965453)

Neither C nor C++ is "on the metal".Any programming language short of Assembly is an abstraction of "the metal" with less capabilities. And even Assembly is debatable.

Surely as a 37-year veteran you should have been well aware of this. Neither C nor C++ enables all control flow mechanisms possible on a CPU.

Many mobile games, interrestingly enough, are optimized for "the metal".

Re:Enough with the toy languages (0)

The Cat (19816) | about a year ago | (#43965721)

C is a portable assembler. As long as we are writing directly to memory, it's on the metal.

No mobile code is written on the hardware. The mobile OS companies want a cut.

Re:Enough with the toy languages (1)

mwvdlee (775178) | about a year ago | (#43966767)

C is a portable assembler. As long as we are writing directly to memory, it's on the metal.

C cannot do all the control flow that one can do using assembler.
C does not support all CPU datatypes CPU (i.e. BCD).
C does not support SIMD (some C dialects do, though).
C is a very thin abstraction and much closer to the hardware than most languages, but it's an abstraction nonetheless.
If you think C is as much "on the metal" as assembler, you are sorely mistaken.

No mobile code is written on the hardware. The mobile OS companies want a cut.

Android allows developers to write assembler for native CPU and graphics hardware directly.
Many games and engines on mobile devices do exactly that for the most common hardware.
Support for using assembler is included and documented in the Android SDK.

Re:Enough with the toy languages (0)

Anonymous Coward | about a year ago | (#43966801)

you make 0 sense

Re:Enough with the toy languages (1)

Shados (741919) | about a year ago | (#43965643)

Sorry, I can't "hear" you over the 1.1 billion dollar/year we're making here by using that HTML5 vaporware and javascript to do more than just display text.

Re:Enough with the toy languages (1)

The Cat (19816) | about a year ago | (#43965675)

I Googled "most successful HTML5 game"

http://techcrunch.com/2013/02/22/ludei/ [techcrunch.com]

This was the result.

Re:Enough with the toy languages (1)

Shados (741919) | about a year ago | (#43965957)

Oh no, we don't do games, but we use the same technologies you would use to make a game, so still relevant IMO.

Same deal Direct X or OpenGL aren't just used for games.

Re:Enough with the toy languages (2)

MiniMike (234881) | about a year ago | (#43966119)

I have to agree with what you say, but only for 'serious' programs. This does not include games. Anything doing serious data crunching, modeling, etc. needs C/C++ (or FORTRAN, usually for legacy code). Most games do not fall into this category. Yes some games do some modeling, ray tracing, etc. but not the ones written in Flash or similar languages. Remember the expression 'use the right tool for the job'? As much as I appreciate and use C, it is not the tool to meet the requirements for browser games, which exist in an environment where quality is traded for ease of distribution and production.

Don't be so dismissive of these other languages- they shouldn't be used in some (most) places, but they're ok in their niche. And as someone who started programming on 'big metal' machines, I can appreciate that my 'fiddly mobile device' has more memory, storage, and processing capability than the DECs and Suns that I started programming on. Go install gcc on your mobile, load up some old code (or new) and see how it does- you might be pleasantly surprised.

Also note that somewhere, a programmer with 47 years of experience is preparing to write a scathing response detailing how FORTRAN is the only real programming language...

Re:Enough with the toy languages (1)

Anonymous Coward | about a year ago | (#43966391)

A lot of serious number crunching these days is being done using R [wikipedia.org] . R seems to be filling the role in at least scientific fields that FORTRAN occupied in past years, though you still see some new FORTRAN code as well...

Languages like C/C++ get iffy when it comes to doing serious number crunching, unless you are careful or are using the libraries of someone who was.

Re:Enough with the toy languages (1)

Jamu (852752) | about a year ago | (#43966615)

So done using a language written in C, libraries written in C, and further libraries that depend on the language and libraries written in C?

Re:Enough with the toy languages (1)

MiniMike (234881) | about a year ago | (#43966813)

R seems like a good Matlab alternative, rather than a good FORTRAN replacement. I have similar code in Matlab and C++/VC++, and in terms of speed the C version rips Matlab a new one and then dances around it. And that's the Debug version. If execution speed is less of a concern R and Matlab are both fine.

If you're not careful you probably shouldn't be doing serious number crunching.

Re:Enough with the toy languages (0)

Anonymous Coward | about a year ago | (#43967877)

R is not a Matlab alternative. R is a statistics package with several constructs and built-ins for statistical analysis. Matlab on the other hand is generally for "matrix" oriented mathematics, think linear algebra, differential equations, control systems etc.. while you can probably shoe horn R to do Matlab stuff or visa-vera they are definetly not alternatives.

Re:Enough with the toy languages (1)

digitalchinky (650880) | about a year ago | (#43971001)

I'm quite sure you have the wrong idea about this. Canvas isn't only for games. I've just finished building a DICOM viewer (similar to eRad) using HTML 5, canvas, Javascript and WebGL for a client. For sure there are stand-alone apps that are a tad faster. The advantage here is that a radiologist can read a study from anywhere that has an internect connection using a bog standard web browser.

If I thought like you I would have turned the contract down. I wasn't even sure it was possible when I started, but I'm glad I was distracted enough by horse shit theory and OOP that I said sure, why not, I'll give it a shot. Saved a few lives along the way too.

Re:Enough with the toy languages (1)

The Cat (19816) | about a year ago | (#43972479)

I think I made it pretty clear my remarks were directed specifically at games.

Re:Enough with the toy languages (1)

Oligonicella (659917) | about a year ago | (#43972291)

Spent a similar amount of time in the business. Your views are ossified.

That is all.

Canvas is discussed; now what about networking? (1)

UnknownSoldier (67820) | about a year ago | (#43973171)

Cool to see HTML5 becoming almost complete for game dev.

How people handling pseudo-realtime TCP/UDP packets (networking) in HTML5 ?

Re:Canvas is discussed; now what about networking? (0)

Anonymous Coward | about a year ago | (#43979127)

HTML5 WebSockets

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>