And...Disney Infinity is officially cancelled.

Disney has announced that they are shutting down Avalanche Studios, and that Disney Interactive will no longer be working on any internal development. It will be 100% licensing of properties now. Basically, they're going to be extending the Star Wars/Lucas Arts model to all Disney properties when it comes to video games.

I am personally disappointed by this. I really liked the Disney Infinity games. And I really liked the figures that went along with them. They were cleaner and more elegant than a lot of the other toys-to-life efforts.

It will be interesting to see how this move affects the toys-to-life market. Infinity was one of the larger and more successful competitors in that space. They still account for a sizable chunk of shelf space. Having them bow out will make a bit more room for other multi-platform games like Skylanders and Lego Universe.

Another beta update for Lumberyard. And again we're seeing significant and desirable updates that improve the engine's usability. Improved options for the FBX importer they integrated in the last update. New networking tools that allow for network functionality without coding. GPU-supported particle rendering. Good stuff.

It's encouraging to see them continuing to support their engine on a regular basis, and I'm still liking the focus of the improvements they're making. A visual flow editor for networking support will make it easier for people to start supporting multiplayer features on their games. (an obvious draw for Amazon, but improving the usability and reducing the learning curve are still benefits for the end-user)

I would like to see someone create a more modestly-scaled title with this engine, and provide a post-mortem. Unity is still the prototyping king.

I feel the obvious would be restrictions.
If I want to make a side scroller/top down, what would I be restricted to?

If those are the perspectives you're thinking about, you actually have quite a few options. Most game engines can handle that sort of thing.

I usually point people to either Unity 3D (an obvious choice) or Godot. (a less obvious choice) Both of these engines have extensive platform reach, have inexpensive options, and play nice with low-cost open-source content creation software. They also both have scripting systems, which allows you to ease your way into programming.

[too]

My third attempt at an actual animation. I think it's got a bit too much energy but it was fun nonetheless.

Exaggeration is a key component of animation. You generally don't have to worry all that much about taking your animation TOO far. More often than not, it is better to push it a little too far. Exaggerated animation looks snappy and appealing. I think your puppy animation is quite nice.

If you have any classic Disney or Don Bluth films on your shelf, pull one of them down sometimes and do a frame-by-frame on some of the more striking animations that they have in them. You don't always catch it while watching them, but some of the faster, snappier animations in those movies use some incredibly over-the-top exaggeration. It's actually kind of hilarious seeing some of those animations frame-by-frame.

It's really becoming pointless to choose one "right" language. The truth is that anyone even partially serious about learning coding is going to learn multiple languages. I'd start with a something like C#, with strict typing but also memory management. It's a good language for learning some programming basics, and especially for getting a grasp on object-oriented programming and inheritance. (a concept that can take a little while to wrap your noodle around)

After that, I would learn javascript if you want to go higher level, and C++ if you want to go lower level. All three languages are ECMA-script, so the general syntax is very similar. (decent crossover)

Not a bad idea to get started with a few markup languages as well. HTML and XML.

There's never going to be just one "right" language. Learning a programming language is just adding another potential tool. Some are more flexible than others, but sooner or later you might find a use for even the more obscure ones. Start with one of the more flexible ones, but be open to the idea of learning more than one.

I care if I can make (3d) games for odroid** or  raspberry pi0

Technically, yes you can. But as you yourself pointed out, that is a low-level operation. I know that at least one person has ported Godot to the Raspberry Pi. But there is currently no official support for this effort. Godot is open-source, so you can do whatever you please with the code, and port it to whatever platform that you can. The fact that one person already ported it to the Raspberry Pi indicates that it is fairly port-friendly.

It would be great to see the community surrounding Godot port it to all sorts of platforms. Micro computers like the Pi are fairly under-served when it comes to game engines. Godot could easily become one of the go-to engines for such platforms with its integrated tools and visual editor.

An engine with that level of learning curve would really have to solve some unique problems to justify the 200+ hours I would need to work with it to get proficient.

Well, that's why I made this post. Lumberyard had its first update, and it addressed several of the initial issues that a lot of users have with the original Cryengine. So Amazon's gaming division is actually listening to users and addressing some of their concerns with Lumberyard to make it more its own thing. This is a good step in the right direction. It just isn't enough of a step in the right direction to persuade me to leave the technology I'm presently using. (and am comfortable with)

