Recent Forum Posts
From categories:
page 1123...next »

No, nothing has been decided yet. Next weekend might be OK, but I wonder if that really gives us enough time to get things set up.

I know that I'm not active in the chat rooms. I was still interested in the collab though. Has anything been decided on framework or timeline? This Saturday wouldn't work for me but I think next weekend might be available.

-Brett

Hello again, everyone!

One of the classes I'm taking this semester is a relatively low-level astronomy course, and while we were talking about the gravitational force's effect on its satellites, the professor pointed something out that I had never thought of before. I'm sure you're all pretty familiar with the equation for gravity, where 'G' is the universal constant and 'g' is the resulting force:

g = G(m1m2) / d2

You're also probably aware of the formula for the relation between force, mass, and acceleration:

f = m • a

What I had never before considered was what happens when you put the two together to find the true acceleration from a gravitational pull.

G(m1m2) / d2 = m2a
(Gm1m2) / (d2m2) = a
Gm1 / d2 = a

If the horrible formatting didn't confuse you, you'll see that the mass of the satellite gets cancelled out from the gravity equation, and therefore any two satellites, no matter the mass, will have the same orbit around a star.

When I realized that I had overlooked this and that my admittedly very innacurate astronomical simulation was even more innacurate than I'd thought it was, I decided to do some reworking. Once I had taken the mass of the planet out of the orbital calculations, ramped up the gravitational constant in my program, and adjusted the initial speed for each new orbit to match the old ones, there's basically no difference. However, some of the planets in my program now orbit faster than they used to, and some orbit slower, because it's a little bit more scientifically accurate than it was before, and I'm pretty happy with that. This also opens the door to some more fun ways to play with the orbits - I've already added two planets with very different masses and overlapping orbits that I know will absolutely never collide with each other, but that make for some really interesting navigational and economical possibilities.

Another thing that we discussed in my astronomy class has to do with the location of the star inside its satellites' elliptical orbits and how it will always be on one of the foci of the ellipse. This little fact caught hold of my curiosity, and so I wrote a lot more code than you'd think was necessary (or at least, more than I had expected) to calculate the location of the foci for each of the orbits in my game and compare them to the location of the star. Unsurprisingly, math is very consistent and even my mediocre physics simulation places the star anywhere from a lower bound of less than one pixel to an upper bound of about six pixels away from one of the foci. Considering that most of the orbits are at least a thousand pixels wide, I think this is pretty awesome!

Anyway, I know that this isn't much by way of progress, but I've had fun coming back to this project with some actual science and thought it was worth sharing. Hopefully I can keep going and come back soon with some more progress.

Don (guest) 22 Sep 2017 04:59
in discussion Hidden / Per page discussions » Basic Math in C#

I'm not the best at math, but I feel like the bottom half…They values you'd say they'd be don't look correct. Then again, I'm probably wrong.

by Don (guest), 22 Sep 2017 04:59

Hello,
I needs some sound advice. I'd appreciate if you could give me some sound advice. My end goals is to create custom 2D graphic charts that have fast chart updates. Another goal is to adopt 2d graphics engine choice that will not go obsolete in the next 5 years where I'll have to do a total code rewrite. I'm familiar with C# and have the desire to do this in Directx. I understand Directx9 has a managed C# libraries which seem very convenient. However, Directx9 is dated and requires a steep learning curve. On the other hand directx seems to have withstand the test of time. I'm considering slimdx or some higher level wrapper that can shorten my learning curve. I'd even consider XNA, monogame or other C# managed opensource platforms but not which one is the most popular, easiest to use, will be around the longest, etc. Anyway, I appreciate your feedback.

Starting 2D graphics project - where should I start? by Tom Roberts (guest), 22 Sep 2017 04:37

So Brett, did you ever get this published on the Windows Store?

I'm wanting to try to get my game out to the Windows Store in some sort of Early Access format, though I don't know if that's even something that they'd support.

Or an alternative would be another simple/easy way to distribute a UWP app outside of the store. Since you're using MonoGame, you probably have other ways to handle that (like just compiling to a .exe file).

I'd love to talk with you about what you tried and what worked and what didn't work sometime.

I added a week to my date also and Plan on ending the 24th

Re: Time Frame by SwatacularSwatacular, 12 Sep 2017 20:04

The competition ends on the 17th of September officially. That's only one more week after today. I'll be going for a week beyond that, because I didn't get started until late because of the eclipse.

