Recent Forum Posts
From categories:
page »

(Awfully late response, I know - sorry!)

Thanks, Brett! I'm a little unsure how the gameplay is going to turn out because of the irregular orbits that complicate everything, but I'm hoping I can use them to create some interesting scenarios. :)

Sprint 3 Results

Game Progress

Although this week did go well, I don't have a whole lot to actually show for it. Most of the work was under the hood stuff.

First of all, I completely overhauled the control scheme to use Swift's GestureRecognizers rather than my own, extremely simple code to recognize gestures. When I first ran the game on an iPad, I realized that every time I put down two fingers to pinch the screen I was inadvertently cancelling the camera's focus because it's impossible to touch it in two different places at exactly the same time, and my simple code for "if there's two fingers on the screen then do this" wasn't taking into account the myriad of complexities that goes into real gestures. To that end, the built in GestureRecognizers are pretty amazing.

let pinchGesture = UIPinchGestureRecognizer(target: self, action: #selector(self.Pinch))

With those two lines of code, everything involved in accurately recognizing a pinch is taken care of and any specified method, in this case Pinch, is called whenever one happens. The downside is that the information the GestureRecognizers provide isn't very useful (mostly just that the gesture is actually happening), so I wound up tracking the touches on the screen separately and then using that information when a gesture is recognized.

I also made a fairly versatile Window class and implemented the planet quick-look window, which fades in and expands when a planet is selected. There's not a whole lot there right now, but I've finally gotten it working nicely and its well encapsulated, so I'm happy. Some of the difficulty here lies in the two different ways graphics are handled. There's the actual game scene, for which you add nodes representing different parts of the game as a child object, and then there's the actual view of the scene (not sure what the official name for this one is … ). All of the UI is drawn with the view by adding sublayers to it, and it took a little bit of time to properly tag each of the little components making up the window and remove them all at the correct time. Interesting stuff, though.


Otherwise, I improved some odds and ends by placing code that was cluttering the primary class into the various others where they actually belong. I also had the line width of the orbital paths increase as the camera zoomed out to keep them visible, which has been nice.

Goal Progress

I accomplished my goal of programming at least 30 minutes every day this week, totaling eight hours and fifty-one minutes.

I also achieved my other goal of deploying my game on an actual iPad. It was actually quite easy - all I had to do was plug the iPad into my computer to select it as the deployment target, and then tell the computer to sign the app with my Apple ID and the iPad to trust it. After that, it works great! I had planned to record a quick video, but a last minute problem cropped up that I have yet to fix - sorry!

Achievements Unlocked!

"Research": You spend a few hours playing a game when you should have been making one.
- I blame a particularly ridiculous sale price on Steam. :D
Lonely: Program on a Friday or Saturday evening.
25 Hours: You spend at least 25 hours working on your game during the competition.

Plans for Sprint 4

I know that the competition is technically over, but I'm planning to continue work. First up on the agenda is implementing ships - I'd really like to be able to select all the ships docked at a planet and plot a course by the end of the week, but we'll see.

I look forward to hearing how all of your projects have gone!

My harddrive crashed.

It's OK though. Other than time, I lost nothing important.
I use a raspberry pi as a git server, so everything was backed up anyway.
Also, upgraded to a SSD.

Now if only I could afford Intel's latest-and-greatest I9 processor.

Sprint 3: Redesigned Inventory Screen

Despite this week being pretty busy, I did make some progress on Tunnel Lords.

You can now navigate the entire game with either just the left mouse button or one finger touch. We have first draft icons for sell and dump resource buttons on a partially redesigned inventory screen. It still needs another run through to polish, but the buttons are all hooked in properly and dump resources.


Inventory Screen Draft for Selling Resources

Touch Screen Testing

I did some testing of touch screen on my wife's computer of the game. There are 2 major bugs remaining:

  • To register a touch as being held, the user must either double tap or hold the screen and then move their finger a little bit.
  • When the user resizes the screen, touch input no longer properly lines up with user interface elements.

Up Next

I have some ideas to refactor and improve readability of my input manager class. I need to fix the user input bugs as well. Then on to saving games in UWP compliance.

I got it!
The client-server connection of the levels has nearly no delay now. I changed the Internet Protocol from TCP to UDP for this part of the game. And everything is now a lot more efficient because of multicasting.

I completed my goals of the Levels, the first one of my menu goals and some parts of the editor goals.
=> The game is now online "playable" (in test mode(!)).

My next goals for the last few days are:

  • Creating a functioning (not beautiful!) level editor, I think I integrate it in the main Program
  • Testing the multiplayer function
  • Creating a server controller program to change the server setting during runtime (like adding or removing player accounts)
  • Add more menu items (like friend organization (see my last update) or the shop)
Re: Leto by TristanStTristanSt, 19 Jun 2017 18:40


This looks great! I have really enjoyed some Space Strategy/simulation games in the past so I'm excited to see where your project goes.


Wow. 10 days since my last post.

I've been making progress here and there. Life is still crazy, as it always is.

I did sneak in enough time to get some work done on world space. It's a little new for me, I always thought I'd be enumerating modes and whatnot, but it's been good so far.

Don't really have a video at this point, but I'm hoping to get it out before the end of (my) week three. My weekend schedule is a little off from normal, so I run alternate days to most people.

Hope everyone is doing well on your projects! See you in Discord!

"May the mercy of His Divine Shadow fall upon you." - Stanley H. Tweedle, Security Guard class IV, The League of 20,000 planets

Sprint 2 Results

Game Progress

This week went really, really well! As planned, I started out by making the basic physics simulation to generate the points for each planet’s orbit, and after a bit of work and tinkering it turned out rather nicely. I do need to fiddle with each planet’s initial values for the orbit to close (rather than either colliding with or escaping the star’s gravitational pull), but it’s actually pretty forgiving and I’m really happy with the wide range of elliptical orbits it makes.

Once I got that done, I wanted to add a dashed representation of each planet’s orbit because it’s a pretty common thing to see. I eventually gave up on the dashed line because none of the relatively straightforward methods were working (besides which, it probably would have been too performance heavy), but I did end up using a solid line that works just as well. Being able to see the orbit’s path actually really helps with the scene’s readability, too, so I’m very happy with how this turned out as well.

(Sorry for the slight blurriness)

However, given that the short orbits are 500-800 individual points and the longest orbits are in the 5000-6000 point range, rendering multiple orbital paths started to really take a hit on the performance. To fix this, I made a new list of points to render the orbital path from that only uses one out of every ten points from the actual orbit. Honestly, I feel like I should have done that from the start …

The next thing I did was to work on the labels. As you can see in the picture above, each star and planet has its name hovering above it, but the labels were kind of just annoying with a static size (if it’s big enough to be readable while zoomed out, it’s way too big when zoomed in, but if it’s small enough to not be annoying, it’s practically useless). So, I gave each label bounds for the camera’s scale within which they were to remain the same proportional size, as well as fading out when the camera is zoomed out even further. Not too exciting, I know, but it feels pretty natural and maintains the balance of functionality and aesthetics, so I'm satisfied.

At this point, I started working on a variable game speed. Space games always have a way to speed up the passage of time, and I needed this to reflect in the orbiting planets. Actually telling each planet to orbit faster was incredibly easy (just increase the index specifying the current point of the orbit by more than one every frame), so I went ahead and started working on the in-game UI for it earlier than planned. This was also pretty easy to do in Swift by using the UIButton class and assigning its dimensions, an image, and a method to be activated when the button is pressed.

Adding the variable speed revealed a new problem, though. When I first added the physics simulation to make the orbits, moving each planet to the next point every frame went way too fast. Rather than trying to mess with the values in the simulation again and then getting even more points in each orbit (four times as many!), I added a counter to the program so that the orbit’s index was only incremented once every four frames. This wasn’t a problem until I had a faster speed that actually was moving one point every frame and really highlighted that the slowest speed moved in fits and starts. As a solution, I added a system to slowly (but continually!) move each planet between two points at the slowest speed. Doing so was actually pretty straightforward - I just found a vector that cuts the distance between any two points into smaller chunks and then added that to the planet’s location every frame until it reaches the next point.

Otherwise, I started working on a system to select a planet and be able to see its statistics (like population, production capabilities, and all that other stuff that I’ve barely even thought about yet), access ships, etc. Currently, when you press on a planet the camera will zoom in and center on it, and then follow it on its orbit. Even though there’s no other functionality yet, it’s still kind of fun to select various planets and see the camera zoom in and track it.

The only other thing I did was to start work on a Ship class, but I haven’t gotten very far yet.

Goal Progress

I accomplished my goal of programming at least 30 minutes every day this week, totaling eleven hours and fifty-seven minutes.

Achievements Unlocked!

Leveled Up: You learned something that you didn't know that you can reuse in other games or other programs.
- It’s all how to do stuff in Swift and Xcode, but as far as those two things go, I’ve learned a ton and can definitely apply it in the future.
Time Machine: Worked for over an hour on code that you rip out.
- I spent quite a bit of time trying to get a dashed orbital path but had to rip all of that code out.
Widget Factory: Add a UI of some sort to your game, with buttons, sliders, check boxes, etc.
Artistic: You create four pieces of art for your game.
- Still nothing fancy, just various geometric shapes that are partially transparent and have a slight glow.
Applying Research: Spend at least an hour programming when you should be doing something else.
- I feel pretty confident that this happened at least once this week, haha!
The Tinker: Fiddle with a complicated piece of code and get it to work only after a lot of failed tweaks.
- The physics simulation, for sure. Of course, I’ve also spent quite a lot of time this week playing around with making various star systems – it’s good fun! :D

Plans for Sprint 3

Currently, my plan for this next week is to make the interface when a planet is selected and to start working on managing ships.

Also, because this is technically the last week of the competition (where did the time go?!), I’m also planning to learn how to build the game on an actual iPad to hopefully fulfill one of my competition goals. I heard there's a way to do so without buying a developer license and am hoping it's true (and legal, of course!).

Sprint 2: Continued Button and Touch Screen Work

Week 2 went slow for development. I didn't devote as much time as I would have liked and a lot of time was spent refactoring/cleaning the code base concerning the in game HUD Screen. I also fixed all the known bugs concerning touch screen / mouse input associated with opening and closing different screens in the game.

The button class now accepts an interface called IScreenObject which represents anything that is drawn to screen. So you can populate a button with anything from a static sprite, to text, to an animation. It seems to be working well as I quickly created a button that contains both a texture and some text. Additional buttons now exist allowing opening the inventory screen and title menu to keep from forcing the user to use special mouse or touch screen commands.

It looks like the last place needing cleanup on touchscreen is the inventory screen itself. There needs to be a way to dump either one or all the minerals of a given type with a touch or mouse click. This functionality will require major modification of how the inventory screen displays. I'm not happy about the extra work, but the inventory screen doesn't look great in its current form, so it is a good excuse to improve it.

Glad to see all the progress others are making!

Week 2 has come and gone, and just like that, we're half way through this competition!

Week 2 Results

In terms of my goals, I was able to complete everything I had wanted, with the exception of missing one day of doing at least 30 minutes of work. Tuesday was a… complicated day. I'm not sure it was really possible to get something done that day at all. But the good news is, I was able to recover and get the other 6 days, despite the glitch. On one hand, a goal of 7 of 7 days might be a little extreme. There's probably occasionally going to be something like that pop up. There's a part of me that wants to set the goal at 6 of 7 instead, but I don't think I'm going to do that.

One thing I wish I did better is better daily tracking of my progress. It just gets much harder to keep track of what I've done if it has been a few days. Especially the exact number of hours I've worked and whether I got enough sleep or not.

In terms of progress on the game itself, I finished putting together the Programming rule set and it did go a long way towards helping me adjust the overall design. I have yet to do Eminent Domain, Dominion, or a CCG, but the more I think about it, the more I think I need to. (I had kind of gotten to the point where I had forgotten about doing that, and had moved on.)

I planned out an architecture for my system, and I think it's pretty solid. (Though again, I should probably test it now against a third game.)

I also started doing some prototype work for my Monster Creator game, and have build a few of the key building blocks needed for the platform.

Week 3 Plans

I think I need to plan out a third game (I'm leaning towards Eminent Domain at this point) with my game platform and make sure that it works for that game too. Eminent Domain has far fewer unique/custom cards than the other two that I've done, but I think the flow of the game is quite different from the other two, so I'll need to make sure my system can capture that.

I am also planning on continuing moving forward with this prototyping that I'm doing. It is perhaps not unreasonable to think I might have something that is somewhat playable by the end of the competition in a couple of weeks. Or perhaps not. I still have a lot of heavy lifting ahead of me…

My process goals are below. Notice I've added a 5th one for updating my goals daily (6 of 7 days). We'll see how that goes.

1. Do at least 30 minutes of work on the game every day. ███░░░░ (3/7)
2. Get a total of 20 hours of work during the week. ████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ (8/40)
3. Run every day this week. ███░░░░ (3/7)
4. Get 8 hours of sleep every night. ███░░░░░ (3/7)
4. Update the status of these goals every day (6 out of 7 days). ███░░░ (3/6)

I've done some (not much) work with tiled and a little with monogameExtended.. let me know if you need anything.. but you probably got further than me anyway.

If you put in the images, but with a modified URL to subvert the system, I can edit it so that the images appear correctly. (like image http something dot com/url.png).

I'm not a big fan of the karma system Wikidot has, and I wish I could just gift enough karma to people that they can post images, but I can't. On the bright side, I think it is something like 10 posts (or less) and you get enough karma to be able to post images and links. I understand why they do it (to prevent spam images and links) but I wish I had a bit more control over how it works.

Ok, so I wasn't about to build a game (way too busy) but I did need to get this map importer working so I signed up just to force myself to get moving on it.

I'm using Monogame and wanting to lay down a good framework for myself to build games, but importing maps from spreadsheet data and whatnot is not cool. Especially when there are a few good editors out there. So I had a hunt around for the easiest way to do it. So many ways to skin a cat.

I found the Monogame Extended libraries and they were just what I was after. Naturally the documentation is a total crapshoot. I pieced it all together though, took me about a day of swearing and trial and error. I've got both orthometric and isometric maps working.

Anyway, I've just discovered I can't post images because of some stupid karma system.
What a waste of time this was.

Sprint 1 Results

Game Progress

This week went way better than I expected. I was able to start coding right from the start and have successfully set up a camera (with basic dragging around the scene and zooming in and out) and a gently pulsating star. I've also made pretty good progress on a planet (drawn and orbiting around the star), but I wasn't happy with how it was being done and so I'm currently reworking it. You can see an early version of both of these in the image below.


There's not much visual difference from then to now (except for getting rid of the white line around the planet and adding labels with the name of each object hovering above it). I have changed how they're being drawn though. Originally I was using an SKShapeNode because it was really easy to use, but the performance hit caused me to switch to an SKSpriteNode.

I'm actually pretty happy with Swift/Xcode so far. I was confused at first, but I think I've got the basic stuff figured out pretty well. There are two options for creating a scene in Xcode - you can either create it visually with the visual editor, a lot like Unity, or you can create instances of objects in the code (like the SKShapeNode I mentioned, or a lot of others) and add them as a child of a Swift class inhereted from SKScene. (The SK prefix stands for Scene Kit, which is a game development module that can be imported. It's kind of like XNA in that it provides all the basic tools to make a game, although I think Scene Kit is bigger.)

There are some annoyances, the biggest of which is probably the lack of implicit casting, to be honest. It's not that big of a deal, but there's an unusually large number of variable types (in addition to the usual Int, Float, and Double values, there's also CGFloat, CGPoint, and a lot of others that regularly come up), so sometimes I'll have a ton of conversions for really simple stuff.

Goal Progress

I reached my goal of a minimum of 30 minutes spent on game development every day except one, with a total of eight hours and six minutes.

Achievements Unlocked!

10 Hours: You spend at least 10 hours working on your game during the competition.
Taking Aim: Set a goal for yourself for one week (or the full length of the competition).
Hang it on the Fridge: You create at least one piece of art (sound, texture, model, sprite, etc.) for your project.

Unfortunately, Xcode doesn't appear to have an option to show the number of the lines of code, so for right now I'm ignoring those achievements. Also, the artwork that I made is just a white circle, but I'm sure I'll do something to warrant the achievement more later on, haha!

Plans for Sprint 2

My plan for this week is to work on completing the code for planets to orbit stars. Originally I had it set up to draw based on the planet's angle relative to the star, and then increased the angle every frame to get a circular orbit. The problem was that, in addition to being restricted to a purely circular orbit, there wasn't very smooth movement (particularly once the radius of the orbit got bigger).

Instead, I'm trying to make a basic simulation that will run once when the scene is loaded, and then store each of the points into an array for future reference. This has several advantages to it, except for the fact that even trying to reduce physics to a very simple level can still be really hard to get straight. Fun stuff!

For future reference, I'd recommend making a new thread for a new question next time, rather than just posting in an arbitrary thread. It makes it hard for others having similar problems (or the solution) to find the question.

I'm not having any issues with what you're describing, so it's not a general failure across the board. It's possible that maybe you don't have permissions to run the program or something that the program is trying to do early on (like access a file or something).

So the first thing to try might be right-clicking and running as an admin.

Second, it might be crashing before it gets a chance to display anything. When you're running in Visual Studio and that happens, the debugger stops the program from running and shows you the error. But outside of Visual Studio, it just dies. You could catch the exception that is being thrown (if that is indeed what is happening here) and write it out to like a text log file or something before closing down. Then you'd have an error report of sorts that you can use as a starting point in your investigation.

The way MonoGame is set up, I'd do that in the Program.cs file, and just wrap everything inside of the Main method with something like:

static void Main()
        using (var game = new Game1())
    catch (Exception e)
        File.WriteAllText("ErrorLog.txt", $"Unhandled Exception: {e.GetType()}\r\nMessage: {e.Message}\r\n{e.StackTrace}");

Obviously, it's pretty easy to imagine doing a lot more creative things with an unhandled exception killing your game than this, but this is a minimal solution that will hopefully help you see what failed.

In the future, you could extend this to use a full-blown logging system with error levels and the like (or use an existing logging framework like Log4Net), display an error message to the user before closing, or automatically submitting it to your bug tracking software or something. But the text file is a good first step, and should give you some insight into your immediate problem unless something truly horrible (or perhaps OS-related) is happening.

Hello, I have just tried setting up Visual Studio 2017 with MonoGame and came across the following problem; once built, the .exe in both the "Release" and "Debug" folders doesn't run, while it is working fine inside the editor. (Nothing happens at all when launching it outside the editor)
Do you have any idea what causes this problem?

Re: MonoGame 3.6 was released by MennoMaxMennoMax, 09 Jun 2017 20:51

Well, not a whole lot to show. Did get some decent progress in this week so here's a short video…

As far as my stated goal go:

  • First week I made 4/5 on 30 minutes a day. This week I hit the 5/5, although pretty much all of both were in one day sessions. Life's still a little crazy atm, so I'm counting it anyways!
  • So far, all my project time has been spend on actual coding, so that is easy enough to track: 4.5 hours coding.
  • I did finally get a background rendering, so that one is done as well. Still going to need some work as it's only about 1/10th of what I want to do with backgrounds, but I didn't really specify anything other than add a background, so it counts as well!

I guess this week's goals will be enemies, enemy AI, bullets, and music. Those will be fairly simple to knock out before the harder stuff kicks in. So I guess during my last week I'll have to bust butt to hit my goals for the competition.

Good luck all on your projects!

"May the mercy of His Divine Shadow fall upon you." - Stanley H. Tweedle, Security Guard class IV, The League of 20,000 planets

my bad i missed this line
spriteBatch.Begin(SpriteSortMode.Immediate, BlendState.Additive

by Joe (guest), 09 Jun 2017 15:09

1st of all, Great tutorials btw.

The first problem with this one is;
CS0103 C# The name 'Math' does not exist in the current context

I realise adding 'using system;' to the directives fixes this but the second problem is that images don't appear to be blending at all

Maybe I've missed something?

by Joe (guest), 09 Jun 2017 15:05

Without looking at the actual code, it's going to be hard to figure out exactly what's going on.

That being said, I'd check to make sure the message delivery is not set to guaranteed delivery. Not even sure where to tell you to look for that at the moment, but it should be somewhere in the TCP setup.

With guaranteed delivery, network propagation times go up significantly, since it has to double check for errors, dropped packets, etc, etc, etc. It at least doubles the threads reaction time.

Hope that is of some help!

"May the mercy of His Divine Shadow fall upon you." - Stanley H. Tweedle, Security Guard class IV, The League of 20,000 planets

page »