In time, Lumberyard might become considerably easier to use than Cryengine was. For now I still maintain a wait-and-see.

Not really much in the way of responses to this thread. But that makes sense. At the moment, there really isn't much to talk about or discuss where Lumberyard is concerned. And I certainly wouldn't expect any current indie developers to jump off of the technology stacks they're currently working with and shift over to Lumberyard. I'm still working in Unity, and fully intend to continue with that engine.

Lumberyard is mainly interesting for how it started out, and who's behind it. I'll continue watching it with interest, but I don't expect to be dappling in it any time soon. In the current highly competitive middleware market, Lumberyard has an uphill climb in front of it.

I haven't seen much buzz on these boards about it, but the Lumberyard game engine was announced and released by Amazon earlier in the year.

And I can understand why there might not be that much buzz. Lumberyard is a licensed fork of the CryEngine. In its initial state it was essentially little more than a CryEngine clone. Anyone not already on board for developing with CryEngine wouldn't be interested in Lumberyard.

With its first upgrade, Amazon is showing that they are listening to the community. Lumberyard now supports iOS. It has also gotten a proper FBX importer, allowing for a much broader spectrum of 3D tools. These are small steps, but they are steps in the right direction. I will continue to watch how Amazon handles its "new" game engine.

Well, it depends on what you're using for the "curved" surface. If you are using a 2D sprite to depict the curved surface, it would be considerably more difficult. If you are using some manner of 3D or 2D geometric construct, it becomes quite a bit easier. This can still work with a 2D sprite as a visual depiction, so long as the collision for the 2D sprite is defined geometrically.

Any collision system worth its salt will allow you to get a reference to the object that is causing the collision event. If you have that, you can get the information of the actual geometry you are touching. From there it's just a matter of calculating the normal, and using that to adjust the rotation of the 2D character moving along the surface. Your best bet to make sure that this rotation stays smooth is to give the 2D character a target rotation that is separate from their actual rotation. When they shift to a different facet of the collision model, adjust the target rotation, and then have a constant update that causes the 2D character to rotate towards its target rotation. This will keep the rotation looking nice and smooth.

The best way to make a character stick to some circular object is to alter its specific gravity to be constantly targeted toward the origin point of whatever you need it to stick to.

Godot

It's cross-platform. It allows for exporting your projects to Android and iOS. It supports networking. The development tools and environment run natively in Linux. (I've tested it myself in Ubuntu, works like a charm) And the whole engine/editor is available under the MIT open-source license. So it is free for commercial use, and you can even edit the source code however you need to. Also, the source code is primarily in C++.

This is the best recommendation I can think of given the criteria you are looking for. Good luck.

On earlier versions of this engine, I wasn't able to get shape-key animations exported from Blender. I've been working on lip-syncing for in-game graphics, so this was a bit of a problem for me. Around two or three releases ago, the Collada exporter they provide for Blender started exporting the shape-key animations properly, and I was able to get them running in-engine.

My cup runneth-over with things I'm busy with in my personal life, so I don't have enough time to dig into Godot properly right now. Later this year I might be able to dig into it a little bit more. I'm hoping to eventually port my lip-sync plugin for Unity over to Godot.

I've been kicking around ideas like this for years. It is a good approach to making a game. The challenge comes with the monetization, but that's a different problem.

In this day and age, the approach you're describing is one of the better options for making a local multiplayer title. Local multiplayer has always been one of the most appealing gaming experiences. Playing with others, and having them nearby, is an optimal way of enjoying almost any game. The biggest barrier to entry for this has been the up-front commitment. For more traditional experiences, you have limited screen real-estate, you need a controller interface for most of the players, and you occasionally need multiple copies of a the game.

Using smartphones is a good solution for this. They are screens that most adults already have in their pockets.

Like why make a new Python-like language?  Why not just... use Python?  You can't put GDScript on a resume (yet).

I think part of this was just that Godot started off as a proprietary in-studio engine. It wasn't originally intended for broad use or acceptance, so they just cranked out an in-engine scripting language for internal use. There was no real need/incentive for them to support other, more common scripting languages because the engine wasn't intended for broad use. Perhaps such standardization will be incorporated in the future. As I pointed out, the community team maintaining the engine seems focused on usability for the immediate future. It could be an option for a future update.

