Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Lets learn from each other

A topic by Rimulex created Sep 05, 2023 Views: 448 Replies: 17
Viewing posts 1 to 8
Submitted(+6)

With the vast array of different games, everyone has made I'm almost 100% certain, that everyone had some kind of trouble during the development of our games so let us talk about some of the trickiest problems that popped up during our month-long development.  I'd be willing to bet that all of us have some kind of wisdom to share that others could benefit from or things that could have eliminated bugs before they even appeared. The same goes for things we were able to do incredibly fast that made making the game significantly easier to develop.

In my case, the thing that gave me the most trouble was coding the AI for the land shark. I think I scraped two versions of the code before I went with a very basic version of it. Originally the goal was to have the shark patrol, to random points in the map, and then hunt the player if the player got within range of them. if the shark lost enough health it would have tried to flee from the player or find a healing item. 

Submitted(+4)

as the artist of my duo team, i had to redo a lot of the animated sprites because i'm not that experienced in animation :,)) i tried to wing most of them and learned that the best way to animate for me personally is to block everything out first before making everything pixel perfect :DD and that i should probably try out aseprite because i was animating sprites in clip studio paint x) aseprite has animation tools ive heard!!!! ^-^

Submitted(+2)

I used Aseprite for our project! I did use CSP for quick concepts and sketches but the animation in Aseprite is so much better for pixel art, even if the interface is a little strange to get used to if you've always used the latter (I kept hitting the bracket keys to increase brush size but it kept changing colour!).

Submitted(+3)
  • Joe's Actions Text Plugin for PGMMV creates child objects in the default Player Group when displaying text - this info was not in the included guide, and thus I spent maybe a whole day trying and failing to fix enemy AI that just flailed back and forth whenever text showed up on screen (they were set to pursue objects in Player Group). Moral of the story is: if something is wrong for mysterious reasons, check every aspect of your plugins I guess? xD
  • Some accessibility things I learned - I need to learn to set up keyboard support because I guess almost nobody has controllers, which was a huge reality check. Also, I need to make games in 30fps from now on. I thought having a high fps would be fine since all my stuff is 2D and light on processing power, but apparently most people can't run even a 2D game at 60fps, so I need to suck it up even if I personally think it looks bad :/
  • Also, something that totally changed the way I approach game design was the concept of "multiple brains" for objects or tasks. In short, don't be afraid to just spam controller objects for every little thing so your game can multitask better!

I think some of this might be only applicable to PGMMV and it's own quirks as an engine, but I hope y'all still enjoyed reading it!

Submitted

i see a lot of this as things that can be applied even outside of this engine! I have a powerful gaming laptop and mid-way through I had the thought of "What if the specs are too high for anyone to play" Its why I went very minimal with a lot of the assets I used the my game. But I'm impressed that 2D game running at 60fps gave anyone any issues at all

Submitted(+4)

Export and test a few hours before the submission. I know there's a few hours left and you could use those to develop the game further, but there's a plethora of things that can go wrong in an export that doesn't happen in an engine build, and the sooner you figure out which bugs are only in the export the better. We had a pretty bad one we found where the game closed when trying to go to the next level or retrying from game over, but we found exporting as a DEBUG solved it. I don't know if this is something we messed up or a quirk of Godot 4.

Additionally Git was a lifesaver, I haven't had the chance to properly use it in a project before because I was a little scared to use it, but it sped up the process a lot! As long as you stick to your branches, discard unnecessary changes, and back up before merging to main, you should be fine. I used the GitHub desktop app and I don't much like it, but it was free. And if you're using Godot, please close the project before pulling!

Submitted(+2)

Ohhhh this was something i was fearing right from the start! I used Unity 3D and I had a issue where the game crashed after the cutscene. Turned out the AI controllers weren't within a area they could properly navigate

Submitted (6 edits) (+4)

Our team had good time with this jam. Maybe some fatigue near the end. We are all gamedev students and have done a few games together before so we were already comfortable working together and had a shared idea of the tools we would be using, how we should work, share tasks and what we are going to use.

Some of the things we did I think are important:

.1 Communicate with teammates

I don’t only mean sharing tasks, progress, what tools you are going to use and everything else that goes to project normally. You should also talk about your expectations for the project. Why are everyone participating the jam? To win? To have fun? To learn new things? As differences in these will cause friction in the team. I’ve seen it happen before. How about, if there is a price, how is it shared in case you win? It’s often better to talk it out beforehand so there are no disputes. How about work hours and work time? Are you going to do it together after work/school/etc? By passing notes if some do it in the morning and some in the evening? How about if some can contribute less hours? Will it be a problem for some? For our team we have similar situation in life so it was clear that we would be doing the work during evening for the most part and communicated over discord during our work time. We also talked out the goal of this jam and for us it was to have fun. As for the price. Do as I say, not as we have done. We have not had explicit conversation about it but I’d say everyone has assumed even split in the case we win. I highly doubt there were any other ideas about it at any point.

.2 Using version control

It makes sharing your work easy as long as you know basics of what you should and shouldn’t do and communicate well enough. Rolling back / inspecting breaking bugs in code is way easier as you can compare changes between any versions you have. Works as a backup. My recommendation is ‘Git’ and it is what we used.

.3 Build often and test it on target platform(web, windows, etc.)

It helps to ensure there are no unexpected hiccups with the build. For example the unity player didn’t work as I had thought it would with itch.io and because of this guideline we knew to tinker with it from day 1 to make sure our game works well here.

