Starter Game Sample Now Available

Starter Game Sample

The Starter Game sample allows you to see how Lumberyard systems are used together to make a game. Starter Game is a small, third-person game that is built with the Lumberyard component entity system. In addition to component entities, Starter Game demonstrates bipedal locomotion, voxel-based global illumination, the time of day system, and more. In this sample, you play as Jack, a robot that has crashed on a distant planet. Jack can explore the world and must defend himself against enemy robots that occupy the planet. You can use Jack or any other assets in the Starter Game sample to prototype your own projects. For more information, see Starter Game Sample.

Read more about the Starter Game in the Blog: http://amzn.to/2rnlutJ

Watch the tutorial video: https://youtu.be/HakIPkpJta0

Hi Dear Binky ,

Great , thank you so much lumberyard team.

I have Two suggestion to lumberyard team:

01-please add other features to this example(develop this template/example for advanced example)

02-please make this example with Script Canvas visual scripting language in lumberyard 1.10 or 1.11.

also I have a question : this example is independent of c++?? I know this example implement with lua script , but I do not know , this example develop dependent of c++ completely or independent of c++ completely???

also next suggestion :

if it is possible , please make video tutorials or PDF files about this example, How to make this example step by step in video tutorials or PDF files , thanks a again :wink:

AhmadKarami, there is some C++ included in this example, it is located here: \dev\Gems\StarterGameGem\Code. From my initial review of the example, most of the code looks like it is LUA and only a small amount is in C++.

Lumberyard Team and Climax Studios, Starter Game is absolutely fantastic! THANK YOU!

You did a great job bringing together together so many different pieces in this comprehensive example. This is going to be a huge help to many of us getting started with Lumberyard. I think you found a great balance between simplicity and scope - the game design is simple enough to provide the shortest path to understanding the implementation of various engine features, while providing a broad enough scope of features that it really gives an end-to-end perspective with a lot more real world practicality than a feature-specific tutorial.

A quick glance at the last few releases shows that the Lumberyard team continues to develop at an extraordinary pace. Given that, I know that real thought was put into whether or not to make this much of an investment into a sample given the pace of change with the engine’s features and systems … so that fact that you invested the resources into putting this together for your community really speaks volumes to me about your commitment to your customers and your community.\

So far I’ve seen seen pretty consistent commenting in the code and intuitive function / variable names - which is quite helpful. Starter Game makes good use of the Component Entity system, including showcasing the value of using out-of-the-box components and situations where custom components can be used to augment the capabilities of out-of-the-box components or to create unique, game specific capabilities.

I’ve only just begun to dive into Starter Game, but I wanted to take a break for just a moment to give some feedback. Thanks again!

There are a few issues with the sample.

  • ai is almost static… never walks just still and shot.

  • a bug in some areas makes the ai disappear even when you are very near to it.

  • character inversion of movement direction is very unresponsively slow.
    Overally.

  • There is a missing opportunity with documentation as no slice in the sample uses the new comment component that may be very handy in these kind of samples.

  • Sample not using fbx for everything is another missed opportunity.

  • This sample made clear for me that the usual way to communicate by string game events is quite weak by any means and need to be replaced especially in input management that now uses a redundant script component for every input event string.

  • Still the mix between legacy and component entity makes you to jump back and fort with the new and old editor ui and where something belongs to may still confuse new users (where to find something in layers vs entity outliner).
    Future

  • Show how to optimize the scene to scale to less powerfull pc.(especially how to setup proper occlusion culling as now the massive vegetation hits hard on fps even in the interior area.

  • Sublevels that isolate learning and show off single elements

another issue the laser material sometime get replaced with a default one ( the red replace me one)

I have observed the same issues that Gamely is describing. Lots of problems with the AI and movement. The underlying code is there for the AI to be a lot more responsive but it seems to struggle with movement and pathfinding. I don’t see a very cohesive connection between the input driven character movement scripts attached to the AI characters and AI navigation/pathfinding - it is a bit odd how the custom coded navigational bus was created to pass back the first waypoint to LUA. After reviewing all of the related code, LUA or C++, and adding a lot of debugging statements it seems like there are some fundamental issues combining the two systems to get the AI to move. I’ve also noticed some typos, problems involving race conditions, and a couple of undeclared global variables in the AI/movement related code.

Thanks for the feedback guys. I’ve sent it to the team.