For the time being, it isn't all THAT much of an issue. I've toyed around with GDScript a little, and it isn't very hard to pick up. Anyone familiar with most high-level scripting languages won't have any real trouble jumping in and getting started. A slightly higher barrier-to-entry would be writing custom modules using C++. Entirely possible in Godot, but C++. (shiver)

If you're looking at it from a long-term time and money perspective though, there is a reason Yet Another Programming Language has a tendency to spur groans.

Well, I'm still working in Unity, if that tells you anything. We all know that switching languages is a non-trivial issue. No one is trying to say that it isn't. While I like Godot, and enjoy watching its progression, I'm still working in Unity for my projects. A lot of this is based on my existing familiarity with the engine and the language it uses.

All the same, I like what Godot is doing, and I like that it exists. I kind of feel like Godot is to game engines what Blender is to 3D modeling/animation software. It's an open-source indie-friendly option. It might not always get the best support thanks to its open nature, but I'll always be glad that the option is around.

Hover your cursor over one of the edges of one of the windows in the editor. Right click. It should give you the option of splitting your window. Now you have two windows. Switch one window over to the UV editor. Switch the other window over to a 3D view. Now you can see your model in 3D while also editing the UV map, and you will be able to see the changes on the model as they're happening in real-time.

I do this all the time. Being able to see the changes in real-time is very important for editing/optimizing the UV mapping. I'll commonly divide the main 3D window into two windows when I want to do simultaneous editing. You can always re-combine them later if you want to. (same process, just select to join the windows instead of splitting them)

I like the direction they went with on the 2.0 revision. So often game engines attempt to push graphical features for revisions, obsessed with competing in terms of visuals. The Godot 2.0 upgrade is clearly focused on improving and refining core functionality and stability, while also polishing up the user interface and workflow. This is a good direction for them to have taken, especially given the open-source nature of Godot. Making Godot easier to use is far more important than graphical features. I approve.

You are mistaking "art" with "illustration." Even a game that relies on "programmer art" still contains art. A sense of style, proper framing and composition, and color balance are all necessary, and are all essential fundamentals of art. But none of those elements require complex or sophisticated illustration. In art school, it is common for students to practice these elements using cut-outs of construction paper, utilizing simple geometric primitives. A similar exercise using basic programming or 3D modeling should be relatively easy for anyone familiar with 3D modeling or a modern 3D engine.

So, no. A good game will have some degree of artistry incorporated into it. That artistry simply doesn't have to be advanced or complicated art. It can be very simple art using basic artistic fundamentals, and it is entirely possible for people who don't consider themselves artists to learn and practice those fundamentals. Learning to recognize and follow those guidelines for art can imbue your game with all the general visual appeal you require, even if the specific visual elements are nothing more complex than simple squares or other geometric shapes.

But I'm a little baffled as to why you want tutorials like that. Most tutorials are not general because it's not the best way to learn as a beginner.

Actually, I think there's a fair amount of value in such tutorials for beginners. It is often a lack of understanding of fundamental but not language-specific constructs that trips beginners up. A few more tutorials regarding such subjects in an easy-to-grasp format would be useful, and help to make game development more approachable.

The steep technical hurdles are what keep most people away from game development. Modern accessible engines have been rapidly lowering those hurdles, but more effective education could go a long way towards lowering them more.

It worked pretty good overall. I think it was something like certain emulators werent displaying rom lists.

If you're not afraid of editing some text files, it is actually possible to customize the rom list displays pretty handily. I did that with the Capcom CPS section. Those packages are multi-part, and are generally a pain in the butt for displaying in a list. But if you know what you're doing, you can re-name the files, scrape the metadata and images for the files, revert the file names to their original settings, and then disable emulation station's search function for that platform. Once you've done this, emulation station will use the XML file generated by the metadata scrape for the rom list, and ignore any detected files. You can even do this with your own custom XML file if you have custom art you want to use, or custom descriptions.

Pretty much everything in emulation station can be customized to one degree or another. I'm really loving that front-end.