How are games made with only code frameworks polished and tweaked?

1

Hi there,

I recently picked up Monogame to learn C# after using Unity for around a month and realizing it didn’t really help much in improving my programming skills.

Everything has been really smooth so far especially using something like the Nez framework. However in the middle of a project I faced a couple of problems.

  1. Tweaking sensitive values: Ex. when making a platformer I keep on adjusting the values of the position and size of the box collider that detects the ground and having to recompile to see the changes made. Back when I was using Unity I could just drag to size I wanted and see it in real time speeding up development.

  2. Placement of objects in game scene: Ex. I wanted to place a change level trigger somewhere I had to estimate the position, compile and see the changes and then readjust and so on. It was really tiring.

So if you guys any tips or solution for the problems I’m currently facing do inform me and thanks.

2 Likes
2

Maybe add some GUI elements which you can use to adjust the values you want to tweak. Or implement a “simple” console. This way you could set values at runtime. You can look into reflection also and combine with the GUI or console solution.

3

I am building my own editors, if I need to (or ingame debug mechanics to do different stuff). That’s why in older games you often find game editors, because they were needed anyway during development.

4

I write my own editors too, but as alternative

  1. reading params from a text file, and reloading them when they change
  2. Edit & continue (with Visual Studio C# you can break, change code or variables, and continue running without restarting the game).

I’d be a sitting duck without Edit&Continue :slight_smile:

1 Like
5

You know, this is a really great feature that, in like 15+ years of using Visual Studio, I never use. Honestly, I have no idea why.

6

#2 edit and continue for sure.

Even now I am working on a UI framework to develop games faster that relies on “edit and continue” to make your game. Something like the idea of having unity but working with your own code in VS instead of Unity for monogame

7

Well, I must say I don’t use Edit & Continue. I abuse Edit & Continue :sweat_smile:

8

And with VS 2017 , not sure about previous versions, you can also add new public, private etc fields to your classes including methods at run time, so I really “abuse” that to develop, sometimes i spent 4 hours in one edit & continue cycle while developing before i need to re-start the game, i couldn’t do that with VS2010.

Also , when I was working on XNA, I had a pipeline with shaders so I could program, compile outside my game when I was doing edit & continue, I was used to reload the shader without having to re-start the game so I could iterate a lot of things in hlsl very fast, sadly I haven’t ported that to monogame yet

Any other tip? anyone have a way to improve or abuse it more? :stuck_out_tongue:

9

That’s exactly the kind of abuse I do too, VS2017 was godsent :slight_smile: I’d say 35-40% of my code is done under Edit&Continue and tested / stepped in as I type.

If the code is not satisfactory, just use “Set Next Statement” to go back to a safe place where the inputs were unaltered and start again.

I even set up the debugging context menu so that “Set Next Statement” appears on the top option, this way I don’t even have to search for that option. Need Set Next Statement? Right click + first option.

10

what kind of black magic is that? I didn’t know you can change the debugging context menu, that’s a next level of abuse I need to learn to do, any other tip? :slight_smile:

11

How do you guys get Edit and continue to work so well? I often find my edits result in purple squiggles and I have to restart my game to get the changes to work, either that or it will say there were errors and refuse to continue, but there are no errors and I have to restart the game.

12

it all depends on what kind of code you are fixing/developing and a lot of planning ahead for a long session.

A few things I noticed:
1- When I do UI part, I can spend 1 minute or 3 hours in one session, depends on what do I need to fix or do. Debugging and testing is very easy this way.
2- When there are callbacks I noticed that VS studio crashes a lot when I edit the code inside a callback, I am not sure if anyone experience the same, but I usually can’t edit a single line of code inside a callback it restart VS , so I have to stop and edit, not other option.
3- Also if you use reflection, you can’t access variables from main program unless you define all those things before, so usually means a restart , plan ahead for those times so you do not have to do many restarts
4- if you are in cycles of spritebatches and you messed up the order, most of the times is faster to restart than trying to fix all the begins/ends messed up by the mistake
5- when doing refactoring, this is when it shines, I spend a lot of time simplifying code and making it reusable for other parts of my game mainly in external libraries, so I can re-use them, in those cases I can spend many hours writing in edit and continue without problems, is just moving/commenting code and fixing bugs, many times you can’t predict all the outcomes until you see them happening, so edit and continue allows you to find those cases very easily , also with VS 2017 (not sure if 2015 has this) you can write functions inside functions to simplify your code! without having to declare variables inside, this is extremely useful! to make your code mode readable something like

public void A(){
    bool validateXYZ(){
         some code here
    }
   void doA(){
        some other code here
   }
  
   if ( somevalidation ) {
       doA;
   } else{
       if ( validateXYZ() ){
          doA;
      }
   }
}

you call doA 2 times in same part of code, function is inside the same function, making the refactoring very easy without having to repeat portions of code everywhere, you can do this while doing edit and continue!

this is something I do a lot lately, and spend a lot of time to make my code more readable, I had a hard time trying to understand my code when I had too much code in one function or method, so I started to follow some concepts of SOLID, you can search that.

6- when you need new fields or methods, you can add those now while in edit & Continue, with default values , so those get initialized always. Example I need a new flag for something, i just go to the code, add it as public and use it in another class if I need to , without having to restart, in VS2010 you had to restart to do that

Those are a few things that come to my mind. Please add more if you know, so I can learn how to abuse it more :slight_smile:

13

Hi @vermiliontower , I think the answer @MysticRiverGames just wrote was meant for you :slight_smile:

As he says, you “have to learn” where you can modify the code and where you can’t. His 6 suggestions are very good experience and as you work on it, you end up knowing when EC will fail. It’s quite predictable.

Some suggestions on my own (some may be just personal preferences) … For EC VS2019 > VS2017 >>>>>> VS2015
I had lots of problems with “errors that are not errors” in VS2015 and initial versions on VS2017, but those were reduced a lot in a VS2017 update. (keep updating, if you can)

Try to avoid modifying code that is very close to your current line (same line or previous line). There’s a decent chance to make EC fail. Just step on a few lines or use “Set Next Statement” a few lines before. Modify your code then (and you can use Set Next Statement" again to put in over the line you just modified.

Avoid “Enable native edit and continue” being checked in the options->debugging->general if possible. Gives lots of problems.

Sometimes you want to start a fresh run on a function… your parameters are garbled, or your mind is :). Use “Set Next Statement” with the final “}” of the function, then step in. The EC engine creates a dummy return value and allows you to return. When the debugger exists the function, just use “Set Next Statement” again on the function you wanted to restart.

