Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted by: alex_brunius
« on: January 27, 2016, 07:33:37 AM »

realtime is probably not going to be possible. each tick involves a substantial amount of work, and 60 of them per second(or even just 30) is not likely going to be workable. It is our hope to make it as speedy as possible however, so we'll see.
Realtime doesn't have to mean you have 60 chunks per second or that ingame time progression have to match real time progression. Only that the game interface and gameplay is adapted to work fine with time ticking in the background (RTS games).

One notable example is Paradox Grand Strategy games which are often referred to as pausable real-time or RTS games, and have minimum chunks between 1 hour and 1 day (ingame time advancement) a piece, but they can be played without pausing as a real time game.
Posted by: Nathan_
« on: January 26, 2016, 05:58:16 PM »

If you get Aurora running on multiplethreads i will be a very very happy person :D

Question: With regards to modability will i be able to say change the way the time ticker works for instance could i make Pulsar more realtime than time passing in set chunks?

realtime is probably not going to be possible. each tick involves a substantial amount of work, and 60 of them per second(or even just 30) is not likely going to be workable. It is our hope to make it as speedy as possible however, so we'll see.
Posted by: Hydrofoil
« on: January 26, 2016, 07:19:21 AM »

If you get Aurora running on multiplethreads i will be a very very happy person :D

Question: With regards to modability will i be able to say change the way the time ticker works for instance could i make Pulsar more realtime than time passing in set chunks?
Posted by: boggo2300
« on: December 06, 2015, 03:27:33 PM »

and windows 10 it ran straight out of the box for me (apart from the stupid laptop resolution issue)
Posted by: Nathan_
« on: December 05, 2015, 06:41:00 PM »

The hoops you have to jump through to get it running on a modern operating system implies otherwise.

I didn't have much trouble getting it to run on windows 7 thanks to the work of the people in the install forums who figured out all its various issues.
Posted by: se5a
« on: December 05, 2015, 03:27:31 PM »

...Aurora is very much a modern game,  this is about moving it to C# from VB.

The hoops you have to jump through to get it running on a modern operating system implies otherwise.
Posted by: Nathan_
« on: December 04, 2015, 03:11:20 PM »

Originally Pulsar was going to be more like what Newtonian Aurora would have been, but the overall design for that wasn't laid out. As a baseline I want to reproduce Aurora as faithfully as possible. Beyond that Pulsar will be modable to a certain degree. Options are already in, for some mechanics that differ from Aurora.

"Instead of having important data hard coded into the game" - that's what Json support is for, and this is the ultimate plan.

"this sounds like you're mostly aiming to be a modern remake of Aurora" - Aurora is very much a modern game,  this is about moving it to C# from VB.
Posted by: Thundercraft
« on: December 04, 2015, 02:26:00 PM »

Question 1: How close to Aurora are you aiming for? Will some things be implemented quite differently?

In the OP of the old Pulsar 4X thread, the project is described as a "fan sequel" to Aurora. IMO, this sounds like you're mostly aiming to be a modern remake of Aurora. I'm surprised you're not calling this "Neo Aurora", "Aurora Redux" or similar. Having a different name may be a bit confusing if the game isn't all that different.

Question 2: For the things that are different from Aurora, will there be options in an Options or Campaign menu to turn them off/on or adjust them?

Myself, I don't believe there's such a thing as having too many configuration options. Leaving the most popular choices as default and allowing the rest of us to customize is what I'd prefer. And it helps avoid controversy over whether this feature or that should be added or left out.

Further: If you have any plans at all to allow others to create mods for Pulsar or easily change it to suit their play style and preferences, I recommend that you design for this sooner rather than later.

I'm reminded of the development of Gnomoria. The developer had to rewrite a large portion of the game to accomidate modding and this took a lot of time. It used to get frequent, regular updates. Some were complaining about the sudden lack of updates and new features, though many were understanding and appreciative of the ability to create and use mods.

Instead of having important data (like the values of weapons and armor as well as pointers to graphics files) hard coded into the game, most of it now resides in easily edited text files in a database-style format. Also, it now has a means to install and uninstall mods without having to mess with the actual game files.

In a way, I'm also reminded of the development of Planet Explorers. About a year ago they decided to migrate the engine to Unity 5. This created tons of bugs and unforeseen consequences, forcing them to put story development and features on hold. Their time and resources were spent on the transition and fixing things. Over a year later and only now are they about caught up with their original plans.

Just saying that, for major changes like that, sooner is better than later.
Posted by: se5a
« on: December 03, 2015, 05:43:13 PM »

The simplest thing to do on the UI is just to copy Aurora wherever possible,...
Ueah but if somone has a bright idea that will make things more efficient or easier,  its woth looking at.
Posted by: kniteli_
« on: December 03, 2015, 01:20:05 PM »

Oddly, I haven't even played very much Aurora.  I was never able to get it to run correctly (it would crash within the first year).  I mostly watched a bunch of youtube videos on it.  I want to play it enough that I'm willing to build it :)
Posted by: Nathan_
« on: December 02, 2015, 01:26:17 PM »

The simplest thing to do on the UI is just to copy Aurora wherever possible, adding additional functionality can be worked out later, and in some cases, such as how individual sensor control was done for 0.2 the existing UI can accommodate it. In other news I've kicked up a bunch of bugs in testing the survey stuff, including a horrible memory leak that I probably introduced with the existing system display.
Posted by: se5a
« on: December 01, 2015, 01:20:06 AM »

We've made some really good strides with cross platform capability in the ECS branch using https://github.com/picoe/Eto
Big kudos to Knitieli for the work he's done with that, including a good start on an openGL system view screen, nothing much to show yet, just a blank pane with some squares in it, however that was one of the major hurdles.
I've made a little progress in a network server/client setup, managed to get a client updating planet orbit locations when the server executed a new pulse which was good, there's still tones more to figure out with that, but I may shelve it for a bit and start trying to learn the ins and outs of creating Eto views, and get that up to where i'd got the WPF.
Fortunately the big thing with WPF is the Model View ViewModel architecture, which also fits well in Eto and means I only have to rewrite half of the UI stuff I'd already done.

If anyone has any radical ideas for UI layouts for different things, sketch something up and post it.