The fundamental point is simple: we’re in the middle of a sea-change in the gaming industry. The experimentation with “free to play” is over and then rush to embrace virtual items as a revenue model is on. As an industry, we’re replacing subscription-based revenue models and advertising-based revenue models with incremental retail revenue models.

And yet, among the early adopters, almost nobody does discounting, promotions, buy-one-get-one-frees, or any of the other things that modern retailing has perfected.

Hence the talk.

A list of simple, easy (at least, if you’re using Live Gamer Elements), and obvious ways to drive revenue that don’t involve changing gameplay.

I recently gave a talk at SDForum’s Emerging Technology SIG on why the problem isn’t as easy as it looks. I mostly stayed away from Twofish’s solutions (the intent was not to give a product pitch).

Slides here.

One review of the talk here.

Today, I found out that John died last November.

Rest in peace, father John.

I can personally vouch for Chris: bright guy, knows his stuff, reasonably good speaker.

In fact, I’m sending two people from Twofish to the talk.

It was a little bit of an unusual talk for me. Prior to this talk, I hadn’t spoken at a Java event in for a little over three years. My attention, to put it mildly, has been elsewhere. But, even though I don’t pay much attention, I love Java. It’s a nice language and it’s a great platform. In fact, I’ll put that in a pull-quote, in bold:

Java is, by far, the best general-purpose platform for software development currently available.

But, even with that, the most ardent fan of Java has to admit two things:

• A large part of being the world’s best general-purpose platform for software development involves repeatedly improving the core — better libraries, faster JVM’s, amazingly robust backwards compatibility, making sure things like OSGI work and that provisioning is both easy to do and automatable, etcetera etcetera etcetera. While important, highly valuable, and hard to do right, this sort of thing can also be deadly dull. And it’s far too easy to take the grace and stability of the platform for granted.
• Every deep sea-change in how we write software happens elsewhere first. For example, Ruby on Rails signified the rise of “convention over configuration” and a renewed focus on DSLs . And Cloud Computing hit first, and has hit hardest, for the more dynamic languages.

And so a large part of my “cutting edge technology attention” has been on other languages and platforms.

Which is why I’ve been truly excited recently by the increasing adoption of Groovy and Grails. These are great steps forward for the Java platform: they take the lessons learned elsewhere and bring them into the Java fold in an amazingly nice way.

And that’s really what I talked about.

But, on the other hand, it’s an awesomely useful service and I, for one, am thrilled to put my presentations out there.

http://www.slideshare.net/wgrosso

One of the thing’s I’m revisiting is a talk by Todd Proebsting entitled “Disruptive Programming Language Technologies”

It’s a glossy talk, very high level and talking about what might make for the next great programming language. He gave the talk in 2002. Since then, I think we’ve seen the rise of exactly zero new programming languages but the Tiobe index since then has shown an interesting shift: Python, Javascript, and Ruby have all crept up the index, taking market share away from the leaders (Java, C, C++). I think the lesson there is that, in the absence of stunning innovation, progamming language feature sets tend to level out and therefore, the playing field levels somewhat.

But, the question is, what happened to Proebsting’s list?  He gave five candidate “disruptive” features for a new programming language:

1. Flight Data Recorders. Add persistent, automatic “tracing” of function calls, events, I/O, etc. to the language run time.
2. Checkpoints / Undo. Make checkpointing and undo (i.e., restoreto checkpoint) primitives in theprogramming language.
3. Parsing. “Scannerless Generalized LR Parsing” (or Earley parsing) could be integrated into a language.
4. Constraint Solvers. Integrate linear programming constraint solver (or, better, integer programming) into a programming language
5. Concurrency. Concurrent functional programming language.

I think that Erlang is the way the world is experimenting with the last bullet point. And that Groovy’s builders are potentially a different approach to parsing that might meet the sub-criteria of his third bullet point. But bullets 1,2, and 4 seem to be potentially huge and valuable innovations that aren’t currently being addressed.

Is it that we’re stagnating? That I’m overlooking things? Or that these aren’t that important and there are other, much more important, things being cooked up.

The rise of next-generation languages that run on top of the JVM is probably the most interesting thing to happen in the Java universe since the combination of the Spring framework and the EJB 2 specification signalled the complete implosion of the Enterprise Sofware Stack

In this talk, I’ll cover, in sequence:

• A brief overview of the state of the art of web application development
• A brief overview of Groovy, one of the most interesting of the next-gen languages available on the JVM.
• A brief overview of Grails, the best web-application framework currently available (where “best” is, of course, highly idiosyncratic)
• The source code to an actual working web application written in Groovy/Grails.

But, in reality, the talk will mostly be about next gen JVM-based languages and programmer productivity.

The thing that impresses me the most, as I think through the argument, is how consistent I’ve been for the past 6 years.

In 2003, I gave a colloquium talk at CSU Sonoma on why Java is much better than most people gave (or give) it credit for. I was completely right, and the arguments I gave there still mostly hold water. Which means that, for the coming few years, I think Java is still going to be the dominant programming language.

In 2004, speaking at No Fluff Just Stuff (and clarifying afterwards), I made the following four claims:

1. The rate of programming language change and adoption in the mainstream is going to continue to slow down.
2. The style of apps we build will more or less be the same.
3. I think that “web-architectures” (fat server, thin client, markup delivered to interpretation engine) are good enough for >95% of our apps.
4. Server-side container architectures are slimming down and becoming less overwhelming. But client-side containers (and that’s really what a web-browser is) are going to take off.

Of course, the world is changing now. The current downturn, the general maturation of everything, and the rising of what I, with only mild levels of sarcasm, will call “LISP-like language features” means that it might be time for a sea-change.

I’ll know what I think when I finish the slides for my January talk.