.4 Submit playable versions early and often enough

This is to make sure you have at least something submitted by the end even if there are problems on your end or on the servers. There were a few teams in this jam that missed their mark on this one and it happens in every jam. At least on itch.io you can update the files until time runs out. Take advantage of that. This is even more important in jams like GMTK which basically break the servers every year on the last submitting hours.

.5 Have something playable quick.

Polishing, testing and fixing bugs often take more time than one might think. We had our games first playable version after the first day. Namely the level itself, the spawners, rats including their ‘AI’, player and killing them but everything was just boxes on screen besides the background. On the second day we had completed everything gameplay wise. Streaming was added as secondary thing to keep track of as smacking rats alone was not that interesting. The remaining 3 days were used to add the art, learning to animate in unity, adding sound effects, polishing, testing and tweaking the game and the UI.

.6 Have it tested by other people

Gamedevs quickly become blind to the rough edges of their darling. We had the game tested by at least a few friends every day to make sure there are no bugs and to see where it could improve. Things like the ‘light’ from streaming setup and the button prompts were added because of the feedback we got. I had naively thought that, “The streaming part is explained in the starting menu, surely people should know how to play”. Of course not. People want to start playing as fast as they can and skip it all. So the prompts were more than necessary to have good experience. We also updated the menu layouts a few times because of feedback. When testing with other people remember to keep quiet at least the first 10-ish minutes depending on game length to see how a player without the dev behind their back would struggle. It can be quite humbling and also quite a struggle to not say anything or help in any way. And as a final note. Bribing testers with snacks can be a good idea and strangers often give more honest feedback than friends and family.

.7 Have a web build if you can

People seem to mostly follow the path of least resistance. So more often than not. Games that can be played as soon as you enter the web page get played more than the ones that you need to download and install to play. At least by my experience. And also the statistics on ‘number of ratings’ in this jam.

.8 Premature optimization is the root of all evil

Jams are one of the few places where you can take enormous amounts of technical debt(make solutions that will hurt you in the long run) and never pay it back. Don’t worry about whether the code is good or not. Just get it working as fast as you can without breaking the game. Players care about the end result and so should you. Not about what’s under the hood. And you won’t be tinkering under the hood more than the duration of the jam anyway. So go wild. Same is more or less applicable to other areas as well. The goal should be best delivery in the given time and theme of the jam.

.9 Take the cheap optimizations

This may sound a counter to the previous one but hear me out. Some things can be optimized by right choices beforehand. There for it won’t cost you any precious time during jam and should be taken. These can range from choice of tools to the specifics of asset creation. For example you might be able to iterate faster with Godot as it seems to be way faster than Unity or Unreal both in editor and with build times. Take that with grain of salt as I’ve used Godot only a little so far. Another is texture sizes. Dimensions in power of 2 will be more optimal for memory usage. I wont be going into technicalities on that. Putting it simply the side lengths should be from the following list but they don’t have to be the same for both sides. [2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, and so on] There are more of these, many won’t be obvious and will depend on platform. So the best way to learn about these is to get to know your tools, platforms in depth and/or talking to more experienced developers about these.

Now all of this is just my opinion and some of it is bound to be wrong at least on individual cases.

THE COMMENT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE COMMENT OR THE USE OR OTHER DEALINGS IN THE COMMENT.

Sorry for the dry humor. :)

Submitted(+1)

Comments like these are exactly what I hoped to see. I'm truly curious about just how many teams missed the cutoff point either because they started late or didn't plan far enough ahead. Where there 6 of you?

Submitted

We had a team of four. Each of us has done 7-ish projects or more. Some bigger, some smaller and some jams.

Submitted (2 edits)

Got reminded of a few good ones today so I added them to the post.

Submitted

My engine of choice was UPBGE and my options for scripting were python, logic bricks and logic nodes. Having very little knowledge of python, I went with the visual scripting route by only using logic nodes. The benefit of logic nodes is that it is faster to put together and has more customizable options than logic bricks, but the current issue with that is that having a lot of logic nodes and nodes within them takes a toll on performance. Had I more time to optimize my game, I would have simplified my logic nodes and switched over some of them for their logic bricks counterparts where possible. And although it might seem like graphics could have been a factor to performance it wasn't as heavy as the logic nodes.

Submitted

The trouble I had for my game. which is a turn base battle game. is math and having to calculate over and over how much experience a enemy gives and how much damage one of them does for a move and the level to make everything balanced. 

not sure how you went about it, but a way to simplify things could be by using curves to determine the scale/growth of the experience drops and the damage/stats, it's still in the end math but you could find it easier since you have some sort of visualization of the growth (I haven't gotten to do this myself but it is something I am looking into just sharing thoughts)

Submitted(+1)

I programmed everything myself outside of the character controller, and brushed aside things like UI since I assumed it would be easy. Sure enough my UI is ugly and boring, and wasn’t even finished. Similar story for the audio.

I have a better respect for the creative side of the game dev process now since it kicked my ass a bit haha. Live and learn

Submitted

I’m with you there on the UI thing. Each and every time I do a project I always think, “Eh I’ll do it later”, and it always ends up being such a pain. Learning Unity’s Canvas system was a bi**h and a half let me just tell you.

Submitted (1 edit)

Have you tried the new UI builder? If the canvas system is “a bi**h and a half”. Then the UI builder should probably be described as 5 of them and all of their extended family. I can see where they were going with it with the website like architecture but I don’t like it at all.

Submitted

I haven’t tried it myself but oof that sounds rough…