Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

alshady

12
Posts
2
Topics
31
Followers
28
Following
A member registered Feb 17, 2018 · View creator page →

Creator of

Recent community posts

hi! I also responded in the other thread but currently there is only one fairly small zone to explore and everyone on the server should be able to see who else is online via the "diplomacy" button and chat with them via the "chat" button. If two players are on the same race/faction they should not be able to turn hurt each other.  There isn't a much to do yet other than blow each other up and fight for control of the capture stations, but I've got all kind of fun stuff in the works. 

I do have a question about how you(and others) think matchmaking should work as the game grows to include more zones. I'm implementing a larger over-world map which has zones or sectors in it. Each sector is actually a different server (though the servers can run on the same machine). The idea is that location updates will only go to people in the same zone/server which will help increase scalability and also allow for a decentralized server architecture where you could run your own server and your friends could physically travel to it, perhaps via some "transponder" code you could give them or by opening a wormhole to your location once. 

Another idea is that certain types of communication(like direct chat) could only be conducted face-to-face or in the same zone, with longer distance communication being more like email.  Am open to suggestions. 

I'm sorry for the hassle on this, the cloud server is back up.  looks like it went down again on August 2nd and I didn't notice. 

@TheBrigadier on the cloud server everyone should be together by default. If you host your own server you'd most likely need to set port forwarding from your router, the default port is 8910. 

The update I've been working on the last 2 months several things that will hopefully make this better in the future. 

* in-game server monitoring / admin GUI 

* support for server and client within one instance of the game ( no more multiple windows)

* better memory and cpu optimization ( a common cause of server crashes when using the low end VM I have)  

Thanks for reading and noticing this. I fixed it! 

Hey Brian, I just wanted to let you know I pushed out a version with the fix yesterday and  have updated the server. 

Sorry to leave you hanging here. I didn't miss it, I've just been working on implementing a lot of what we've discussed and it took longer than expected :). Yes I agree about controls  and have been working on this from many fronts. 

1) I'm working on letting people remap the existing controls to different keys and gamepads, still in progress. 

2) I've been working on Astar pathfinding both for the AI and also so you can control big ships with an RTS style right click on where you want to go method. Here is a youtube video of where i'm at with this, it works but is not yet usable in-game. 

3) I've been working on weapons which can be controlled in ways other than point your ship and shoot. 

For example, turrets auto-fire with in certain firing arc as seen in the video below. These are in-game but do not draw energy, can't be controlled and will just fire at any enemies in range. They are OP atm and will be nerfed in next update. 

I've also been working on a targetting system where you can right click a  ship and is added to a list of ships you can fire on with more automated weapons. This is still in progress but you can right click for targeting recticle. 

Lastly, I've been working on new control schemes in general including a high-speed "hyperspace race" mode. 

Thanks for the offer of assistance , I'm still trying to solo this at this point though this may change soon and I'll definitely reach out if it does. In the meantime do you know of any example games or youtube videos showing control schemes you think might work better?

(1 edit)

Hi Brian, sorry about that! The last release was running into a engine bug that  that caused clients and server to slow down to a crawl after a few minutes. It took a long time figure out what was going on and work around the bug.  I've also filed a bug with the Godot game engine and made a demo project so that the devs can fix the issue generally.

I'm currently compiling new version of the server and clients which should have the fix plus some new features (including bombs if you press alt). I hope to have it up in the next few hours. Moving forward you can host local dedicated servers from the "Advanced" menu at the login screen and I'm also working on an offline mode. Thanks for your patience and for posting about the issue :)

An update to this, the 2.3.0 update adds parts of what was discussed above. This post will just talk about the turrets.

Turrets have been added and there are two ways you can see/use them now. They are statically placed in each factions shipyard and also in each asteroid base and are attached to each players command ship. They will fire on anyone who is not in their owners faction, within their firing arc, and within line of sight. The screenshots show the turret test scenen and also an in-game shot.  The reddish arc  is the field of view of the turret.  The red line and dot are drawn to when a target is in the field of view but blocked by an obstruction. 

Currently only beams are supported but missiles are 90% done as well. When a turret is attached to a object that has an owner, it will inherit that same owner. So once you capture a base, its turrets will stop firing on you and fire on your enemies. Currently they cannot be disabled, destroyed or constructed, but that is coming. 

Hi, I'm a solo indie developer who has been working Dark Nebulae Online (itch.io page) for ~6 months and have been maintaining a devblog here on itch. It is a multiplayer top-down real-time strategic space combat game with 4x elements. Its currently being offered for free in open alpha. It has support for dedicated servers and I also maintain a free cloud server. 

I released pretty big update today (devblog) and am hoping to start a new wave of testing to help determine the development priorities moving forward.  I've also started a community forum and plan to use this to inform continued development. 

Here are a few screenshots and a video to give you an idea of what Dark Nebulae is about.


That sounds like a great idea, Core Feature! 

I'm working on the  "Bars" more generally right now and will try to get at least a basic one into tonights update. 

Hi Kingrattus, you are the first poster! 

First I want to say thanks for writing up your thoughts and for trying out the game. I agree with pretty much everything you've said and have some additions/ideas to add  :) I'm going to sticky this, since your comments provide a good framework to discuss some other core ideas for the game. 

At a high level, I agree that a Moba style match is a good path to iron out strategy elements(and maybe just the core game mode) after using the deathmatch to iron out core combat mechanics.  The main challenge is having enough players on at a given time to properly test it. The combat mechanics still needs a lot of work, but I've been working the past few weeks to enable Moba.  The recent AI development and network code  update  was to to expand the number of bots was to enable the creeps and AI bots to test on. Another note is that Moba's depend on having "lanes" and how do you do that in space? My answer was using hazardous nebula to funnel the players(this is how the game got its name).  My initial layout was purely symmetric  with 3 lanes and I've got a partial post written about the map design process.  

So regarding your comments:

"Defense - Each Faction has a central core. In between that core and the enemy players is a defense. This defense could be in the form of turrets. ":

I agree, and I propose the "Core" be a single Mothership /Flagship for each faction/race/team.  I'm working on this as a Core Feature. The mothership would be:

  • Large and very slow. The players would not directly control/pilot the mothership(because its boring) and some may not be mobile at all. Perhaps some matches they are static and act at the base/core like in  other mobas. In other matches they will move forward slowly as your clear the way or take down enemy defenses. Like escorting a tank. You may also lead it to resources on the map after clearing out enemy npcs. 
  • Currently all the ships spawn at an immobile mothership that has no special abilities, but the UI has a prototype of how I was thinking it would work. This includes
    • A basic research tree that the mothership executes. (I'm thinking you do the research by completing objectives like "Scan 5 wormholes" or "Capture 5" Bases" I'll maker a dedicated post for this. 
    • A build queue for ships. 
    • Unique upgrades for the mothership itself, like more build slots, more ship classes. 
  • The Hivemind boss creature itself  would be the mothership for the Hive and currently he hangs out over the center planet until taking minor damage then talks some (randomized) trash and quickly flies to the lair where he hunkers down and spawns a lot more mobs. If you defeat him there he moved back to the planet and this repeats ad-infinitum.
  • Not just hard to kill. but an actual boss fight.  its how you win and you need not only overwhelming numbers but also some coordination like a WoW raid boss sort of thing. I'm currently working on Turrets for the humans like you suggested, but the hivemind might just grab attackers and eat them :) 

"Turrets - Turrets can be built, repaired, upgraded, and destroyed. There would be a player that focuses on defense. This means that whichever players choose the defense role will have a different ship. The ship should be designed to focus around upgrading the turrets, and self defense."

Regarding turrets, I agree and am working on this as a Core Feature. While lettings players build turrets anywhere may be the end-goal, I feel like at least for now, for the sake of a Moba, they should either only be build-able in predetermined locations or already be there. I think they should be repairable in both cases, but only by players. 

"Offense - Players that choose offense will have a ship designed for combat. This could include everything from stronger weapons, faster ships, and long distance attacks.

  • EMP cannon - This could be a long rang attack upgrade used to temporarily disable enemy turrets.
  • Guided Missiles - A missle that is remote controlled.
  • Drones - Unmanned assault ships"
  • Nuke - This could be a neutral weapon that must be earned.

I agree and am working on these items as a Core Feature. In addition, I'm working on other novel combat techniques such as hive minions biting down on your ship to pull you toward thier master to be eaten, goo they cover your ship in to slow you down. Being able to control how fast the projectiles are fired based on timing how long you hold the button press (and more energy), mines, and more. 

The one caveat is that I am currently trying to make the ship upgrades generally offer the (player) ships additional optionality versus simply being better.  The idea is that the advanced upgrades come at a cost of something else, but gives advanced players who don't mind losing wall bounce for more speed or damage for example.  Or that certain weapons are better against certain things so having the option is an advantage. 

"NPC's 

  •  The NPC minions should be fairly easy to kill and provide a currency used to upgrade ships and turrets
  •  The giant monster NPC may be what is guarding the Nuke. Killing the beast drops it.
  • NPC drones can be found harvesting materials from asteroids scattered throughout the map."

I agree and this is a Core Feature  which is currently partially implemented.  The Terran, Construct and Zarkavan NPC's currently drop a green "Isotope" item which players can collect and currently persists along with your player on each login. The build GUI menu shows the other planned resources with the idea being that each race drops a unique one and that they can be used as currency to unlock things or maybe as a requirement to assembly certain ship types. Some resources would be also only be gather-able by holding capturing and holding neutral NPC stations/regions. 

"Ships

  • Offense - Ships must be upgraded and purchased. For example, every player will begin with a frigate, then once enough credits are earned, they may upgrade the path of their choice.
  • Defense(Frigate) - These are ships that decide on staying as a frigate, and instead upgrading their tech for turret building."

I agree with the sentiments here but propose a slightly different way to realize the goal. My current thinking that is each player in the moba is a fleet commander and are responsible for only the ships they build. The larger battle may involve multiple fleets on multiple fronts, or several fleets cooperating on one front where one is largely geared toward defense or a particular play style. This may not really work though, so I'm working on this as a Exploratory Feature.

My current thoughts for ship classes are similar, but geared around letting the player always be the hero who changes the tide of battle.

  • Mothership: Core base, race-specific boss fight,  extremely slow or immobile. 
  • Dreadnought: Large, slow and powerful capital ships the player may give orders like in an RTS or simply slowly follow the player. They would be the only ships capable of taking down powerful shield/station barricades/ capturing bases/planets, and would be required to have all available present to take down a mothership. They would have automated weaponry with firing arcs that skilled players could stay out of. Though strong, unless defended, smaller ships could take them out and they are expensive to replace. Each player would want to escort theirs in critical battles to ensure survivability but maybe could also divert some to smaller un-assisted objectives. 
  • Destroyers: I see these as a special class of ship that can only be directly piloted by players (maybe they require some neural link). The idea being that they are the "sweet spot" that can wreck the weaker frigates en masse and also are the Achilles heel of the larger dreadnoughts. They are fast, reasonably tough and are the flagships that the players fly as fleet commanders.  These may be good candidates for more extensive ,persistent, customization both cosmetic and in gameplay.Things like extra defense/AOE shields, stealth for reconnaissance, etc. I can also imagine that different races have very different version of this where one race may be geared around stealth. 
  • Frigates: These would be generally weak, but the toughness / quantity per race/faction many vary. (hives have a lot of really ones vs humans fewer but stronger units). The mothership would likely be continually manufacturing these ships to press the battle These would only be piloted by AI and you would either assign them to follow the player, or a dreadnought.  Maybe later on the behavior could be customized as a research option. Their loadouts would be basic but still part of the research tree. 

That may be more of a reply than you bargained for :D  What do you think?  

(1 edit)

Hello and welcome to Dark Nebula Online!

I wanted to write this short post describing some of the goals of the game,  what I'm hoping we can develop this forum/community into, and to try to define reasonable expectations.  First just a note that I(Al Shady) am solo developer who also has a full time job and 18 month old baby. Luckily, my passion for the project takes up the rest of my time so i had to give up sleeping to balance things out : ) I've not made any announcements about the project other than in some discord chat rooms for other developers because I want to get a stable and reasonably playable version done before opening the floodgates.

I have been putting out mostly weekly updates for the last few months and streamlining my client/server release process that it can be done with very little effort. Sometime far in the future I may want to release the final version as a paid game, but for the foreseeable future it will be free(as in beer).  My only asks from you are:

  • Engage with each other and me to help make the game better.
  • To try to be respectful of other players before you blow them to bits :)
  • To understand that I’m only one person, am doing this for fun, and am doing the best I can.

