I might be asking this too early in development, but I'm thinking of making a Zelda-style with gamepad controls and am wondering what a good layout for the gamepad would be. The main issue is that it has standard "move with left stick" "rotate camera with right stick" and I have a melee attack with short cooldown (right shoulder, top button) and projectile attack with long cooldown (right shoulder, bottom button). I also want a jump button and a "lock on target" button.

Intuition says that you don't want to force the player to take their thumbs off the joysticks to do things like jump and lock-on that they would want to be able to do while moving, so that made me think of using the left shoulder buttons for jump and lock-on. But I want people to be able to jump around while staying locked on to targets, and pressing both top and bottom shoulder buttons simultaneously feels awkward to me. I alternatively tried making it so you jump by pressing in on the left joystick and/or lock-on by pressing in on the right joystick, which seems meh because 1) accidentally pressing in on the left stick when you just want to move but not jump happens too much when I try it, and 2) for the right joystick I want pressing in while moving the stick up or down to control zoom instead of lock-on.

I uploaded an HTML5 export of the game that has tentative gamepad controls (not yet shown on the in-game instructions because I'm still wondering about a good layout) where the right shoulder buttons are slash / fireball and you can do jumping or lock-on either with left shoulder buttons or by pressing in on the joysticks (zooming by pressing right joystick while moving it up or down is also incorporated in this version) so people can play it to see what I'm talking about - there's a room with test dummies to lock on to and attack after you get the other controls down, and that's the last room of the current draft. You would need to run this gamepad configuration thingy for NewGrounds to configure your gamepad once if you've never done it before and then you can try playing it here.

Does it need to be in Flash, or can it be something else that'll let you make web games?

Options range from Scratch to GDevelop to HaxeFlixel to Godot to Unity, and they have instructions on how to get started making online games.

Before getting too into it, be aware that Godot 4's web exports have compatibility issues with players using macOS or iOS even though they're playing on web from their browser, while Godot 3's web exports work fine on anything. You can still make non-web exports for mac or iOS with Godot 4 that run fine if the player installs it. But if your goal is to make web games for NewGrounds then you might want to stick with the latest release of Godot 3, and use the GLES2 renderer since it'll be the most compatible with anything even if the player is using a potato.

Start with the Godot Docs and change the version in the bottom left to be whichever Godot 4 or Godot 3 version you're using and start there. At least go through their Getting Started section and explanations on how things work and bookmark that site because you're going to be referring to it a lot. And read whichever parts of the Manual section look like they would be relevant for you. Afterward, if you like videos then I'm sure there are a bunch of youtubes on it, but I personally hate videos and wrote this text tutorial walking through everything I did to make a small gamejam game that covers a lot of the fundamentals using Godot 3. And you're probably starting from the right place if you already have a game in mind and can, as you're reading stuff, pay attention to what people are doing and why so you can identify what approaches you can use when you're making your own game (or decide you want to change plans to make things easier).

If you have some coding experience and are familiar with variables and types, if-else, for() loops, functions and passing parameters, and are sort of familiar with object-oriented principles then you're in a good position to start. Otherwise it might be kind of tough and you might want to focus on learning some coding outside of a game-making environment first, like learning some Python or C or JavaScript or smth. It doesn't really matter which exact language you learn as long as you get the concepts down.

Not sure if it's what you're looking for, but I wrote this tutorial for Godot geared for beginner-intermediate level on how I made a gamejam game that covers fundamentals that I felt the Godot docs didn't cover well. Text because I also don't like youtube videos, although in retrospect I prolly should've included pictures.

First step would be to download Godot (3.x and not 4.x because Godot 4 web exports have Apple compatibility issues if players try to play your game on a mac or ifone, while Godot 3 works fine on anything) and go through the Godot docs including their little demo Dodge the Creeps game, then the tutorial I wrote once you're ready for something closer to a simple game you might see on NewGrounds.

Depends on how you pull it off. I could imagine having a Game Jam with that theme and there might be a couple of games that do something crazy amazing with it.

Even if the game isn't spectacular, it'd still be good to post especially if you're just starting in game development and want to see what kind of feedback you'll get.

Maybe the same issue tydaze had in this thread?

You could try opening the project in an older version of GDevelop (5.2.171 or earlier) and exporting the game to HTML from there if you haven't already.

This is really weird. The exported HTML does run fine if I set up a local testing "server" and run it from my hard drive, but messes up if I zip it and upload it to NewGrounds and preview it.

I haven't encountered anything like this before, has anyone else here? @HelperWesley might be my best guess as to who would know if it's something that can be addressed in GDevelop, although the HTML working locally but not after uploading makes me think it might not be GDevelop-specific.

Not gunna lie, this is the first time I've ever seen anyone worry about the best way to avoid any money being made from posting an online game, especially on NewGrounds.

If you're worried about people finding ways to post bogus highscores to a leaderboard then maybe I could think a bit on how to keep that from happening, or at least make it hard enough that it's not worth people's while. If you mean people rating the game up down or sideways for whatever purposes they might have aside from actually liking or disliking the game, then ignore the ratings. If you're worried about something else, it'll be difficult for any of us to say anything useful if you speak in riddles, but if you don't want to post it publicly then feel free to msg me if it's something that can be addressed by coding in Godot and doesn't need to involve changing how NewGrounds, the Internet, or Humanity works.

Are there any clues if you start the game and go to your browser's Developer Tools window and Console tab?

If that doesn't give you any clues, IDK it doesn't sound like it fits any pattern I'd anticipate from a specific issue. Maybe try playing with options in your project upload page like Uses SharedArrayBuffer/Cross Origin Isolation, or deleting the project page and making a new one to reupload to in case it's some random weird glitch.

If you run the your game locally (from your hard drive and not uploaded to NewGrounds, and running from the index.html file using a browser and not in a game engine's editor) will the microphone work? If it works locally but not after uploading, then yeah it's probably an issue with NewGrounds not granting access to request microphone permissions, and it would be a matter of discussing with a staff member whether the benefits of letting game devs have their games access microphones would outweigh the risks of letting random people upload whatever they want that can listen in on your microphone.

I suspect that such a tool doesn't exist, but if you haven't already then maybe try asking at the Godot Q&A.

If not, and if most of the GameObjects have similar structure and the same set of animations where the only thing that changes is the root filename for the animation frames, then in principle it would be possible to write a script extending AnimatedSprite that would load all of the animation frames in for you so you just need to specify a location to look to load all of those frames. But in practice, I worry that such an approach could cause performance issues since it would need to run load() instead of preload() statements a lot of times whenever a character gets instantiated. Probably better to bite the bullet and set up AnimatedSprites manually instead of trying to get fancy with code unless it would be a truly herculean task.

Just to make sure: is the issue that you no longer have the source images (either a series of images like hero_walk_0.png, hero_walk_1.png, hero_walk_2.png, hero_slash.png or as a spritesheet of hero_animations.png) and need to extract them from Unity? (I could find sprites from my old Unity game Cat's Eye on my hard drive in the Unity project's directory \Documents\Unity\CatsEye\Assets\Sprites.) Or that you'd like to export Unity's GameObjects with all of their associated info about how the sprites are arranged in different animations that the object could play and import them as Nodes in Godot (which I don't think is doable)?

If you have the source images then yeah making 100 different characters using the usual procedure for animated sprites with AnimatedSprite nodes would be tedious, but most of it involves doing things that seem like they just have to be done to make the game work: making names for and dragging images in for each of the different animations that it might show like idle, walking, slashing etc, setting properties like FPS rates for each of them, and writing code to switch between states at appropriate times.

https://docs.godotengine.org/en/3.1/getting_started/editor/unity_to_godot.html

Just in case there are some people about to pick up Godot engine, I'd recommend getting the latest Godot 3 version instead of Godot 4 because Godot 4's web exports still aren't compatible with Mac / iOS browsers. That said, if you mainly want to export to target systems' native architecture and might also release web exports as a side thing, Godot 4 would be fine because most people here seem to don't use Apple anyway and Godot 4 games have been frontpaged here.

If you're trying to get a web export to be able to work on an iPhone... I tried to let as many people as I could know about this issue but unfortunately this ranks as the suckiest thing to ever happen with Godot which has otherwise been a great engine (and still is if you use Godot 3)...

https://www.newgrounds.com/bbs/topic/1525855

I agree, that's awfully ambitious if you haven't made a game before. The games here on the NewGrounds frontpage are pretty much what you can make if you're good and have been making games for a couple years or so, and is what people here can give you advice about doing.

If that doesn't dissuade you and you'd still like to learn what you can and make what you can, I wrote this about getting started in gamedev a while ago after I made some games I was proud of, which is still pretty much accurate I think.

You can use any engine tbh. It's also possible to do a multi-game collab if you wanna, even across different engines / frameworks. I thought about doing it a while ago and made this prototype as a demonstration of concept and posted source code that people can put into their games to make them interact. If you do it, you might want to start by making a "root" game that other games can branch off of.

I know you can avoid the issue if you use File (which will point to a place in IndexedDB which you can specify as a parameter to its functions) and hard code a path to something like yourName_yourGamesName so it doesn't change when you push an update to your game.

It might be better to see how I did it than try to explain -- this was a sorta slick thing I did when I assumed that most newbies would use PlayerPrefs (like I did in my first game) and get burned by it because it suffers from the same problem you're facing. I basically wrote a script to override Unity's PlayerPrefs behavior and make it write to a location you want. Here's the source code, and the class constructor and Save() function are probably what you want to pay attention to.

It's been a long time since I used it in my Phaser game (which is basically just JavaScript) but my recollection is that I got the newgroundsio.js file from the old deprecated version of the API implementation in the /bin subdirectory and put it in a /bin directory of my game, then had code like so at the top of my index.html file before the JavaScript with my actual game:

<script src="bin/newgroundsio.js" type="text/javascript"></script>

Then came the script with my game, including the following lines

// Start NewGrounds.io
var ngio = new Newgrounds.io.core("my_app_id_went_here", "my_aes_encryption_key_went_here");

and later

    if (ngio.session_id != null) {
      if (wonZoom + wonNoZoom > 0) {
        ngio.callComponent('Medal.unlock', {id: one_of_my_medal_ids_went_here});
      }
      if (wonZoom + wonNoZoom == buttonSprite.length) {
        ngio.callComponent('Medal.unlock', {id: another_medal_id_went_here});
      }
      if (wonNoZoom == buttonSprite.length) {
        ngio.callComponent('Medal.unlock', {id: the_last_medal_id_went_here});
      }
    }

TBH I didn't even know JavaScript when I started this for a month-long Phaser jam so I probably wasn't using good programming practices but it seemed to work. Using the newer version at the top of the list on the newgrounds.io page might be better, but I haven't used it myself.

I've thought my games were awesomesauce while I was working on them but then after releasing them and coming back to play them a lot later I was like wtf why did I think this would be enjoyable for anyone to play?

Not sure I have an answer, but I have noticed that when I collabed with Gabe and Toffee the games turned out to be pretty popular even though when I was working on them I thought they were heading toward being too simplistic from a programming perspective. Telling a story and creating an engaging world / environment seem to be pretty key.

For a month, and if it's for a stream, I say do something totes not srs and just lulzy. Kickboxing game with Putin and Xi where half the game is playing dressup with them before the fight starts, and where they mostly fight dirty by kicking each other in the oval offices.

I looked at Unreal a long time ago. MSGhero is correct - you have a choice between either looking through their docs and finding the last version that inherently supported web exporting (which is what I did) or download the latest version and hope that user-maintained code somewhere can allow it to export to web without issues.

Then I saw that a web export for the simple placeholder single-small-level microgame that comes as a template option if you start a new project ends up being about 100 mb, zipped, so I was done with it. Don't use Unreal for web 3D games, use Godot (version 3.x not 4 because of issues of Mac compatibility with web exports) or Unity.

I also agree with not trying to make your first game be 3D. First think of a 2D game you'd like to make, then do a tutorial and while you're doing it see what techniques you could modify to incorporate into your game (which might help push you to really learn what they're doing and why so you can adapt it to your game), make the tutorial game, then make your 2D game. With Unity the one that taught me pretty much everything I needed to know to make a game was the Ruby tutorial, with Godot I wasn't aware of a good tutorial so I wrote my own tutorial for beginners who've downloaded the engine and looked through their docs on making the example Dodge the Creeps microgame and are ready for something more like a NewGrounds game jam type game.

In general, programming a game is its own sort of skillset that has maybe some but not a lot of overlap with other math and science stuff. Like Gimmick said, if you want to make or modify your own engine or graphics renderer then that's one thing. But if you just want to make a game using an engine that is set up to do most of that (Godot or Unity or even HaxeFlixel or Phaser), then the engine will handle stuff for you. Specific comments:

• Linear Algebra - do not need
• Calculus - you don't need to actually do calculus yourself. If you're familiar with concepts of integration and differentiation then that's nice, but often you'll have code like

acceleration = force1 + force2

velocity =+ acceleration

if on floor velocity.y = 0

if hit wall velocity.x = 0

position += velocity

Which I wouldn't consider as needing to know calculus for

• Geometry - it can help to know what a normalized vector is (pointing in the same direction but forced to have a length of 1). I took some advanced geometry and actually used dot and cross products when I wanted to do some custom calculations for Cat's Eye. But most engines have functions that will calculate angles between vectors for you which would make it unnecessary, so I probably didn't need to do it that way.
• Discrete Math - you should know what a modulo is, and that if you generate a random integer in a large range and calculate it mod N, then you end up with a random integer in the range from 0 to N-1
• Statistics and Probability - you do probability in programming by generating a random number and having statements like

if rand_num < 0.4

slash_attack()

elif rand_num < 0.7

headbutt()

elif rand_num < 0.9

haruken()

else

heal_self()

• Trigonometry - it might be helpful to know what a sine and cosine are, but I think I've mostly used them to make wavy changes in some parameter like color or light intensity, not for actually calculating physics
• Physics in general - see Calculus. And if you want to have a gravity generator, then you should know that you can calculate the vector from player_coordinates to star_coordinates by saying vector_to_star = (star_coordinates - player_coordinates) and then having star_gravity = vector_to_star.normalized * (1 / vector_to_star.length)^2

You now know all the advanced math you need to know for programming a web game.

Things not listed are that you need to know that an array of size N has elements numbered from 0 (not 1) to N-1 (not N). So if you're using C you can say for(i=0; i<N; i++) { } and that will loop over all elements up to and including the last one in an array of size N. And you will get a fuckup if you try to access element number N of an array of size N, and you won't have things work like you want if you access element number Y without remembering that it's the (Y+1)th element. Also, you will need to learn the difference between global coordinate systems and local (with respect to some object in the game) coordinates because that will mess you up nice and good at some point especially if you transition to 3D.

A fair number of games here have links to Steam pages. IDK what percentage of them actually make it big, or make anything at all. But some folks are trying. They seem to be in the minority though, and I'm personally just a hobbyist.

Depends on how complex you want to make it, but adding momentum to a character is easy enough to just post a question about. Make a variable of velocity and have the player's input increment or decrement the velocity each frame (have velocity.x += input.x * delta instead of velocity.x = input.x), along with code to not let the velocity exceed some maximum velocity (if velocity.x > velocity_x_max: velocity.x = velocity_x_max). If you want to add dampening so the player gradually slows without input then have a variable like dampening = 0.4 or so and add a line of velocity.x *= dampening ^ delta.

Writing tutorials is more work than writing code, I did it for a gamejam game I made to teach beginners Godot 3, but for something small like just a player controller IDK if it would really need a tutorial. The other thing about writing tutorials is that a lot of people are amateurs and hobbyists who might not feel like they write pristine enough code to serve as a model for others to emulate.

It sure seems like something's making it call functions you aren't intending to call. But I'm not sure if I can give any helpful advice on debugging without seeing the code, and possibly the scene's structure if you have subtle bugs among a bunch of code in different nodes that aren't interacting how you want.

The bad part about Godot and any object-oriented structured language is that, depending on how you set things up, it can get hard to keep track of code and how it's interacting with things if it's spread out in a bunch of nooks and crannies among parent, child, sibling, half step uncle twice removed, and autoload nodes and I'm not aware of a good way to trace things.

Could anyone with a mac lemme know if this game runs for you?

It says in the Developer Tools window it was made in Godot 4.1, and got frontpaged and didn't have comments of "Game won't run 0/5 stars", so maybe it works? I can't test it on my iPad 'cuz it's not mobile friendly and I'm too Windows to try to make the iPad think it's a laptop.

If you can convert your video to Ogg Theora format (.ogv) you can use a VideoPlayer node (in Godot 3.5) or a VideoStreamPlayer node (in Godot 4, but Godot 4 web exports currently won't run on iOS / macOS devices).

I haven't clicked the rickroll link so if it's not a rickroll and actually has smth important lemme know.

If it would be important to get more of an analog feel than you could get with suggestions like a Run key, an alternative might be to use mouse for movement. It would probably feel more natural to players for top-down than side-scrolling formats. And of course might not be an option if you're planning for 2 player local gameplay.

The GMTK jam games are hitting Under Judgement now so you can take your pick, but here are a few to choose from that I liked.

Scratch should be allright, maybe also look at GDevelop and see which one looks like a better fit for you because my impression is that GDevelop looked a little more capable. If you're willing to pay money, GameMaker and Construct would also be options. I wrote this TL DR on getting started in gamedev which should still be pretty much accurate, but long story short you could also consider just learning some programming first and then starting off with a more capable engine like Godot 3.x or Unity. Depends on your personality and whether you would want to learn some programming first vs get started making games sooner, either way is ok.

Even though Godot 4 is an official release now (not in alpha or beta testing anymore), currently the Godot 4.0 docs say the following.

Attention

Godot 4's HTML5 exports currently cannot run on macOS and iOS due to upstream bugs with SharedArrayBuffer and WebGL 2.0. We recommend using macOS and iOS native export functionality instead, as it will also result in better performance.

Godot 3's HTML5 exports are more compatible with various browsers in general, especially when using the GLES2 rendering backend (which only requires WebGL 1.0).

I tested it out with a minimal Godot 4.0.3 HTML5 export uploaded to NG, and verified that it plays fine from my Windows lappy but doesn't run at all and just gives an error screen about cross origin array buffers or some crap if I try to run it from a browser on an iPad.

Godot 3.5 and probably 3.6 work fine though, so continue to use those.

However, if I'm wrong about that and Godot 4 web exports can be made to work on Apple stuff, or if at any point in the future anyone notices that Godot 4 HTML5 exports start being able to run from Apple stuff, then plz post here and/or ping me (which posting here will do) because I modified the code for the Newgrounds API Godot implementation to work with Godot 4 and confirmed that it can do everything including cloudsaving correctly (if you run it from Windows). I can post that Godot 4 code, but for now I'm holding off because posting API code for a version that won't work on the web for a lot of people would be trolly.