Re: Time Frame by rbwhitakerrbwhitaker, 10 Sep 2017 23:57

I'd be willing to work on a Unity project, if there were only one team, or that's where the interest was.

I thought we'd have enough people for more than one team last time, but we barely even had enough for one team.

To be fair, I didn't do a great job at advertising it or anything, so that probably contributed. The competition ends here in a week and a day (I think) so after that, we'll hit the planning for this thing hard and see who's interested in joining.

If we have enough people for multiple teams, that would be awesome!

Prado (guest) 07 Sep 2017 22:27
in discussion Hidden / Per page discussions » MonoGame Texture Atlases

I had the same problem but found the answer!

The AnimatedSprite class is in your solution but not in your project. To solve this, right click the project Game1 or whatever you called it(not the solution), then select Add Existing Item and choose AnimatedSprite! Problem solved!

I hope that I helped!

^^

- From a wandering newbie programmer :)

by Prado (guest), 07 Sep 2017 22:27

Week 1 Results, Week 2 Goals

I'm a week behind the official timeline, so don't mind my week numbers if yours are different..

I'm also a day behind, but considering it was still the weekend because of Labor Day, I'm still counting it as last week.

I should probably go back to my original post and flesh out a bit of description on what this game is, but that's probably not happening tonight. The game is 1 part Asteroids, 1 part Space Engineers, 1 part Kerbal Space Program, and 1 part Firefly/Serenity.

Over the last week, I've gone from a very raw experimental statewhere all I had was the bare minimum to draw some vector graphics and enough physics to test the physics library I want to useup to where I am now, which has a lot of the absolute essentials of the game fleshed out.

The GIF below illustrates where things are at in development right now.

Decoupling.gif

In a nutshell, I've got asteroids generating, plus a ship that is composed of parts. The parts have a parent/child relationship and are hooked together at specific attachment points. You can see in the GIF that I used the little connector just behind the capsule and disconnected the capsule from the cargo bay parts and the engine at the back.

Goals For Week 2

I'm hoping to get the physics going for real in the game (not just the little experimental stuff that I did earlier). It's perhaps the single biggest and riskiest piece that I have left to work on. (Don't get me wrong; there's still tons to do.) Once the physics system is up and running, the only core game mechanic left to implement will be your ability to manipulate the environment (besides crashing into things).

We'll see how far that goes. My process goal is to hit 15 hours of dev time this week, not including today, which I'm actually counting for last week. So I'll be doing some rounds probably every day in the chat room if anybody wants to come join me.

Re: RB's Game Thread by rbwhitakerrbwhitaker, 05 Sep 2017 04:19

Okay, really quick update.

Basically, I haven't done anything. I've only spent about an hour programming over the last two weeks as I settle into my new school schedule. I definitely want to find some regular programming time before too long, but I still may not do much for another week or two.

Oh well. At least I got in that last really big update on the old thread, so I don't feel too bad about a few slower weeks. Hope your guys' projects are going well!

I'm having issues with loading more than one model at a time. I'm using MonoGame 3.6 in OpenGL on Windows with VS2017.
When I load one, it looks great. I went back to an older version of 3.6 and it works fine. Seems to be a bug.
If I load another, it takes on the aspects of the first model. I've tried loading each model on its own, and it looks great. The mesh gets messed up, as does the UVs when I use more than one at a time. It is like the data is getting corrupt.
I've tried lots of things to fix this, to no avail. Such as:

Services.GraphicsDM.GraphicsDevice.RasterizerState = RasterizerState.CullCounterClockwise;
Services.GraphicsDM.GraphicsDevice.SamplerStates[0] = SamplerState.AnisotropicWrap;
Services.GraphicsDM.GraphicsDevice.BlendState = BlendState.Opaque;
Services.GraphicsDM.GraphicsDevice.DepthStencilState = DepthStencilState.Default;

Please help.

Alright!! Lots of great news.

First off, Got a new public version available! You can see the changelog down below.
I am claiming a few several achievements for my first post this competition, really boils down to the last few weeks though.

My Happy Accident was very interesting.

While I was programming, I programmed a bug in my code causing a infinite loop, which I had trouble breaking out of.
While working on the problem, my cat managed to walk behind my computer and knock my external hard drive off the desk, which resulted in corrupting all of the work that I had done in the last week.
However I did not realize this and eventually gave up and went to bed, at which point I noticed the hard drive sitting on the ground and only the next day realized what had happened.

