Some sort of starship-building game that I have yet to name.

Hello, all!

I'm not sure if this is the correct place to post something like this, but it seems to be the best place. It might get long, but here goes:

I've had this idea for a game in my head for a long while now, and I've been adding ideas to it over time. I just want to write it down somewhere so I can have an organized place for all of my ideas (and future ideas) that relate to this game, and also so that I might be able to get some feedback on whether they're actually good ideas or not. I want to make it eventually. I really hope this (or something like it) hasn't been made before.

So, I'm thinking something like a game set in space, and it's a collect-resources-from-asteroids-and-build-your-own-ship sort of thing, but I have some ideas that would probably make that more unique. Also, I'll have it be side-view, like Terraria or Starbound.

First off, some sort of story-ish thing behind it would be good, instead of just spawning in with a basic ship. My idea so far is this: You spawn in on an asteroid as a broken probe. Really, it's just a computer core with a fabricator, drill, and broken solar panel attached. You have a limited battery life to find some quartz and fabricate a working solar panel,  and then from there you can build onto your ship.

But something else- inside the computer core is an AI (who I've thought to name LUNA, or Layered Universal Navigation Assistant or something idk) who knows how to survive, in theory. She(?) has knowledge on things like how to fabricate things, how to survive, how to build/program (more later) your ship, and other such knowledge, like what certain ores can be used for and stuff. She also regards the player as if they are simply just another AI inside the core, but one who is able to actually manipulate the world and build/program/control the ship, mine, etc. LUNA is just an informational assistant, really.

What I'd like is for the player to be able to actually ask LUNA questions via a chat sort of thing, but I have no idea how to go about it in Stencyl. Let me start with an example: If you ask Alexa "what's the weather like," then she can tell you the weather. But if you ask her "what's it like outside," she has to be able to understand that both of these sentences mean the same question, and therefore she must give the same response. So I'd like to have a database of questions/answers and have some sort of AI that can detect which question is closest to what the player has inputted.

But that's all super complicated, and again, I don't even know if Stencyl can support a text-recognition AI, let alone how to do it. For now, then, she just gives you information when it happens to be needed (like, mining quartz ore for the first time would trigger dialogue about quartz).

Now, an idea that I absolutely love- programmable ships. Instead of set controls for certain things, like WASD for movement, or a certain key to fire guns, I think it would be better for the player to have to wire up their own inputs to their devices. These wirings would originate from the computer core, and each one would correspond with whatever keyboard keys the player desires. For example, W could activate thrusters on the bottom of the ship, making it move upwards. Also, these wirings could be modified wit simple logic gates or delays to allow for different things to happen. For example, you can't shoot through your own shields, so you'd have to have, say, key X turn off shields, (NOT gate) then after a delay of .1 seconds, turn on all of the guns.

And these are just activation wirings- but there could also be state-change wirings. Say you have some auto-fabricators that are manufacturing batteries based on the things they're getting from conveyor belts. When you press, say, K, a state-change wire can change it from crafting batteries to crafting guns or something.

Everyone's ships would be so unique because there's no default control scheme. Each person who plays would come up with their own controls for their own ship, and if someone else came along and tried to use their ship, they'd have to figure out what everything does first.

Another idea I like is detachable miniships- you can put a smaller computer core somewhere, and have a specific block that lets go of the blocks it's holding when activated (again, whatever control you want.) Then you can switch focus between the computer cores of the main ship and the smaller ship. This would be useful for mining ships, or small fighter ships, or whatever else comes to mind. I don't think there should be a 'right way' to play this game, just make whatever feels right to you. Or you can make cursed ships that just fall apart at the press of a button, if that's your thing.
Of course, the game wouldn't be much fun if it was just building a ship. No, there also needs to be enemies. I feel like this would make an excellent multiplayer game, as everyone would have crazy ship designs that don't make sense to you except for things like movement and guns.

But, I don't know if Stencyl has multiplayer support in any fashion, least of all what I have in mind (like a server you can join and build/fight with others). So, singleplayer it is (for now.)

I would have randomly generated enemies (or maybe a bunch of pre-designed ships, since random ships might be terrible at shooting) that you would have to defend yourself from. Or AI-generated ships, but again, I don't know how to AI, and I don't know if Stencyl knows how to, either.
I'll probably use physics so that ships collide and stuff. As for being attacked, I think of it somewhat like each piece has its own HP as opposed to the entire ship's HP. If you lose the Core, though, you're done for good.

And shields, instead of just completely deflecting everything, should function like so: Say a laser has a power of 50. The shield has a power of 1000. The laser's energy is sapped away, and the shield is left with 950. But if the shield had 50 power and the laser had 100, only 50 would be taken from the laser, and the weakened laser would carry on to damage the ship. The same could work for physical projectiles, but instead draining velocity. Getting power into the shield is slow, so it'd be balanced as if you shot the shield fast enough, you could break it.

Of course, this is all just ideas I have floating around.I think there's more I've thought of but I forgot to mention. This is simply just the base of the game, the core mechanics. Please, feel free to tell me what you think of these ideas, or even suggest ideas of your own that you think might be a good addition! I'm open to any feedback and criticism. I'd like to know if this is a good idea before I try to make anything. I'll add more posts with more ideas as they come to me, or maybe some concept sprites/tiles.

And as for my other game (the foresty one), I'll still work on it! I've just been a bit busy lately and haven't had time to do much to it.

Thanks for reading!

I've got some ideas regarding item storage. I feel like there should be specific storage modules, like a block with its own inventory. But instead of having multiple stacks of each item, taking up slots, there should just be only a total item limit. So, say there was a basic storage unit block, and it could hold 400 items. You could have 354 of one item and 46 of another and and that would be fine, or you could have 1 each of 400 different items, or any combination of items that add up to 400, as opposed to a regular inventory that limits how much you can hold in a stack and limits inventory space based on stacks and not items themselves. Of course, some items would be bigger and take up something like 4 inventory space for one item, like a gun or something.

When building onto your ship, you have access to any of the building blocks stored in or around your computer core. Also, I think the player should be able to make item distribution systems and such: for example, when they dock a mining ship back onto the main ship, some hoppers or conveyors can take items out of its storage and put them into the main storage or divert them to fabricators.

Hoppers could take items out of things with inventories, and conveyors would move them/input them into other components. Since there's no gravity in space, items would just stick to conveyors instead of relying on gravity to hold them down. To go with conveyors, there could also be sorters and distributors and such. Like, you could filter a sorter to only take out copper and then any copper that goes through it is outputted to the left, while any other items keep moving forward. Distributors could just distribute items evenly across all connected outgoing conveyors.

A few things that would be better if I were to make this game:
First of all, I already have experience with Stencyl this time, as opposed to my other game which is full of tangled spaghetti that I made when I just started Stencyl. I would be much more organized this time.
Also, there's no z-ordering, since it's side view and not 3/4 perspective. Well, there is, but it would be static z-ordering. And not only are side-view tiles and sprites easier to for me to draw, I feel like I'd be much better at drawing starship parts as opposed to nature tiles because they're much more orderly and neat. Of course, I'd still have some nature tiles, like asteroids and ores, but the rest would all be starship parts and other such sprites. Though, graphical effects like shields and parallax background stars would be new to me.

Still, this game, if I make it, is going to be much more difficult to program than my current game. I'll figure it out if/when I get to it, I suppose.

Wow, this whole thread is just lots and lots of text so far. I'll see if I can maybe make some concept sprites/tiles and post them here at some point.

Hello Fayabella,

How nice to put in all your thoughts to this journal.

There are a few points I would want to advice:
* Start small
* Find your core-game mechanic
* Iterate over the design by implementing stuff rather than over-think-them
* Be prepared to ditch stuff if it isn't working

Even for an extremely advanced Stencyler this project is a huge one. No problem, of course,
but you said that you are not having too much time. It will be hard to keep motivated.

A bit more in-depth on the parts mentioned:
* Game set in space
Don't lock yourself to a view like side-view, maybe it will not workout.
Start with small blocks rather than detailed graphics

* Computer has an AI
This one is indeed very hard. I don't know of a HaXe library that can deal with text recognition.
It reminded me of the early adventure games where you had words like 'pick', 'look', 'walk'
You have to be really carefull that players need to interact a lot to get what they desire.
Later adventure games made clickable actions to interact with the game.

This comes down to the question: is this part of the core-mechanic of your game?
If it is, then you need to focus all your attention to it and nail it before you do anything else.

* Wire controls to actions
This one seems to be also very complicated, but I must say it 'sounds' better as a core-game-mechanic.
But you. ofcourse, need to find that yourself.
I'm not sure how much fun it is to put all the efforts in making your own ship and then to go
find other ships to take over. What happens with 'your' ship?!
People kind of feel attached to their own creations so be carefull if that is part of your core-game-mechanic

* Be carefull about statements like 'of course the game wouldn't be fun if it was just ...  '
Each little part of a game-idea can be fun. You have to find if that is the unique thing or very well implemented idea.
Some people like building things (look at minecraft) and enjoy the building more than the playing inside part.
'Need to be enemies' also a very bold statement. Maybe you don't need them if the game is about building.

* Multiplayer
A very, very advanced area. It is doable, but you have to know a lot of network knowledge to understand how to
work with lag. Because every online multiplayer game will have lag.
Again, if you believe that this is part of your game-core-mechanic and the game would only be fun if it was:
then spend the time implementing this.

* Shield mechanic
This, again, comes down to : is it part of the core-game-mechanic.
It could be, and it could be fun. Like how the Enterprise can 'defer power from the ... to the ... '

* Storage items
Well, just read my final thought about this.


All boils down to : is it part of the game mechanic and is it fun?

Be very,very careful to say : it is only fun when all of the ideas are in the game.
Some people like building things, others like to fight. While others like to find stuff.
If you want to find stuff and you need to fight off enemies every minute : you will quit
If you want to fight and you spend every half our to build things that takes you half an hour : you quit

Most of your ideas would take months to implement.

Also, talk to Bombini (maybe he'll join this conversation).
Some things that you mentioned are done by him. And he started his journal on 2014 (!)

mdotedot makes some really good points. Ludum Dare is coming up. That would give you a good excuse to take just one of these ideas and build a game around it. See how it works out.

I made a space station building game for one of the LDs (Aether Mine): http://www.stencyl.com/game/play/36669 The source code is still downloadable. I think it requires AI tools extension, though.

Speaking of AI, questions like "Stencyl can support * AI" are the wrong kind to ask. AI is a broad concept, so the answer is almost always going to be 'yes'. A better question would be "does Stencyl provide the tools I need to implement the theory out of the box?", and the answer largely depends on what kind of AI you're looking at implementing. I found the answer to be "no" for graph-based AI, which is why I wrote the AI Tools extension. I'm playing around with an event-driven system in my side project, and so far I've found Stencyl provides a great environment for it (custom events).

For LUNA ("...some sort of AI that can detect which question is closest to what the player has inputted..."), I can imagine a tree-based solution. Organize keywords in a tree and search the tree based on the player input.

The best place to start would be to make sure your math background is up to date. If you've never studied graph theory or statistics, find a good primer on both. If you have, then I'd also read about decision trees and Utility AI. Utility AI may be another workable approach for your ideas. Hectate has made some good posts on procedural generation in the forums--those are good reading, too.

There are a few points I would want to advice:
* Start small
* Find your core-game mechanic
* Iterate over the design by implementing stuff rather than over-think-them
* Be prepared to ditch stuff if it isn't working

Even for an extremely advanced Stencyler this project is a huge one. No problem, of course,
but you said that you are not having too much time. It will be hard to keep motivated.

Excellent advice; I usually spend too much time implementing random things that don't actually add to the core gameplay itself. And while I now have some experience with Stencyl, I wouldn't call myself an advanced Stencyler. I've only been using it for a around a year and a half. This is indeed a huge project, and while I definitely want to make it, I don't know if I can. That's why I'm just going to pour ideas into this thread and speculate on how I can implement them until I have enough to start making this game, as opposed to jumping into it blindly like with my other game.

Don't lock yourself to a view like side-view, maybe it will not workout.
Start with small blocks rather than detailed graphics

Again, something I'm doing wrong with my other game- I'm spending too much time trying to make it look good instead of adding new mechanics and actual gameplay. Right now you can chop trees, mine rocks, and then craft some items and place them, and that's it. I think for this game I'll just start with basic sprites, even if they don't look good, and then make them better later after the game has some functionality. Well, at least I hope I'll be able to stop myself from trying too hard to make it look good, haha. But I do feel confident in keeping it side-view. No pesky perspective/depth ordering to worry about.

* Computer has an AI
This one is indeed very hard.
This comes down to the question: is this part of the core-mechanic of your game?
If it is, then you need to focus all your attention to it and nail it before you do anything else.

Speaking of AI, questions like "Stencyl can support * AI" are the wrong kind to ask. AI is a broad concept, so the answer is almost always going to be 'yes'. A better question would be "does Stencyl provide the tools I need to implement the theory out of the box?", and the answer largely depends on what kind of AI you're looking at implementing. I found the answer to be "no" for graph-based AI, which is why I wrote the AI Tools extension. I'm playing around with an event-driven system in my side project, and so far I've found Stencyl provides a great environment for it (custom events).

For LUNA ("...some sort of AI that can detect which question is closest to what the player has inputted..."), I can imagine a tree-based solution. Organize keywords in a tree and search the tree based on the player input.

The best place to start would be to make sure your math background is up to date. If you've never studied graph theory or statistics, find a good primer on both. If you have, then I'd also read about decision trees and Utility AI. Utility AI may be another workable approach for your ideas. Hectate has made some good posts on procedural generation in the forums--those are good reading, too.

The AI would definitely be a huge challenge, and it isn't actually important as a game mechanic- just something that would be a cool feature. So, this should probably be put on the backburner until I have a playable game.

As for the tree-based solution, I had thought a bit about that, like deleting words that don't add to the question, then determining what type of question it is by searching for key phrases (or variations of them) like "how do you..." or "what does...do?" and then select the closest answer that refers to the other part of the question. But then, I would have to write answers to as many questions I could think of, and suddenly this becomes an even more ambitious project than before. So for now, it will be much wiser to wait.

* Wire controls to actions
This one seems to be also very complicated, but I must say it 'sounds' better as a core-game-mechanic.
But you. ofcourse, need to find that yourself.
I'm not sure how much fun it is to put all the efforts in making your own ship and then to go
find other ships to take over. What happens with 'your' ship?!
People kind of feel attached to their own creations so be carefull if that is part of your core-game-mechanic

Definitely a core mechanic. I feel like the wiring/programming should be a fundamental aspect of the game. Think programming a spaceship with Redstone-like logic, but without the size restrictions/timing restrictions.

As for what the point of the game is... You're right. I haven't actually thought of what the game should be about, aside from upgrading/automating your ship. I'll have to think on that more. And as for losing your ship... that does seem pretty harsh. I'll also have to think of some way to deal with that. Maybe players can save ship designs, and then when they respawn with a basic ship, they'll have to find enough resources and then it'll automatically be built? Not sure.

* Be carefull about statements like 'of course the game wouldn't be fun if it was just ...  '
Each little part of a game-idea can be fun. You have to find if that is the unique thing or very well implemented idea.
Some people like building things (look at minecraft) and enjoy the building more than the playing inside part.
'Need to be enemies' also a very bold statement. Maybe you don't need them if the game is about building.
[...]
Be very,very careful to say : it is only fun when all of the ideas are in the game.
Some people like building things, others like to fight. While others like to find stuff.
If you want to find stuff and you need to fight off enemies every minute : you will quit
If you want to fight and you spend every half our to build things that takes you half an hour : you quit

* Multiplayer
A very, very advanced area. It is doable, but you have to know a lot of network knowledge to understand how to
work with lag. Because every online multiplayer game will have lag.
Again, if you believe that this is part of your game-core-mechanic and the game would only be fun if it was:
then spend the time implementing this.

You're right, I shouldn't be the one to judge whether something is fun or not. It's up to whoever plays the game to make what they will of whatever I add. And I'll have to balance the game to make it so that both builders and fighters are satisfied. I just have to make something that has potential to be fun/challenging.

I've never dabbled in multiplayer at all, so that, too, would be something to figure out after I have a playable game. Personally, I feel like it could be fun especially because you don't have to necessarily kill others, you can also team up with them. Maybe combine your ships into some sort of megabase with twice the controls. That's an interesting thought. But again, I have no idea how multiplayer games work, especially in Stencyl. I would like to learn, though.

* Shield mechanic
This, again, comes down to : is it part of the core-game-mechanic.
It could be, and it could be fun. Like how the Enterprise can 'defer power from the ... to the ... '

I think shields could be a good mechanic. Not like, a core mechanic, but still something that can be fun and help you protect your more vulnerable parts, like solar panels and guns and docking stations, while using metal armor plates elsewhere.

All boils down to : is it part of the game mechanic and is it fun?

I think this is something pretty important that I completely tend to ignore with my other game; I just add whatever comes to mind/seems feasible. I'll definitely keep this in mind for this game, so I don't end up with a game packed with random features that don't add to gameplay, haha.

Most of your ideas would take months to implement.

Yeah. I don't know where this game idea came from, but it sure isn't an easy one to make, haha. Maybe that's why I'm writing out a bunch of ideas first. I want to be organized this time. My other game is like, super messy on the inside, and I have a bad habit of not commenting. But if I do make this game, it will indeed be very time consuming. I hope I'll be able to stay motivated.

mdotedot makes some really good points. Ludum Dare is coming up. That would give you a good excuse to take just one of these ideas and build a game around it. See how it works out.

I don't know anything about Ludum Dare, I'll have to look into that. But it does seem like a good excuse to test out some stuff!

I made a space station building game for one of the LDs (Aether Mine): http://www.stencyl.com/game/play/36669 The source code is still downloadable. I think it requires AI tools extension, though.

The building mechanics seem similar to what I want in my game, except placeable on any part of the ship as opposed to branching from the centre. But the outlining and only being able to place certain things on other things (like crossbraces on braces, etc.). I can't go for a tile approach, I'll have to make each item an actor and somehow make them act as one actor when connected, including with physics.

Thank you both for the responses! I always appreciate feedback; it's good to have a few other opinions out there. I'll leave the AI stuff and multiplayer stuff until later, and for now, just focus on core game mechanics.

Something that will be important, I think, is to sort out how physics will affect the ship. Of course, there is zero gravity in space, (well, microgravity, but I'll just do 0 for simplicity), but how will the ship move?

I love the idea of small ships being able to rotate around based on their thrusters. That makes it so you don't have to have a drill on every side of your ship for mining, or a gun on every side for fighter ships. But as ships get bigger, I feel like rotation would just be annoying/hard to deal with. So, perhaps large ships/motherships can't rotate, but any child ships can.


Here's some sort of outline idea sketch that I threw together in 10 minutes. Say this is the starter ship or whatever- the player can use the small thrusters (s.t.) to turn, and the large thruster (l.t.) to move forward. To do this accurately, though, I'd need to be able to :
1. Determine the centre of mass
2. Connect all of the objects so that they behave as one physical object
3. Apply a force at a specific point on this object, such as at the thrusters, so that it rotates accurately.

I might have to look into the physics joints extension, but that might be laggy (connnecting every block) or find some other way to connect them. As for applying a force at a point, I might have to figure out some specific mathematical ways of doing so since as far as I know, Stencyl doesn't have a block (or combination of blocks) to do that. I'd have to set rotation speed based on the distance of the thruster from the centre of mass, and I'm not exactly sure about that one yet. I've never actually used Stencyl's physics engine.

Some things about this picture: the drill (D.) would automaically output any items it mines into the rather limited Drill Storage (D.S.), which would output items into the Hopper (H.) then to the Storage Unit (S.U.). The Computer Core (c.c.) could have a built-in fabricator, and the battery (B.) is, well, a battery. The solar panels (s.p.) would, of course, be broken when the player started the game. the Armor Plates (A.P.) would actually be 8x8, , they're just two blocks thick here. I know this design is kind of blocky/clunky, but it may look better with actual textures.

Also, here's just some sort of idea of what the world would look like, minus the player ship and minus ores. I made the tiles myself:

So I've figured out how to find the centre of mass of any object that is just a list of tiles, using Python. All I would have to do is translate this into Stencyl. It may not look like much, but the basic idea is still there.

Changes I would make if I made this in Stencyl:
First of all, I need more than a tile's weight. I need its name, its size, and actor instance, and maybe more, like an inventory. This would probably be in the form of nested maps. Or, I might find something better, like having the actor itself hold values, while the map just holds the coords and actor of each actor.
Now, not all of the objects in my game are going to be simple 1x1 tiles. Thy're probably gonna be a variety of shapes and sizes. So instead of taking the weight of the entire tile each time I loop through one of the tiles it occupies, I can just divide the weight by the volume (LxW) and add that.

Now, I need to find out how to apply a force on the ship based on where a thruster fires from, relative to the centre of mass. Also, I need all of the tiles to be joined together as one physical object. I don't know how to do either of these yet.

Hi Fayabella,
just curious...did you make progress?
Cheers!

Hi Fayabella,
just curious...did you make progress?
Cheers!

No, not really, unfortunately. I started a small test project, but decided not to continue with it. Stencyl just doesn't feel right for this kind of thing. I still would love to make this game, I just need a different medium with which I can do so. I know Python, but I can only make discord bots and text-console interfaces, and have no knowledge on the process of making games with graphics.

Speaking of graphics, I'm not the best at spritework, and I would probably be more inclined to try making this game if I had a friend who could help with the sprites. I will keep the game idea in mind, but I don't think I would make it with Stencyl. Stencyl is probably capable of doing what I need for the most part, but I just don't feel like it fits for me.

If I ever do try to make this and actually make some progress, I'll post here to let you know that the game exists in some form- but if it's not done in Stencyl, then I should probably post a journal elsewhere somehow.

Okay Thanks