{GAME] [DEV-DIARY] Space Game

Kreeba

I hope nobody minds, I would like to start a little Dev Diary for my game, and use you guys for alpha feedback?

I am a teacher by day and was inspired by seeing how my students work together on the occasions we have used Artemis. We have just got Chromebooks, which are great laptops, but aren't very compatible with existing software. So I decided to take the summer and try to create a 100% browser BridgeSim.

My short-term objectives for the sim:
-Captain, Helm, Weapons and Science stations.
-Embed Middle-School maths and science concepts where possible.
-Always on server with NPC enemies to facilitate casual drop-in/out play.

My lofty admissions are to further extend the genre by including controls for admirals (issuing orders to multiple ships via a RTS style interface) and full player factions with control points, resources and design-able ships/stations.

I haven't had much game making experience, however I have been teaching myself JavaScript over the last year. I have been working on it for around 5 days now and got a basic demo of multiple ships with captains and helms officers.




Test Server (might very well be down/crashed/broken).
-There is no weapons right now
-You can open 2 browsers if you want to connect yourself

kwadroke

Nice. Looking good so far. Keep us updated.

Kreeba

So Alpha 1 is still online. I am looking at the weapons and sensor systems now moving to Alpha 2

When doing an open network game it is important that you don't trust the client with any data they shouldn't have. This is especially important with a JavaScript game, as the front-end client code is readable available.

What this means is, if an enemy ship isn't in sensor range of the player ship, the player ship shouldn't receive any network data about that enemy ship (effectively mirroring what a real sensor does).

To help the game calculate weapons and sensor ranges I build a new Arc system which I can use for weapons and sensors:

Sensor and Weapons Range Detection Example

Notice, when the sphere (enemy) goes behind the player ship and our of the sensor range, he is no longer visible. The enemy model goes invisible and the players inside the player ship stop receiving any data about that enemy ship.

smcameron

Cool. One thing I noticed while making Space Nerds In Space is that there's a tension between realism and fun. For example, if you try to make planets and ships realistically sized, your space will be so huge, and you'll have to travel so fast that you will have little hope of ever seeing another ship except as a very distant dot. So you shrink the planets and the space down and slow things down to make things more reasonably close together for game purposes, so that you can see other ships as more than just dots and have some close combat, etc. And then you try to restrict the sensor range, but you realize that when you do, things drop off the sensors when you can still see them out the window in the 3d rendered view (or else, they disappear from the 3d rendered view unreasonably close). It turns out you can see a long way out the window. So you kind of find some balance and compromise among these tensions as best you can. Or at least that's how I found it to be. (Don't really have any recommendations, just kind of thinking out loud.) BTW, that last youtube link seems to be broken.

smcameron

Played around with this for a bit. Couple things I noticed (of which you're likely aware already, but I'll mention anyway): 1. The direction indicator on the helm is a very very tiny dot. That should probably be made more visible, maybe a little triangle or something. As it is now, it took me awhile to realize it was even there and realize why the ship was suddenly turning (because I had clicked on the circle, and moved the tiny dot, and the ship was swinging around to point towards the dot.) If it had been a more visible arrow, I would have not been so confused. That being said, I did figure it out. 2. Sometimes the ship seems to take the "long way around" to make a turn, instead of turning 90 degrees to the left, it turns 270 degrees to the right (a made up example... but I saw it do something like this at least once.) 3. That the game runs in the browser and you just point your browser at the server to run is super convenient and I'm envious.

Kreeba

I have fixed the video link in the previous post

Thank you for the feedback and suggestions about scale. These types of informed ideas and valuable experience is exactly why I wanted my Dev-Diary in this community.

I was actually thinking about scale and sensors whilst looking at your 3D scanner and how it shows faded meshes when things are not quite in view. I believe I will keep planetary bodies always visible in wire-frame form.

One thing I want to aim for is having admirals giving orders to player fleets who are in guilds. The guilds would be able to take planetary bodies to control sectors within a system. Sensor range is important for this as I want the player controlled fleets to have to patrol and/or maintain sensor buoys to scan for any possible threats to their space. The Admirals and leaders of the guild will then be able to see all activity within all ships and sensor boys within their guild etc. I am trying to think of mechanics to enhance the player experience, especially forcing them to have to cooperate.

I have been doing some experiments on the scale and visual style and am collecting inspirational shots. I want to aim for more 'hyper real' rather than realistic, something akin to the visual style of the new Star Trek movies. My inspirations board:

Space Game Inspirations Board

Things like having visible warps in the grid to represent gravity with warped space/time, and that effects the ships movement so the helm has to compensate. Visual magnetic poles with energy that players can hide in.

To come in on your points:
1) Yes, it is terrible JQuery Overlay right now. I am debating how best to implement UI on a browser based game. If I go with HTML as on overlay or I build it within the 3D engine.
2) My rotation maths is a bit off right now
3) Thanks. The stack is:
NodeJS for Server
Socket.IO for communications
Babylon.JS for 3D Engine

I am recoding everything using Typescript and refactoring to get in repeatable and scalable systems before adding anything else.

Kreeba

Hi All.

Over the last few days I have been converting over the codebase to TypeScript to have shared base classes across the client and server. This will, hopefully, make the codebase easy to extend going forwards.



I have a basic weapons system going, which I am integrating with the main game over this week.

My targets for Alpha 2 End-August
-Captains Station (crew management, tactical awareness, central communication)
-Helm Station (heading, speed, jump engine, gravity compensation)
-Tactical Station (targeting, weapons, shields)
-Single Solar System
-UI for Captain, Helm, Tactical (aimed mainly at 7-13 inch touch and non-touch displays, the main devices in schools)

Alpha 3 November-December
-Science Station (enemy ship analysis, long range tactical scanning)
-Engineering Station (power distribution, repairs)
-Inter-ship voice communications

daid

Very cool.

From my experience on EmptyEpsilon. I recommend focusing on getting the basics right first. Which requires a lot and a lot of playtesting (We almost had weekly sessions at my office once I had the basic game running)

Enemy AI (and AI in general) is difficult. But your players will already have lots of fun with pretty stupid AI that only attacks you straight on. So implement nothing fancy here. My initial AI couldn't even use missiles for quite a long time.
As soon as your world gets a bit crowded, you will need some form of pathfinding. But the general examples of pathfinding resolve around grid based perfect path finding. I have a different implementation that isn't a perfect solution but can avoid flying into objects with very little calculation time, as empty space is not taking up calculations:
https://github.com/daid/EmptyEpsilon/blob/master/src/pathPlanner.cpp

Science is essential for the game. Until you have some form of long range view, the ship is usually blind. So delaying that in your plan might not be wise.


I would do the UI parts in HTML overlay. For the simple reason that some designer can drop by and style up your UI in CSS pretty quickly. The hard coded (and slightly unwieldy) UI code of EmptyEpsilon is one of it's pitfalls. Most of the work IS in the UI. (about double the amount of code is in the UI compared to "in game objects")

Kreeba

Good Day everyone,

I am pleased to post a short video on what I have been up to:

Dev Diary 2

Apologies for the quality.

Kreeba

Hello Everyone.

I have almost complete Alpha 2, I just have a couple of things left to add. The Helms and Tactical UI are currently active, and I am mainly working on the lobby system now.

I have produced a new video just to show you where I am now.

Dev Diary 3

smcameron

Looks cool, congrats on getting Helm and Tactical working, since as everyone knows, driving and shooting are the two most important activities of a starship captain.