That being said, I spent the entire next week rewriting all of the code, except this time I refactored it and wrote it atleast ten times better. resulting in several achievements listed below.


Version 0.0.18 Changelog:

Public Version 0.0.18
[AI]
> Added AI Sight, can see anything infront of him with a 90 degree FOV.
> Added AI Looking at Player if he can see him.
> Added AI Walking towards and away from Player to stay at a smart distance.
> Added AI Strafing and Dodging at random intervals.
< Removed AI controls from player mouse.
[Player]
> Changed WASD to cardinal controls.
> Added Mouse for sight control.
> Added Spacebar for fire control.
- Changed fire rate for player.
[Map]
> New Map


List of achievements unlocked.

Achievement Name: Description:
Victory!: Beat your game for the first time!
Stay On Target: Take the time to re-evaluate your goals during the competition, and determine that they're working.
Happy Accident: You accidentally create a bug that leads to humorous results.
Less is More: Lines of code ain't everything. Sometimes, the best solution is to refactor to eliminate redundant lines of code, leaving you with less but better designed code.
Time Machine: Worked for over an hour on code that you rip out.
I'm Sorry, Dave. I'm Afraid I Can't Do That: Add an AI enemy, opponent, or component to your game.
1/10/25 Hours: You spend at least 25 hours working on your game during the competition.
Applying Research: Spend at least an hour programming when you should be doing something else.
The Thinker: x3 Spend a hour thinking through a complicated piece of code and get it right first try.
The Tinker: Fiddle with a complicated piece of code and get it to work only after a lot of failed tweaks.
Thinking Ahead: Spend time before the start of the competition planning your game.
The Great Unveiling: Provide a download for your game.
Way To Brag: Claim at least 15 achievements. (Claimed 17)

Talked a little bit about doing something in Unity with the Unity Folk around here in Oct-Dec.

Not sure if it will become a official thing, or it will be one of multiple teams. we are beginning to have quite a crowd here so my guess is that we can have multiple projects going on.

I have no idea when this competition ends. Could we clarify that?

Re: Time Frame by SwatacularSwatacular, 01 Sep 2017 14:23

Well on about last Friday night, I changed plans on when to start the competition and pushed it back a week. The eclipse kept me busy all weekend (and Monday) and then work kept me busy all week, so that's probably the right move.

But that means that this weekend that is ending was the first weekend for the competition for me, and I was fortunate enough to have gotten started.

I've begun working on a game that might be described as "If Asteroids were a sandbox game". Or perhaps, "Space Engineers, but simpler, with a dose of Firefly."

I honestly haven't gotten very far yet. I've been playing around with tools and constructing some building blocks, but I've begun to settle on the idea of using Win2D for vector drawing, UWP for a UI, and Velcro (formerly Farseer) for physics. Those two tools should get me going much faster, without piling on a lot of constraints. I very much have mixed feelings about not using MonoGame. But don't take my leanings towards these other tools as a sudden change of heart for MonoGame. It just seems like Win2D is a better tool for vector graphics, and UWP just comes along for the ride there. Farseer was designed for XNA, and I'm doing a few hacks to make it work outside of XNA/MonoGame.

Truth be told, I've always tried to design my games in a way where I don't have to have architecture determined by the game engine or rendering engine anyway, so my games have tended to not be too tightly coupled to those types of things. (Meaning I could make a MonoGame UI for this game without reworking the entire game if I wanted to.)

I'm hoping to get PiscesMike to work on this game with me, but he's been so busy with his new job and his old car so far… :P

I'm hoping to have a bit more to share by the end of next weekend.

Re: RB's Game Thread by rbwhitakerrbwhitaker, 28 Aug 2017 03:42

Plans for Sprint 1