If you change parameters of an existing function, it’s a restart. So if you’re creating a new function, carefully plan ahead the parameters. Same happens with captured variables (lambdas, functions inside functions, …)
So, if you’re in a pickle and you really really MUST keep EC going but you can’t add a parameter… just add a work variable to the class and use that variable for parameter passing.
OBVIOUSLY mark that variable declaration with a “FIXME ASAP” and explanation, and fix that aberration as soon as the EC session ends. Note it down somewhere so that you don’t forget about it. And obviously too, it won’t work for recursive functions.

Most of the “Can’t continue” errors can be undone by undoing the offending code. In example, if you need to add a parameter somewhere, you didn’t realize and added it, and now it fails. Just Ctrl+Z (or put the parameters as they were back, if you remember them) and you’ll be able to continue.

Because of the last tip, add little code every time. If it fails, it’ll be easier to go back to a resumable state. You’ll be able to add more code as you get the grip of it.

C# attributes are a no-no. Oh, I’d love to be able to add/modify DebuggerDisplay on the fly…

that’s all I can think of :slight_smile:

14

I suppose you mean an inline lambda.

What I do is

bla.callback+=(s,e) => { myFunc(params); };

(or the delegate-caching equivalent, to avoid garbage)

then I have a myFunc function that can be modified without major problems. It’s not as flexible and you obviously can’t change parameters, but allows E&C. However, now that I think of, I haven’t tried of using this in combination with a local function.

Beware of lambdas because they’re usually garbage generators.

15

In November last year, I switched from MonoGame to unity and let me tell you, the ease of use in unity is light years ahead of Monogame. For a total noob, you will learn more if you get to play with more things. Just because you’re using MonoGame it doesn’t mean your “learn rate” for C# will increase. :slight_smile:

16

Good idea, that!

Whaaaat!!???

You are shitting me, right? I can’t believe I didn’t know this existed after around 6 years using Visual Studio / Xamarin Studio (on a Mac though). Can you do this in VS2019 for MacOS do you know?

I spend so much time in Jetboard Joust tweaking parameters then recompile, restart etc. I know I should write a GUI to tweak things (especially things I use a lot like particle fx and certain shader fx) but by the time I realised I needed that the game had progressed so far I thought it wasn’t worth it (I was wrong).

If I ever do another game I’m going to write a GUI ‘tweaker’ first.

In the meantime - I’m looking into ‘Edit and Continue’. That sounds like some serious voodoo shit right there!

17

@BitBull It seems it’s not supported on mac.

In fact, until very recently, only 32 bits code was allowed to use E&C in Windows, and last time I tried in android (maybe 2 years ago) it didn’t work there either.

18

Ah, thanks!

So now I feel disappointed that it’s not there but glad I’m not a total douche for being ignorant of it if it was! :rofl:

19

yes , inline lambda. That is mainly used when trying to handle events on User interface, which makes it very easy to jump from one side of the code to another but very frustrating to edit and continue.

And it is pretty bad that is not supported on Mac :frowning: I will drop my Mac if I had to develop on it without it , or at least you can try a virtual machine? Monogame will run slow but you can try edit and continue magic.

20

What you are looking for is, Boot Camp : Boot Camp Assistant User Guide for Mac - Apple Support

Something the majority of my Mac repair jobs did lol, the number of times I had a phone call from a client and when I ask what laptop they have, MacBook, [I later asked what OS they were using as well] and when I get there, it’s because their MacBooks forced a boot into MacOS and I had to rework the boot options to boot back into Windows :stuck_out_tongue: