Sprint goal

Think of the significant risks and uncertainties that need to be mitigated when developing a complex product. What hypothesis ought to be tested now? 

A Sprint Goal may emerge at any point during Sprint Planning, but it will give the Developers a reason to work together during the Sprint, and not on separate initiatives. The coherence may be a feature or it could be a joint commitment based on flow, for example.

Expect divergent opinions and some degree of annoyance when doing creative work. People have to diverge before they converge. If that isn't happening, you've got a problem.

how to define a good sprint goal and when during the planning should you pick the goal? 

The goal can be picked anytime during the planning. Your product goal should be the guiding light to define the sprint goal. I have seen teams struggle to define a single sprint goal. If that is not possible you could have the team add multiple goals (try to define SMART goals). There have been cases where prioritized work is selected and then a goal is formulated. No matter how you formulate the goal it is important to have one so that the team have a common focus.

The Sprint Goal needs to answer the question "Why is the Sprint valuable to the Stakeholders". Thus the team needs to have an understanding of the stakeholder's perspective. Especially the Product Owner is expected to have the most awareness about the 'bigger picture' and the stakeholder's needs and understanding of the value. 

Also, the stakeholder's perspective on the value is being shaped by the input from the Scrum Team.

What is Value, depends on circumstances. Sometimes, it might be reducing the technological risk, another time it may be probing the market with some new feature, another time it might be getting the funding to continue the project...

Discovering the proper thinking about the value in the given endeavor and shaping the Goals is not trivial since it goes beyond the Scrum Team and is very much connected with the organization. 

It is also connected with figuring out the right duration for the Sprint. Commonly, teams decide to go with two-week Sprints and mainly use Sprints to divide work, while it needs to be more about achieving valuable Goals through producing usable SW Increments. Often not possible in two-week Sprints. 

Think of the Sprint Goal with flexibility in mind. It doesn't need to occupy 100% of everybody's time in the Sprint. It takes priority in the Sprint but it doesn't mean the team can't do anything else. Also, it doesn't mean throwing something out of the Sprint ruins the Sprint Goal. 

Let's say the team develops the game, and the Sprint Goal is to: introduce a new type of weapon to generate fresh attention from the gamers community. What kind of weapon, what characteristics in needs to have is quite flexible.

Let's say the team develops a driver for the display card, the goal might be: to decrease the power consumption by this and that range to catch up with the competitive drivers. (What exactly needs to be done is flexible)

If the Product Owner and the organization are not ready to formulate goals, I wouldn't force it on the Scrum Team to have the goal at all costs. I would rather work towards showing the advantage of goals oriented approach to the Product Owner and the stakeholders first. They might not even know yet that this is the central part of Scrum.