Chances are that there's going to be some more problems related to the route system for me to solve, but barring any major distractions, my plan for this week is to work on being able to select convoys apart from when they're docked on a planet (which doesn't include convoys that are waiting on that planet until they launch again). Without this, once a convoy is assigned a route it can never be selected again, so it's an important feature but shouldn't be all that major of a task, which sounds perfect for this week.

Sprint 11 Results

Game Progress

This week was pretty unfocused, but also fairly productive.

First of all, as I already posted, I fixed the sync problem on day one of the sprint! While I didn't like the idea of basing the convoy's movement on the clock (so that it waits until a given time before launching and then travels until a given time to start waiting again) rather than actual values for how many frames to wait/travel for, I decided that there wasn't a problem with using the clock a little bit for route calculations. Like I said at the end of the last sprint, calculating the total amount of time left to finish the convoy's current course was somehow introducing a problem, and so I cut all of that out and instead assigned each waypoint the frame at which it should arrive and then found the difference between that value and the game's current frame. By doing so, I was able to get what should have been the same value, but in a much simpler way that didn't somehow introduce errors. Problem solved!

After that, I didn't feel like jumping into another big task or spending more time trying to round out all of the features supporting routes, so I just looked around for something fun to do and went with that. What I decided on was implementing names for convoys. Previously, there wasn't any way to access information about a convoy - once you made it, you didn't know how many ships were in it or anything - and I thought a good first step towards distinguishing them was to be able to name them. However, I didn't want yet another popup window that would require more input when the player creates a convoy, but I did want there to be some encouragement to input custom names rather than the automatically assigned "Convoy #X".

The cool thing is, the Swift game development libraries that play a really big part in interfacing with the app's visuals and player input provide a lot of handy object types, one of which is a UITextField that recognizes taps and automatically pops up the keyboard and displays whatever you type into it. In addition to the 'text' property, there's also a 'placeholder' property that displays the assigned string in a faded color when there's no actual text. So, my solution was to default to the generic "Convoy #X" name as the placeholder text so that the player doesn't have to assign a name but can still distinguish between convoys and, I hope, gives the impression that it can be changed. Once it receives a custom designation, the convoy's name is displayed as regular, solid text.

kCN5hpc.png

I still didn't feel like getting back into something big, though, so I spent another couple days making improvements to lots of little things. For instance, the blue arcs that show how long a convoy is going to wait for before launching towards the next planet were changed to only be displayed if the time left to wait is less than one full orbit (otherwise, when convoys need to wait a really long time, no other useful information can be displayed - there's just a solid blue orbital path). I also made one of the windows look a little bit nicer by filling in some weird empty space with a nice header, fixed a problem with the convoy visuals not fading away when it's run out of waypoints and is busy calculating more, and made the maximum acceptable bounds in a route a bit more flexible. Sometimes two planets in a route will shift to be in really inconvenient relative positions so that it takes forever for them to come around again to be close enough to meet the route's requirements ("don't travel further than X"). So, for every full orbit made without finding any suitable launch opportunties, the maximum acceptable travel time increases by a decent amount.

Unfortunately, as I was testing some of these changes, I was reminded of some weird route behaviors that hadn't gone away with the other problems. Every once in a while, very unpredictably, one waypoint would be assigned to launch before the one it comes after, so that the convoy would jump around and expect planets to be where they were a moment ago but no longer are. After a bit of diagnostic work, I found the problem with a piece of code that no longer works properly because of some of the other changes that I've made but was able to fix it pretty easily.

Here's a video of the route system in action:

Goal Progress

I spent at least 30 minutes programming every day except Monday, totaling four hours and fifty-eight minutes.

Change in Location

From now on, I'll be posting updates at this thread, for the new competition. I look forward to seeing what all of you come up with and am excited to keep working - I'll see you there!

The Game

In a sentence, this game is (going to be) an interstellar trade simulator. The player will manage ships, create trading routes, and more to earn money and grow even bigger. I have a lot of ideas for cool features, but I'm trying not to get ahead and myself (and, realistically, I kind of doubt that I'll ever get far enough to start implementing more than the relative basics, but fingers crossed!).

All of my progress so far can be found here.

Goal

Spend a minimum of two hours over at least four days every week programming.

Achievements

Carry-Over Achievements

½KLOC: Your game reaches 500 lines of code. You're off to a great start!
1KLOC: Your game reaches 1000 lines of source code. Making progress! Excellent!
2KLOC: Your game reaches 2000 lines of source code. Keep it up!
Hang it on the Fridge: You create at least one piece of art (sound, texture, model, sprite, etc.) for your project.
Artistic: You create four pieces of art for your game.
Widget Factory: Add a UI of some sort to your game, with buttons, sliders, check boxes, etc.
Heads Up: Add a Head-up Display or other UI overlay to your game.
It's Just Temporary: You put in artwork in your game that you claim is temporary, until you or your friend can provide you with better art.

I've also already spent seventy-eight hours and twenty-four minutes working on this game, but for the most part I'll start counting from zero again. I may make note of when my overall time reaches big milestones like one-hundred hours, though.

New Achievements

page 1123...next »