Although I have an overall vision for things that I do and don't really want to see in the game, there are also significant gaps/questions where I don't have plans or am open to experiment with different ideas to see with resonates with the players. I will open up my feature/bug tracker into a shared thing so I can integrate suggestions here and from in-game chat into my current workflow. I'd also like to post some polls to get feedback on features I'm currently planning. I'm mentally breaking down the improvements/roadmap into 3 categories.

  • Core Features: These are thing that will definitely happen and be in the game permanently. (unless they turn out not to be fun)
  • Exploratory Features: There are things that may or may not stay in the final version but  I will implement so we(the community) can decide if its fun.
  • Bug Fixes/Server Maintenance: If its broke, i'll fix it!  I've also got a lot of experience with server design/deployment/maintenance and am running them in low-touch cloud based VMs.

Bug fixes and server maintenance are the top priority, followed by core features and finally the exploratory features. That said, as a indie who is doing this largely for fun, expect some fluidity in this. Once there is a player-base, I will try to run polls to determine the implementation priority. Below are are some core pillars of things I'd like to accomplish, but this question might frame it.

What would Master of Orion (or Stellaris) look like if Blizzard designed it and if fleet flagships were piloted by skilled players?

Some things I feel pretty strongly about:

  • Combine elements of strategy games with a challenging real-time combat model and atmospheric space game-world..
  • A combat system that is approachable and intuitive, but has a high skill-cap. IE: Easy to learn, difficult to master. My mental prototype for this is the old subspace continuum game which also started with basic asteroids-like mechanics but made a deep combat system.
  • Higher-level team-based strategic goals so that the outcome of combat means something. At most a small starmap / web of wormholes and at a minimum, MOBA style matches.
  • Seamlessly blend things like maps/scans and other UI stuff so that you never leave the main gameplay screen.
  • Seamlessly blend "matchmaking" into the game. IE: flying from your personal home zone into a wormhole to join a battle.

Some things I do NOT currently want to do:

  • No pay-to-win, no microtransactions.
  • No fully open-world generic space trading/combat game. A lot of great games already exist and do it better than I ever could.
  • No things that aren't fun. I've spent more hours than I can count mining asteroids and hauling goods and I'm not interested in space spreadsheets anymore :) You might start by shooting some asteroids, but things that are tedious chores should either not exist, or be done at AI/bots.
  • No realism for the sake of realism. Realism can be a guide but should not be the sole reason for doing something.
  • No big, open, empty, expanses of space. I want space to feel packed and busy.
  • No complex ship upgrade systems with lots of Mark1, Mark2, Mark3 versions of things. I do think ships should be upgradable and there should be lots of weapon choices, but this may look more reconfiguring the core strengths of a handful of ship classes versus making ships that are just better.
  • Don’t give the player too much to do at once. I don’t really think its possible to micro manage a fleet and a series of bases/planets  while engaging in fast-paced combat.

Some things I THINK I want to do but would like to discuss/get opinions on: ( I’ll do dedicated posts to each topic to organize the thoughts. )

  • Persistent world vs Instanced matches. This is tough.
  • Novel networking mechanics. This project was an excuse for me to learn to write efficient networking code, but how this is used can vary a lot. I believe I can currently support hundreds (or more) networked objects a single real-time match
    • I could support many(30+ players) each leading small AI fleets (50 or less) into battle.
    • Alternatively, there could be smaller engagements that use the network bandwidth to have a very dynamic environment (like large physics based asteroid fields/bases)
    • PvP and PvE within the same matches/modes. This may include not only bots supporting the players but also entire AI factions.
  • Large motherships which are very difficult to destroy and move slowly. These would be AI piloted though you may control where they go or just clear the path for where you want them to go. They would store resources collected, and construct the ships for your fleet  
  • Your character is a person(or alien) and not a ship or abstraction. Even though you may construct/direct/fly in a fleet you are always an individual. Death may occur but perhaps you could pay to recover the dead, or your player character can eject and fly back to mothership for a new ship.
  • Player generated content / modding. If the game is multiplayer/competitive I may not be able to make all elements fungible but should still be able to do some things. This could range from map creators to an interface to create/submit scenarios, storylines, races, etc.
  • Lots more, but this post is already too long.

Hi, thanks for filing this and being willing to give it a second shot :) . I thought I had fixed the crash on login bug last week but it was still happening on windows and I was mostly testing on linux. (I don't have a Mac so hopefully it works on OSX :) It was kind of tricky to figure out but I think it was a combination of godot spamming debug messages and trying to reference some audio files that were not there. I rewrote the audio system with more careful checks and may check this is as a godot demo project. 

I fixed this and many other things in a bugfix marathon last night and just updated the version that went along with my last dev blog since there have not been many downloads. The server does check the client version on login so an old version will fail to log in and should say why.